In May 2026, you no longer write a custom Stripe integration, a custom Atlassian integration, and a custom Notion integration to get your agent talking to those systems. You install three Model Context Protocol (MCP) servers — official ones, published by Stripe, Atlassian, and Notion themselves — point your agent at them, and the agent acquires roughly 400 tools across those three platforms in about an hour. This lesson is the practitioner walkthrough: install one official MCP server, connect it to a real agent, trace a single tool call end-to-end (agent decision, MCP dispatch, vendor API call, response back through MCP, agent reasoning), and explain what the MCP server is doing versus what the agent is doing. We use the May 2026 official-server list — Salesforce, ServiceNow, SAP, Atlassian, GitHub, Slack, Box, HubSpot, Notion, Stripe, Cloudflare, Vercel — and the named hosts (Claude Desktop, Claude Code, Cursor, Windsurf, ChatGPT, Zapier MCP) where these servers run.

What an MCP Server Actually Is

Model Context Protocol is a JSON-RPC-based protocol that Anthropic open-sourced in November 2024 and that the rest of the industry — OpenAI, Google, Microsoft, GitHub, Atlassian, Stripe, Notion — adopted through 2025. As of May 2026, it is the de-facto standard for connecting an LLM agent to an external system, and the cross-vendor framing is settled enough that a single MCP server runs unchanged inside Claude Desktop, Cursor, Windsurf, Claude Code, ChatGPT, and the Zapier MCP host.

An MCP server is a small process — often a single Node, Python, or Go binary, occasionally a hosted HTTPS endpoint — that exposes three things to an agent:

1. Tools. Named functions the agent can call (create_issue, charge_customer, append_to_page) with documented JSON schemas describing arguments and return types.
2. Resources. Read-only context the server can hand back when asked (a page's content, a customer record, an issue body).
3. Prompts. Reusable named prompt templates the server publishes (e.g., "summarize this Linear cycle" templated against the server's own knowledge of the cycle schema).

The agent does not need to know how the server talks to Stripe or Atlassian. The agent sees a flat list of tools with schemas, picks one, sends JSON arguments to the server, and gets a JSON result back. That separation is the entire reason MCP matters: any agent that speaks MCP works with any server that speaks MCP, regardless of who built either side. Before MCP, every agent platform had its own incompatible tool-integration format and every SaaS vendor needed to either build a connector per platform or hope the platform built one for them. Now there is one shape that fits all sides.

The MCP server is the thing that knows how to authenticate against Stripe and how to translate charge_customer({"amount": 1000}) into the right HTTPS call. The agent is the thing that decides whether to charge the customer at all. Keep those responsibilities separate and most MCP architecture confusion goes away.

The May 2026 Official Server List

"Official" means the vendor of the underlying system publishes and maintains the MCP server itself. That distinction matters enormously for trust (which is the subject of Lesson 2 of this chapter). Below is the practitioner-relevant list of official servers as of May 2026, with the surface area each exposes.

Salesforce MCP

Maintained by Salesforce. Exposes the Sales Cloud, Service Cloud, and Marketing Cloud object models — Account, Contact, Opportunity, Case, Lead, Campaign, plus custom objects via metadata reflection. Roughly 80 tools at GA. Auth is OAuth2 with Salesforce's per-user permission set enforcement, which means the agent gets exactly the access the connected user has and no more.

ServiceNow MCP

Maintained by ServiceNow. Exposes incident, change, problem, request, and CMDB tables, plus Knowledge Management read. Roughly 60 tools. Often used in pairs with the Atlassian MCP to bridge dev-side and IT-Ops-side ticketing.

SAP MCP

Maintained by SAP. Exposes S/4HANA Cloud, SuccessFactors, and Ariba surfaces via SAP Build's MCP layer. The most enterprise-leaning of the official servers and the most rigorously permission-scoped — SAP's authorization objects (the famously granular "you can read this field but not that one" model) come through unchanged.

Atlassian MCP

Maintained by Atlassian. Exposes Jira (issues, comments, sprints, transitions), Confluence (pages, spaces, attachments), and Atlassian Compass. Roughly 50 tools. The default MCP destination for "agent that does engineering ticket triage."

GitHub MCP

Maintained by GitHub (Microsoft). Exposes repos, issues, PRs, Actions, Codespaces, Copilot. Roughly 70 tools. The default MCP destination for any code-aware agent that needs to read PR diffs, comment on issues, or kick off CI.

Slack MCP

Maintained by Slack (Salesforce). Exposes channels, messages, threads, users, and Slack Connect. Roughly 30 tools. The default "write to a channel" or "read this DM thread" destination.

Box MCP

Maintained by Box. Exposes files, folders, metadata, and Box Notes. Roughly 25 tools. Enterprise-document-store flavor; commonly paired with Salesforce MCP for "find the contract attached to this opportunity."

HubSpot MCP

Maintained by HubSpot. Exposes Contacts, Companies, Deals, Tickets, Marketing Hub objects. Roughly 50 tools. The SMB-and-growth analog to Salesforce MCP.

Notion MCP

Maintained by Notion. Exposes pages, databases, blocks, comments, users. Roughly 25 tools. The default MCP destination for "agent that reads our internal docs and updates the project tracker."

Stripe MCP

Maintained by Stripe. Exposes Customers, Charges, Subscriptions, Invoices, Products, Prices, Webhooks. Roughly 60 tools. Notable because Stripe's MCP is the cleanest public example of how to scope a payments-grade MCP server safely — read tools default-on, write tools require explicit per-tool opt-in.

Cloudflare MCP

Maintained by Cloudflare. Exposes DNS, Workers, R2, Pages, Access, Tunnels. Roughly 80 tools. The default MCP destination for any "agent that operates infrastructure."

Vercel MCP

Maintained by Vercel. Exposes Projects, Deployments, Domains, Environment Variables, Analytics. Roughly 35 tools. Often used alongside GitHub MCP for the full ship-from-PR-to-prod flow.

Zapier publishes a different kind of MCP server — a meta-server. The Zapier MCP exposes Zapier's full library of ~8,000 app connectors as MCP tools, dynamically. You ask the Zapier MCP for "the Salesforce.com create_lead action" and it returns a tool schema generated from Zapier's underlying app connector. Practitioners use Zapier MCP as the fallback for SaaS apps that don't have a first-party MCP server yet.

Install an Official MCP Server

The mechanics are nearly identical across hosts. We walk through the Atlassian MCP into Claude Desktop because that combination is the most-installed as of May 2026 (the Atlassian MCP crossed 400,000 monthly active agents in March 2026 per Atlassian's own developer-day numbers).

Step one: locate the server

Atlassian publishes the server at atlassian.com/mcp with a one-click install link for Claude Desktop, Cursor, Windsurf, and Claude Code. The link generates a host-specific config snippet. Do not install Atlassian MCP from a third-party GitHub repo even if it looks legitimate; the official one is at atlassian.com.

Step two: paste the config

For Claude Desktop, the config file is ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or the equivalent path on Windows. The Atlassian one-click install adds an entry under mcpServers that points at the Atlassian-hosted MCP endpoint. You restart Claude Desktop and the server appears in the connected-tools menu.

Step three: OAuth

On first call, Claude Desktop pops an OAuth flow. You sign into your Atlassian Cloud workspace, consent to the permission scopes the server requests (read issues, write issues, read Confluence pages, etc.), and return to Claude. The OAuth token is stored on your machine and the MCP server holds it for the lifetime of the connection.

Step four: verify

Ask the agent something the Atlassian MCP can answer. "List the last five Jira issues I commented on" is a good first probe. The agent calls one of the Atlassian MCP tools, gets a response, and surfaces a list. If the list looks right, the install is good. If you see an authentication error, the OAuth scope is wrong; revoke and reconsent.

Total time for the install-and-verify loop: ~6 minutes if you have the Atlassian credentials handy. We've done this in front of audiences as a live demo more times than we can count and the only common failure mode is a corporate Atlassian Cloud that requires admin approval for new OAuth apps — in which case the install fails at OAuth and you need a workspace admin to approve.

Trace a Single Call End-to-End

Now the substance. We trace one tool call — the agent creating a Jira issue from a Slack message — through every layer so you can see who is doing what. This trace matters because most operator confusion about MCP collapses the moment you have a clear picture of what runs where.

The user's request

A user in Slack types: "Hey @claude, create a Jira bug in PROJ for the issue Sarah just reported in this thread — payment widget crashes when CVC is left blank." The Slack-Claude integration delivers this message to the agent.

Agent reasoning (step one — model side)

The agent (Claude Sonnet 4.5 in this example) sees the message plus the system prompt plus the full list of available tools — which now includes the Atlassian MCP's create_issue tool because Atlassian MCP is connected. The model decides this is a "create Jira issue" task. It selects create_issue and constructs the arguments.

What the model produces is a JSON tool-call payload, roughly:

{
  "tool": "atlassian.create_issue",
  "arguments": {
    "project_key": "PROJ",
    "summary": "Payment widget crashes when CVC is blank",
    "description": "Reported by Sarah in #payments-bugs thread...",
    "issue_type": "Bug",
    "priority": "High"
  }
}

The agent runtime — Claude Desktop, or the Claude API host, or the Slack-Claude integration's middleware — receives this payload. The model itself has done its job: it produced a structured intent. Everything after this is plumbing.

The host dispatches to the MCP server (step two — host side)

The Claude host looks up atlassian.create_issue in its connected-server registry, finds it's served by the Atlassian MCP process, and sends a JSON-RPC request over the MCP transport. For the Atlassian MCP, the transport is typically streaming HTTPS to Atlassian's MCP gateway. For a locally-installed MCP server (e.g., a self-hosted custom server), the transport is typically stdio.

The host's job here is purely routing. It does not understand Jira, Atlassian, or what a "project" is. It knows that the tool named atlassian.create_issue is served by a specific MCP server and it forwards the arguments verbatim.

The MCP server translates to the vendor API (step three — server side)

The Atlassian MCP receives create_issue with the arguments. Inside the server's code, this maps to a specific Jira Cloud REST API call: POST /rest/api/3/issue with a body shaped to Jira's REST schema. The server attaches the OAuth token it holds for this user, sets the appropriate Content-Type, and makes the HTTPS call to your-tenant.atlassian.net.

The MCP server is the only component in the trace that knows Jira's REST API exists. It is the translator between the model-native function-call protocol (MCP) and the system-native protocol (Jira REST). Everything specific to Jira — endpoint paths, request shapes, error semantics, retry behavior — lives here.

The vendor processes (step four — vendor side)

Jira Cloud validates the OAuth token's scopes (was this user granted issue-create permission on PROJ?), runs its server-side business logic (project workflows, required fields, custom validators, automation triggers), and creates the issue. Jira returns the created issue as JSON: { "id": "10583", "key": "PROJ-1247", "self": "https://...", "fields": { ... } }.

Notice: every Jira-side guardrail still runs. The MCP server is not a backdoor; it is a client like any other client. If the OAuth scope doesn't allow create-issue on PROJ, Jira returns 403 and the agent sees the error.

The response flows back (step five — back to the agent)

The Atlassian MCP receives Jira's response, shapes it into the MCP tool-response envelope, and returns it to the host. The host returns it to the model. The model now has:

{
  "tool_result": {
    "issue_key": "PROJ-1247",
    "url": "https://your-tenant.atlassian.net/browse/PROJ-1247",
    "summary": "Payment widget crashes when CVC is blank"
  }
}

The model writes its final user-facing response: "Created PROJ-1247: Payment widget crashes when CVC is blank. Link: ..." That reply goes back through the Slack-Claude integration and posts in the thread.

Total elapsed time

Roughly 1.4-2.6 seconds for this end-to-end trace in production conditions, of which most is the round-trip to Jira's servers. Agent decision time is ~400-900 ms, MCP transport is ~50-150 ms, Jira's REST call is ~600-1400 ms, response shaping and final message is ~200-300 ms. If something is slower than 4 seconds, the bottleneck is almost always the vendor's API, not MCP.

What the Server Does vs. What the Agent Does

The reason this trace matters is that operators consistently confuse the boundaries. Here is the clean split:

What the agent (model) does

• Interprets the user's natural-language request.
• Decides which tool to call and constructs the arguments.
• Reads tool responses and decides what to do next.
• Generates the user-facing reply.

What the MCP server does

• Publishes the tool catalog (names, schemas, descriptions).
• Authenticates against the vendor API.
• Translates tool calls into vendor-specific API requests.
• Translates vendor responses back into structured tool results.
• Handles vendor-specific edge cases (rate limits, pagination, retries).

What the host (Claude Desktop, Cursor, etc.) does

• Manages the connected-server registry.
• Routes tool calls to the right server.
• Surfaces tool catalogs to the model.
• Provides the user-facing UI (chat, approval prompts, audit logs).

What the vendor API does

• Enforces authorization and permissions.
• Runs business logic and workflows.
• Stores and returns data.

This separation has practical consequences. If the agent picks the wrong tool — that's a model problem, fix it with better prompting or better tool descriptions. If the tool's arguments are malformed — also a model problem. If the call fails with 403 — that's a vendor-side authorization problem; fix the OAuth scopes. If the call hangs — vendor-side latency. If a known-good call fails to even reach the vendor — MCP-server problem; check the server's logs. If the tool catalog is missing or wrong — server-side; the server is publishing the wrong schemas. If the same agent works in Claude Desktop but not in Cursor — host-side configuration issue. Knowing where to look saves hours per incident.

Five Named MCP Flows You Will Build

The flows below are pulled from production-installed agents we've observed in May 2026. Each names the official MCP servers involved and the trigger.

One: Atlassian + Slack ticket triage

Slack message in a #bugs channel triggers the agent. Agent reads thread context (Slack MCP), creates a Jira issue with the right project key and labels (Atlassian MCP), posts back the issue link to the thread (Slack MCP). Total elapsed time: ~3-5 seconds. Replaces a manual copy-paste step that previously took the on-call engineer 60-120 seconds per bug.

Two: Stripe + Notion revenue snapshot

Scheduled daily at 9am. Agent queries Stripe MCP for yesterday's net new MRR and churned MRR, queries Notion MCP for the company's revenue tracker page, updates the page with the day's numbers and an annotation if any number deviates more than 2 sigma from the trailing 30-day mean. Replaces a manual finance-team report.

Three: HubSpot + Stripe account-status sync

Triggered when a HubSpot Deal stage changes to "Closed Won." Agent reads Deal contents (HubSpot MCP), creates a Stripe Customer and Subscription with the right plan and trial dates (Stripe MCP), writes back the Stripe customer ID to the HubSpot Deal (HubSpot MCP). Replaces a manual sales-ops handoff.

Four: GitHub + Linear release-notes assembly

Triggered weekly. Agent queries GitHub MCP for all merged PRs to main in the last seven days, queries Linear MCP for any tickets those PRs reference, assembles a markdown release-notes draft, opens a PR with the draft for human review. Replaces a tech-writing hour per week.

Five: Cloudflare + Vercel infrastructure incident response

Triggered by a PagerDuty alert. Agent queries Cloudflare MCP for current traffic patterns at the edge, queries Vercel MCP for recent deployments, identifies whether the incident correlates with a deploy, posts the analysis to Slack (Slack MCP) with a recommended action. Replaces five minutes of manual log-and-deploy-history correlation.

When MCP Doesn't Fit

MCP is not always the right packaging — Lesson 4 of this chapter covers the decision tree. Three short cases where you would not use MCP:

• One-time scripts. If you need the agent to do one thing once, a direct tool call inside your agent framework is faster than installing a server.
• Highly custom internal systems where no MCP server exists. Either build a custom MCP server (and pay the upfront cost) or wire the system directly into your agent. The decision is reuse-driven: if more than one agent will use it, build the server.
• Hard real-time systems with sub-100ms requirements. The MCP transport overhead is small but not zero. For very latency-sensitive flows, in-process tools beat MCP.

The Zapier MCP Fallback

For SaaS systems that don't have a first-party MCP server, Zapier MCP is the practitioner's universal adapter. The Zapier MCP host wraps Zapier's ~8,000 app connector library and exposes any of them as MCP tools on demand. You authenticate Zapier once, declare which Zapier apps the agent should see, and the Zapier MCP publishes those connectors as tools to your agent host.

Trade-offs: Zapier MCP adds a hop, which raises latency to ~600-1200ms per call versus ~150-400ms for a direct MCP server. Zapier's per-task pricing also applies — each agent tool call counts as a Zapier task. For high-volume flows this gets expensive fast (see the L2 "$60,000 task threshold" lesson). But for low-volume, long-tail integrations, Zapier MCP fills the official-server gap.

Installing Five Servers in an Afternoon

For a builder onboarding an agent to a new company in May 2026, the typical install path is:

1. Inventory: which 5-15 SaaS systems does the agent need to talk to?
2. Filter: which of those have official MCP servers from the list above?
3. Install official MCP servers for the ones that do, in order of importance to the agent's job.
4. For systems without an official MCP server, decide: build a custom server (if reused), wire via the agent framework directly (if one-off), or use Zapier MCP as a temporary adapter.
5. For each server installed, do an end-to-end trace like the Jira example above to verify the wiring works.

A practitioner team we observed in April 2026 brought a new customer-success agent online with five official MCP servers (Salesforce, Slack, Notion, Atlassian, Stripe) in a single afternoon. The agent went from zero tools to ~225 connected tools, OAuth-scoped to a single service account with read-mostly permissions, in roughly four hours including the verification traces.

Key Takeaways

• MCP is a JSON-RPC-based open protocol Anthropic released in November 2024 and that the industry standardized on through 2025. As of May 2026, it is the de-facto agent-to-external-system standard. One MCP server runs unchanged inside Claude Desktop, Cursor, Windsurf, Claude Code, ChatGPT, and Zapier MCP.
• The May 2026 official-server list (vendor-maintained MCP servers): Salesforce, ServiceNow, SAP, Atlassian, GitHub, Slack, Box, HubSpot, Notion, Stripe, Cloudflare, Vercel. Plus Zapier MCP as the universal-fallback meta-server wrapping ~8,000 connectors.
• An MCP server exposes three things: tools (callable functions with JSON schemas), resources (read-only context), and prompts (reusable templates). The agent calls tools by name; the server translates to the vendor API.
• Trace a single call end-to-end: user request → agent picks tool and constructs arguments → host routes to MCP server → server translates to vendor REST call → vendor processes → response shapes back through server, host, and agent → final user reply. Typical latency: 1.4-2.6 seconds, most of it in the vendor's API.
• Clean responsibility split. Agent decides what to do. MCP server knows how to talk to the vendor. Host routes between them. Vendor enforces authorization. Confusion vanishes once these are separated.
• Install pattern: locate the server on the vendor's domain (atlassian.com/mcp, stripe.com/mcp, etc.), paste the one-click config into your host, OAuth into your account, verify with a known-good call. Six minutes per server when credentials are at hand.
• Five real flows: Atlassian+Slack ticket triage, Stripe+Notion revenue snapshot, HubSpot+Stripe account-status sync, GitHub+Linear release-notes assembly, Cloudflare+Vercel incident response.
• Skip MCP when: it's a one-time script, the underlying system is so custom that nothing exists and you won't reuse the connector, or your latency requirement is sub-100ms.
• Zapier MCP is the universal-fallback adapter for SaaS systems without first-party servers. Adds latency and per-task cost; use for low-volume long-tail integrations.
• A practitioner team brought a new customer-success agent online with five official MCP servers (Salesforce, Slack, Notion, Atlassian, Stripe) in one afternoon — ~225 connected tools, OAuth-scoped service account, four hours including verification.