/zapier-demo

name: zapier-demo
description: Walk a new user through setting up their first Zapier action and running it live — the smallest possible win. Asks what app they use, recommends one read action to enable, guides them to mcp.zapier.com to add it, then demonstrates it working in the same chat. Use when the user asks "show me how Zapier works", "set up my first action", "give me a quick demo", "I want to try it", "what's the fastest way to see this work", "minimal setup", "hello world", or "smallest example".

Zapier demo

Walk a new user through the smallest possible first win — one app, one read action, one prompt that actually runs. The whole flow should feel quick: a few minutes from "I'm curious" to "oh, that worked."

This is the natural next step after `zapier-onboard` for users who want to see Zapier work before configuring a full toolkit.

When to use vs. other skills

• **zapier-demo** (this skill) — *one app, one action, immediate demo.* Fastest path to "oh, this works."
• **zapier-onboard** — *pitch + connect + diagnose.* Run this first if the server isn't connected yet.
• **zapier-explore** — *role-tailored expansion.* Run this after demo to set up a full toolkit for the user's role.
• **zapier-status** — *health checks and audits* on an existing setup.

If the user says "show me," lean here. If they haven't connected the server yet, route to zapier-onboard first.

Step 1: Confirm the server is connected

Inspect available Zapier MCP tools. If none exist, the server isn't authenticated yet — authenticate first via `mcp_auth` or the client's MCP settings (same pattern as `zapier-onboard`'s connection step). Don't continue until at least the configuration tools are available.

Once connected, set the tone:

> "Let's get one Zapier action working so you can see this in action. We'll pick one app, enable one thing, and try it — should take just a couple minutes."

Step 2: Ask what app to start with

Lead with concrete popular options — most people find it easier to react to a list than to come up with one cold:

> "Which app do you want to try first? A few popular ones to pick from: > - **Gmail** — find or draft emails > - **Slack** — find messages and ping channels > - **Google Sheets** — look up rows in a sheet > - **Google Calendar** — check your schedule > - **HubSpot** — find contacts and deals > - **Jira** — look up tickets > - **Notion** — find pages > > Or name something else — Zapier supports 9,000+ apps."

Confirm support and pull app details

Once the user picks, **fetch the app's Zapier marketing page** to confirm Zapier supports it and surface action details for Step 3:

https://zapier.com/apps/{app-slug}.md

Examples: `https://zapier.com/apps/slack.md`, `https://zapier.com/apps/hubspot.md`, `https://zapier.com/apps/google-calendar.md`.

**Slug conventions:** lowercase and hyphenated. `Google Calendar` → `google-calendar`. `Microsoft Teams` → `microsoft-teams`. `HubSpot` → `hubspot`. When uncertain, check `https://zapier.com/find-apps/{letter}` (the alphabetical browse) to confirm the canonical slug.

The fetched page tells you:

• **Whether Zapier supports the app** — a successful fetch = yes
• **Available read/write actions and triggers** — use these to recommend the right starter in Step 3
• **Popular cross-app Zaps** — useful for the Step 6 "what's next" pitch

If the `.md` mirror 404s, try the HTML page at `https://zapier.com/apps/{app-slug}` as a fallback. If both 404, be honest with the user:

> "I'm not finding [App] in Zapier's catalog under that name. Want to pick a different one, or check [zapier.com/apps](https://zapier.com/apps) to verify the spelling?"

If they're stuck choosing:

> "If nothing jumps out — Google Calendar is the easiest first one. Everyone has a calendar, and the 'what's tomorrow?' demo lands every time."

Step 3: Recommend one starter action (read-only)

Use the action list from the Step 2 marketing-page fetch to pick **one read action** — search/find/get/lookup. Read-only matters here: write actions need confirmation, which adds friction to a first demo. We want the simplest possible "click run, see result" loop.

Tell the user what you're recommending and why, in plain language:

> "Great — for Calendar, the simplest first action is **Find Events**. It lets your AI look up what's on your schedule. We'll add that one and try it."

Fallback starter actions by app

If the marketing-page fetch didn't surface a clear read action, fall back to this table for the most common apps:

| App | Recommended first action | Why | |---|---|---| | Google Calendar | Find Events | Universal, easy to verify ("what's tomorrow?") | | Gmail | Find Email | High-impact, every user has emails to find | | Slack | Find Message | Most-used in chat-heavy workflows | | Google Drive | Find a File | Works for any user with Drive | | Google Sheets | Lookup Spreadsheet Row | Needs a specific sheet but very tangible | | Jira | Find Issue by Key | Needs a Jira ticket key (e.g., PROJ-123) — easy to test | | Linear | Find Issue | Same pattern as Jira | | GitHub | Find Pull Request | Read-heavy use, fast demo | | GitLab | Find Merge Requests | Same as GitHub | | Notion | Find Page | Useful for note-takers | | HubSpot | Find Contact | Sales-flavored, easy to test with own email | | Salesforce | Find Record | Like HubSpot — pick by email or name | | Trello | Find Card | Visible, easy to verify | | Asana | Find Task | Project-management equivalent | | Airtable | Find Record | Database-flavored | | Google Docs | Get Document Content | Pull a doc you have open |

If the user names an app not on this list, default to a "Find [Thing]" pattern — almost every Zapier-supported app has a search/find action. If you're unsure of the exact name, say "the find/search action for [App]" and let them pick the right one in the configuration UI.

Step 4: Walk them through enabling it

If the server exposes a `get_configuration_url` tool, call it first and g