Frontier spoke

Model Context Protocol — the open standard for agent-to-service communication

MCP is the open standard that lets AI agents talk to external services through a consistent interface — tools, resources, prompts, all behind a uniform API. Anthropic published it in late 2024; by 2026 it has tens of thousands of community servers, support from OpenAI, Google, Microsoft, and every major IDE-integrated agent, and is the de facto answer to 'how does my service become agent-callable?' Shipping an MCP server is one of the highest-leverage moves a SaaS product can make for the agent shift.

By Chris Mühlnickel · 2026-05-16

What is Model Context Protocol (MCP)?

MCP is an open protocol — initially proposed by Anthropic in November 2024 — that standardizes how AI agents discover and interact with external tools, data sources, and capabilities through a uniform client-server interface using JSON-RPC over stdio, HTTP, or SSE transports.

By the numbers

Why it matters

Every AI agent needs a way to call services beyond text generation. Pre-MCP, every agent platform had its own plugin system — ChatGPT Plugins, custom integrations, vendor-specific frameworks. MCP unifies that: one protocol, one server implementation per service, every MCP-compatible agent can use it. The economics shift from "build N integrations across N platforms" to "build 1 [MCP server](/learn/glossary#term-mcp-server), every platform can use it." That's a step-change in leverage for any service with agent-callable actions.

Adoption is moving fast — and it's not just Anthropic. OpenAI announced MCP support across ChatGPT and the OpenAI Agents SDK in 2025. Microsoft Copilot Studio, Google ADK, and major IDE platforms (Cursor, Continue, Cline, Zed) all ship MCP client support. The protocol has crossed the "everyone supports it" threshold inside twelve months — the closest historical analogue is OAuth, which took years to consolidate at the same level.

The three primitives are simple but powerful. MCP servers expose three types: tools (functions the agent can call), [resources](/learn/glossary#term-mcp-resources) (data the agent can read), and [prompts](/learn/glossary#term-mcp-prompts) (templates the agent can apply). This trinity covers most agent-service interactions, and the simplicity is what made adoption scale. Tool schemas carry the call-time contract; the MCP client inside an agent platform handles discovery and invocation.

The "everyone gets an MCP server" pattern is the right call for SaaS. Stripe, Notion, Linear, GitHub, Slack, Atlassian, and Cloudflare all ship official MCP servers in 2026. The pattern is straightforward: take your existing API, wrap it in an MCP server with curated tool descriptions, ship it. The engineering cost is days; the upside is being agent-callable from every major agent platform with one server instead of N integrations.

Authorization is the hardest part. Most MCP servers we see ship with weak auth — no auth at all, or a single shared API key. Both create more risk than value. The right pattern is per-agent OAuth scopes (oauth-scope) + capability-level permissions + audit logs + rate limits. Sites that solve auth well differentiate; sites that don't create vulnerabilities. The depth on this lives in MCP Authorization.

Where it's heading

MCP becomes table-stakes for SaaS by 2027. Currently a competitive advantage; on the trajectory to be a baseline expectation. Vendor RFPs for B2B SaaS already include "MCP server availability" as a criterion. Expect that to spread to procurement checklists across most enterprise segments inside eighteen months.

Native MCP support in clouds and platforms. AWS Bedrock AgentCore, Azure AI Foundry, and Google Vertex Agent all ship MCP as a first-class runtime in 2025-2026. Hosting an MCP server becomes a managed-service offering rather than a build-your-own. That lowers the floor on shipping MCP and raises the bar on what "good" looks like above the floor.

The "OpenAPI-as-MCP" gap closes. Today, sites with good OpenAPI specs still need to hand-curate MCP servers for quality. Tooling is emerging to bridge this — auto-generation with better tool descriptions, schema validation, and curation hints. It won't eliminate the curation step but will reduce it significantly. The signal to watch: the first generator that produces servers an agent can actually use well at v0.

Authorization standards converge. Today, MCP auth is implementer's choice (some use OAuth, some use API keys, some use HTTP message signatures). Expect an MCP authorization spec extension that codifies the OAuth + capability-scope pattern by 2027. The Anthropic / OpenAI / Google working group converging on a shared spec is the leading indicator.

WebMCP and server-side MCP coexist. WebMCP (Chrome 146 early preview, February 2026) is the browser-side variant — declarative and imperative APIs for an in-browser agent to call tools directly from the page context. Server-side MCP stays the higher-leverage move for API-anchored products; WebMCP layers on top for browser-anchored ones.

Common mistakes

  • Shipping MCP without authorization. Server exposes tools that can mutate data, anyone with the URL can call them. Don't ship until auth is implemented — see MCP Authorization.
  • Treating MCP as an OpenAPI alternative. They're complementary, not substitutable. OpenAPI describes the HTTP surface; MCP describes the agent-facing surface. Most teams need both.
  • Auto-generating MCP from OpenAPI without curation. The auto-generated tools work but ship with terrible descriptions (Returns a list of objects of type Customer). Agents need contextual descriptions (Use this tool to list active customers when answering questions about who has signed up recently). Rewrite for the LLM-as-reader.
  • One MCP server for the entire product. Better pattern: one MCP server per logical domain. Stripe ships one for payments, one for connect, one for customers. Each server has a focused tool set; agents pick the right one for the task.
  • Not maintaining the MCP server when the underlying API changes. Drift is silent — agents call tools that no longer match the API behavior, fail, and blame the agent. Treat the MCP server as a first-class API surface with its own changelog.

Frequently asked

Does MCP compete with NLWeb? With A2A?

No — they solve different layers. NLWeb is for natural-language interfaces on top of Schema.org markup (agents finding answers in your structured data). A2A is for agent-to-agent coordination. MCP is for agent-to-service — a single agent calling out to your service. All three coexist.

We have an OpenAPI spec. Is that enough?

It's a starting point. Generate an MCP server from the OpenAPI as a v0; then hand-curate the tool descriptions for v1. The auto-generated version 'works' but agents get much better at using it after curation — tool descriptions are read by the LLM at call-time, and generic developer-doc phrasing leaves the model with nothing to reason from.

Which transport should I use — stdio, HTTP, SSE?

HTTP for web-published servers (the common case in 2026). stdio for local / CLI agents (Claude Desktop, IDE integrations). SSE is mostly being deprecated in favor of streamable HTTP.

How do I monetize an MCP server?

Same way you monetize the underlying API — usage-based billing, tiered access, enterprise contracts. The MCP server is an interface to your existing business model, not a separate product.

How do I find which MCP servers exist?

mcp.so, smithery.ai, and PulseMCP maintain public directories; Anthropic also publishes a directory of vetted servers at modelcontextprotocol.io. Community-maintained GitHub repos cover the long tail.

Can I add MCP to a legacy on-prem product?

Yes, but auth becomes more complex. Self-hosted MCP servers are valid; some enterprise vendors (Atlassian Data Center, GitLab self-hosted) ship them for customer deployment. The auth model needs to handle the customer's identity provider rather than a SaaS-style OAuth flow.

Should I expose every API endpoint as an MCP tool?

No. Curate. Pick the 10-20 highest-value agent actions. Adding every endpoint creates noise that confuses agents about what to call — and degrades the call-time signal-to-noise ratio for the rest of your tools.