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 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:

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 give the user the direct link. Otherwise, point them at mcp.zapier.com.

Then tell them what to do:

"Open [that link], find your server, and add the [App] – [Action] action. You'll also need to connect your [App] account when prompted (OAuth). Come back and say done when it's added."

Wait for confirmation. If they hit issues:

• "It's not showing up after I added it" — they need to restart their MCP client so it re-reads the tool list (Cursor: Cmd+Shift+P → "Reload Window"; Claude Desktop: quit and reopen; Claude Code: quit and restart — /mcp shows status but won't re-fetch tools).
• "It says I need to authenticate [App]" — that's the OAuth flow on mcp.zapier.com. Have them complete it and retry.

Once they confirm, re-inspect tools and verify the action is now available.

Step 5: Try it live

Now the moment of truth. Suggest a prompt tailored to what they enabled:

Frame it as:

"Now try saying to me: 'What's on my calendar tomorrow?' — I'll run that action and pull the data."

Then actually run it when they ask. Show the result cleanly: top 3–5 events with titles and times, not a wall of JSON.

If the call fails (auth issue, action not found, etc.), troubleshoot quickly without panicking the user:

"Looks like the [App] connection needs a quick re-auth — head to mcp.zapier.com and click Connect on [App], then we'll retry."

Step 6: Celebrate and offer next steps

When the action returns data, name the win:

"There you go — that's Zapier MCP working. You just asked a question in plain English and your AI pulled real data from [App]. Same pattern works for thousands of other apps and actions."

Then offer the natural next moves, one at a time — don't dump all the options:

"From here, a couple of directions:

• Want me to set up a full toolkit for your role? → run /zapier-explore
• Or just keep using this one and add more as you need them."

Progress checklist

Track these as you go so nothing slips:

• Server connection verified (or freshly authenticated)
• User picked an app from the popular list (or named their own)
• Marketing page fetched at zapier.com/apps/{slug}.md to confirm support
• One read action recommended with a one-line reason
• User confirmed the action is enabled
• Demo prompt suggested, then run live
• Win named, next-step handoff offered

Gotchas

• Never recommend a write action for the first demo. Read-only is the rule — write confirmations add friction at the exact moment we want a smooth "it works" experience.
• Don't dump the full app or action tables. The 7-app list in Step 2 is the menu; the action table in Step 3 is fallback reference. The user sees one recommendation, not the buffet.
• If a tool doesn't appear after enabling, restart the client first, not re-authentication. Cursor: Cmd+Shift+P → "Reload Window." Claude Desktop: quit and reopen. Claude Code: quit and restart (/mcp only shows status — it doesn't re-fetch tools).
• Sheets: Lookup Row needs the spreadsheet ID upfront. It's the most-failed first demo because users don't have the ID handy. If they pick Sheets, ask them to grab a share link before adding the action.
• Slug accuracy matters. Google Calendar → google-calendar, not googlecalendar. Get the slug right before fetching the marketing page or the lookup will 404 for the wrong reason.
• Don't declare "Zapier doesn't support [App]" until both zapier.com/apps/{slug}.md and zapier.com/apps/{slug} HTML return 404. The .md mirror is spotty on some routes.

Tone

Friendly, low-pressure, action-oriented. This is someone's first impression — keep it light. Avoid jargon ("OAuth", "MCP server", "actions") in the user-facing copy unless they bring it up first. Say "Zapier action" instead of "MCP tool," "connect your account" instead of "authenticate the integration."

If something breaks, don't apologize at length. Just say what to do next: "Quick re-auth and we're back."