MCP, From Pidgin to Protocol

Before MCP, AI integrations were an N-by-M graveyard. Five AI clients times twenty internal systems meant a hundred bespoke adapters: Claude-to-GitHub, Cursor-to-Postgres, ChatGPT-to-Linear, internal-agent-to-Slack, and a pile of JSON schemas rotting in five repos. Every model talked to every tool through a different tunnel that someone had to maintain forever.

MCP is an open protocol for connecting AI applications to external capabilities. It can reduce the number of bespoke client adapters when several compatible hosts need the same integration. Adoption counts do not establish suitability or security for a particular deployment.

This is the companion piece for MCP. Where the RAG article walked retrieval up five floors of understanding, this one walks the protocol — the new lingua franca for AI talking to the world — from a first shared word to its diplomatic frontier. By the time you reach the top, you'll know what MCP is, when to use it instead of REST or vendor function calling, every server worth running, every alternative worth knowing about, and the failure modes most teams discover the hard way.

REST or MCP? The decision in 60 seconds

Before you reach for MCP, ask the question that matters:

Does standardized discovery and interoperability across hosts justify an additional protocol layer?

Use a direct API or SDK when you control the integration and that interface meets the requirements. This works for ordinary services and agent workflows alike. A human chat session is not the deciding boundary.

Consider MCP when supported hosts need a common way to discover and invoke capabilities. Those hosts can be interactive clients, unattended agents or durable applications. Verify the specific capabilities and authorization behavior required on both sides.

The USB-C analogy earns its keep: REST is internal wiring. MCP is the port on the outside. You don't replace the wiring with USB-C. You expose one standard socket when many things need to plug in.

Yes, both are protocols. Here's what MCP actually adds.

MCP defines a shared interface for exposing tools, resources and prompts to compatible clients. It can wrap an existing API; it does not replace that API’s domain model, authorization or reliability work.

REST is an architectural style, GraphQL defines a query language and execution system, and MCP specifies an application protocol. The useful comparison is what each interface contributes to the integration.

Standardized self-description at connection time.

Under the versioned protocol, clients and servers initialize and negotiate capabilities. A server that advertises tool support exposes tools/list; tools are not mandatory for every server. Tool lists can be paginated and reflect the caller’s authorization. The host decides how to expose the available descriptions and schemas to the model.

// AI host on connection: POST /mcp { "method": "tools/list" }
// MCP server returns:
{
  "tools": [
    {
      "name": "linear.search_issues",
      "description": "Search Linear issues by query string. Returns matching issues with id, title, state, assignee.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query":   { "type": "string", "description": "Search query (free text or Linear filter syntax)" },
          "limit":   { "type": "integer", "description": "Max results", "default": 25 }
        },
        "required": ["query"]
      }
    },
    {
      "name": "linear.create_issue",
      "description": "Create a Linear issue in a given team.",
      "inputSchema": { /* ... */ }
    }
  ]
}

Direct APIs offer several workable approaches to describing their capabilities. Their suitability depends on how much of the client and integration you control.

Option 1 — the AI already knows the API. Linear's docs were in the model's training set. Maybe accurate. Maybe stale. Maybe missing the v2 endpoint you actually need. No guarantees, no introspection, no way to know what the model knows.

Option 2 — you hand-write function-calling specs. For every endpoint you want the AI to call, you write the JSON-schema yourself — and you write it again for OpenAI's function-calling format, again for Anthropic's tools API, again for Gemini, again for whatever ships next. Per AI host. Per API change. Forever.

Another option is to generate client/tool definitions from a versioned OpenAPI or GraphQL schema. MCP standardizes a different discovery interface; it does not make generated schemas or direct SDKs inherently unreliable.

A server publishes reusable capability descriptions through MCP. Compatible hosts consume the capabilities supported by their negotiated version and permitted for the caller. Discovery does not remove the implementation or authorization work.

A compatible host can discover a newly exposed tool without a bespoke adapter for that tool. The server still needs an implementation, authorization rules and a compatible schema; the host may require capability refresh or user configuration. Discovery reduces some integration work rather than eliminating it.

Discovery is one reason to choose MCP. It is not a guarantee that every client can safely use every returned tool or that a REST API cannot publish a discoverable schema.

And MCP is more than just tools/list. It bundles the full agent-to-system surface: tools/call for actions, resources/list + resources/read for content the AI should read (files, db rows, docs), prompts/list for reusable prompt templates the server suggests, standardized OAuth 2.1 auth, standardized transport (stdio for local, Streamable HTTP for remote), JSON-RPC error format, and server-pushed notifications when something changes. One protocol, one shape, every server.

The USB-C analogy isn't that the cable carries data — REST does that fine. It's that plugging in performs a handshake — the device announces "I can do these things, here's the spec" — and the host adapts without needing a custom driver per device.

The Linear / Claude Code trap

This is where people get tangled. Linear ships both: a durable GraphQL API and a hosted MCP server at mcp.linear.app/sse. You ask Claude Code to integrate Linear into your project. Claude Code says: use Linear's API key and GraphQL API. The rule seems to break. Claude Code is an AI host. Linear has MCP. Why isn't the answer MCP?

Because Claude Code is two things at once.

Claude Code can consume MCP capabilities while it operates as an agent host. Other MCP clients can run unattended or remain active independently of a human conversation.

When building a durable Linear integration, a direct SDK or GraphQL call may be the simplest design. A durable MCP client is also possible. Choose according to ownership, required interoperability, authorization, failure handling and deployment constraints.

The distinction is the interface contract and operating requirements, not whether a human is currently chatting.

For an interactive board query, an existing MCP integration can be convenient. For a controlled deployment pipeline, a vendor SDK can be convenient. Neither example establishes a universal rule.

Code-side, the contrast is one line per side:

// REST / GraphQL / SDK — your code calls the system later (deploys, CI, jobs)
export async function createLinearIssue(input) {
  return linearClient.issueCreate(input)
}

// MCP — you expose a capability; compatible clients call it in interactive or unattended workflows
server.tool('linear.search_issues', { query: 'string' }, async ({ query }) => {
  return linear.searchIssues({ query })
})

Many serious teams need both. A SaaS product can use REST internally while exposing MCP so power users can bring Claude or Cursor to the same data. An internal platform team can keep GraphQL for production automation and ship MCP for engineers asking questions in their IDE. Different surfaces for different moments.

Choose MCP for a useful standardized capability interface; choose a direct API when that is sufficient. Both can support long-lived automation.

Floor 1 — First Word (ELI5)

An AI model is like a very smart kid locked in a room with no hands. MCP is a standard way to give it safe, labeled doors to things outside the room: files, calendars, GitHub, databases, browsers, support tickets. The important part isn't magic intelligence. The important part is that every door works the same way, no matter which AI is opening it.

TL;DR (engineer level)

Floor 2 — What problem MCP actually solves

Model capability and integration quality are separate constraints. Models can still make reasoning and factual errors, while missing context or poorly scoped tools introduce additional failure modes.

The product is no longer the model. The product is the model plus context plus permissions plus actions plus audit. A model that can't read your repo, query your tickets, inspect production logs, or act inside approved boundaries is just a haunted autocomplete box. RAG solved part of this — the read side. MCP solves the other part — the read-and-write side, the part where the model actually does things in the world.

Why now? Because the integration tax was about to crush the ecosystem. Every IDE, every chatbot, every agent framework, every internal AI tool was inventing its own way to plug into the same handful of systems. GitHub. Slack. Jira. Postgres. Filesystem. Browser. The math was unsustainable: N AI clients times M integrations, and every cell in the matrix was someone's quarterly OKR.

MCP gives systems and AI hosts a shared integration interface. A system exposes an MCP server; a compatible host can discover and invoke the server capabilities supported by the negotiated protocol and permitted for the caller. A common interface can reduce adapter work, but compatibility and operational controls still need verification. Decide which capabilities the AI may use and under what conditions.

Floor 3 — How it actually works

MCP has three roles: host, client, and server. The host is the AI application — Claude Desktop, Cursor, VS Code with Copilot, an OpenAI Agent, your internal shell. The MCP client is the connector inside that host. The MCP server is the program exposing context and actions. One host runs one client per server.

The protocol revision matters. The 2025-11-25 specification documents initialization and capability negotiation; HTTP session behavior depends on the transport and implementation. Verify the negotiated version rather than assuming every client and server has the same lifecycle.

Two transports matter today. Stdio is local: the host launches the server as a subprocess and talks to it over standard input and output. This is why every bad MCP install guide begins with "npx -y something something." Streamable HTTP is the production path: POST and GET to one endpoint, optional Server-Sent Events for streaming, support for resumability, session headers, and standard HTTP auth. It replaced an older HTTP+SSE transport that still haunts compatibility layers.

The server exposes three primitives:

• Tools — model-invoked functions. create_issue, query_database, open_browser, search_docs.
• Resources — readable context. Files, docs, database rows, logs, objects.
• Prompts — reusable templates and workflows the server publishes. Underrated.

The client exposes three primitives back. Roots negotiate filesystem boundaries. Sampling lets the server ask the client to run model inference on its behalf — the server gets model judgment without owning API keys. Elicitation lets the server ask the client to collect input from the user. These are powerful and dangerous. Treat them as loaded weapons, not plugin candy.

Tool-selection quality needs evaluation. Naming, descriptions, overlapping functions and the exposed tool set can affect results. Add capability search or selective loading when measurements justify it, rather than treating a particular tool count as a universal failure threshold.

The server landscape (2026, opinionated)

Reference servers (official, learning material)

The official modelcontextprotocol/servers repo distinguishes live reference servers from archived historical ones. The live set: Everything (a protocol testbed), Fetch, Filesystem, Git, Memory, Sequential Thinking, Time. Archived historical examples that the ecosystem still copies the shape of: AWS KB Retrieval, Brave Search, GitHub, GitLab, Google Drive, Google Maps, PostgreSQL, Puppeteer, Redis, Sentry, Slack, SQLite. Honest take: reference servers are learning material and primitives, not enterprise architecture. Filesystem and Git are useful. Production teams should prefer vendor-maintained servers.

Vendor-maintained servers (where this becomes real)

Honest take: vendor-hosted remote MCP is what makes the protocol survivable. Local npx toys got MCP adopted. Remote OAuth-backed servers make it enterprise-relevant.

Clients (the host applications)

Honest take: client support is broad but not equivalent. "Supports MCP" can mean tools only, no prompts, weak resources, no sampling, broken OAuth, no dynamic discovery, or terrible approval UX. Always ask the precise capability checklist before you trust the marketing.

SDKs

Choose an SDK using its current support status, protocol coverage, release history and deployment fit. The official SDK directory is the source for maintained implementations; this article does not assign permanent support tiers to language ecosystems.

Registries and marketplaces

The official MCP Registry launched in preview on September 8, 2025 as a catalog and API for server metadata. Its publishing documentation describes namespace-based authentication. This helps establish publishing authority for a name; it is not a security audit of the implementation. Inspect the code or service, requested permissions and data boundaries independently.

Documented ecosystem examples

The following primary references describe public capabilities and ecosystem infrastructure. They do not establish that every integration is configured safely or that every advertised workflow is deployed in production.

Should I use MCP? A decision tree

Use these questions to compare integration options against the actual consumers, workflow and operating requirements.

1. Will more than one AI client use this integration? Consider MCP when compatible hosts benefit from shared discovery; verify the capabilities they require.
2. Is the integration for normal software clients too (humans, services)? → Build a REST API or OpenAPI surface. Add an MCP wrapper later if agent demand shows up.
3. Does the vendor already ship an SDK that handles auth, retries, pagination, webhooks, and domain objects? → Use the SDK. Wrap with function calling locally. Don't reinvent.
4. One agent app, three to ten tools, one model provider you control? → Direct function calling may suffice for a controlled tool set. Compare its maintenance and portability requirements with MCP.
5. Is the workflow strictly deterministic — same input, same call, every time? → Queue, workflow engine, or direct API. Don't put a model in the middle.
6. Otherwise: Prototype MCP when it supplies a concrete integration benefit. Start with one server and a compatible host, test the workflow, and configure the authentication and authorization required for remote access.

Brutal rule: if your MCP server is just curl with theatrical lighting, you probably built the wrong thing. The best MCP servers are not API wrappers — they're opinionated capability products with prompts and tools aligned around real workflows.

Alternatives — when each one wins

MCP isn't the only way to plug an AI into the world. Five alternatives are worth knowing, with clear when-each-wins logic.

Applications can combine MCP interfaces, direct vendor SDKs and an agent framework. These components address different responsibilities; choose and connect them according to the workflow rather than aiming for a pure MCP architecture.

Floor 4 — Advanced (the production-grade patterns)

OAuth 2.1 and the auth problem

Remote MCP lives or dies on auth. The current authorization spec is built around OAuth 2.1-style flows for HTTP transports — the MCP server acts as a protected resource, clients discover authorization metadata via a well-known endpoint, dynamic client registration and client metadata documents exist for interoperability. This is good. It is not solved. Enterprise auth still wants SSO, device posture, scopes per tool, audit, revocation, and policy engines. Most of that lives outside the MCP spec, in the surrounding identity stack. The companion piece on workload identity federation covers the part of this story that MCP itself doesn't address.

Multi-server orchestration and the tool overload problem

Connecting many servers can expose more tool descriptions than a workflow needs. Evaluate selective loading, namespacing, tool search or a gateway when they address measured context, routing or access-control problems. Compare their operating cost and failure modes with a smaller fixed tool set. Capability discovery is one design option, not a requirement that every deployment must adopt.

Sampling, roots, and elicitation — the dangerous primitives

Sampling is under-discussed. It lets a server ask the client to run model inference, with text or audio or image content. Useful when the server needs model judgment but shouldn't hold API keys. Also a security nightmare if the client can't clearly show the prompt, the model, the data exposure, and the result path.

Roots are the filesystem boundary primitive. They're not sandboxing — they're a negotiated list of places the server may operate. Good clients enforce them. Lazy clients merely confess them. Production deployments need actual sandboxes underneath.

Elicitation lets the server pause and ask the client to collect user input mid-flow. Powerful for human-in-the-loop workflows. Equally powerful for malicious servers to extract sensitive information through plausible-looking forms.

Resource subscriptions and living context

Static tool lists are fine for demos. Production systems change: tickets update, logs stream, schemas evolve, files move. Resource subscriptions and list-change notifications matter for living context. If your MCP server pretends nothing changes between calls, you're shipping a postcard, not a system.

Federation — the next fight

Not "one MCP server," but server portals, gateways, private registries, downstream marketplaces, enterprise allowlists, and capability brokers. This is where Cloudflare's MCP portal direction matters more than another toy server — turning MCP from a per-machine plumbing into a per-organization fabric is what makes it operationally serious.

Floor 5 — Cutting edge (politics, protocols, and failure modes)

MCP is Anthropic-born — that matters and is now contained

Anthropic’s December 9, 2025 announcement says it donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. That is the documented governance transition. Open governance can support interoperability, but it does not guarantee adoption, longevity or the behavior of any implementation.

MCP is LSP for AI, not REST 2.0

LSP offers a useful analogy: a common interface can let different clients reuse a server’s capabilities. The analogy is about interoperability, not identical wire protocols or security properties. MCP tool execution still requires its own authorization and isolation design.

MCP is not A2A

MCP is agent-to-tool-and-context. A2A — agent-to-agent — is a different protocol for autonomous services to negotiate tasks, status, delegation, and handoff. If two services need to coordinate as peers, that's not naturally MCP work. You can fake it with tools. You should not build your whole agent society out of fake tools. Google's protocol guide positions MCP alongside A2A, AP2 (agent payments), and A2UI (agent-rendered UI) — all complementary, none interchangeable.

Unsolved gaps as of May 2026

Tool metadata can describe intended behavior and risk. Treat those descriptions as claims from the server, not as enforcement: authorization, approvals, isolation and output validation remain separate controls.

Security failure modes (not theoretical)

A malicious MCP server can lie in tool descriptions. It can request broad scopes. It can exfiltrate context through tool outputs. It can poison prompt templates. It can leak tokens from environment variables. It can smuggle commands through unsafe subprocess handling. Supply-chain risk is brutal because most installs are an npx or uvx command copied from a directory page, and most directories don't audit the underlying code. The official spec's security section explicitly warns that tool descriptions are untrusted and that hosts must obtain consent for data access and tool execution. Almost nobody reads it.

The future: capability negotiation with teeth

Evaluate proposed security and discovery features against the specific released protocol and client implementation. A roadmap, a specification proposal and an implemented control are different evidence. Tool annotations and signed metadata, where available, do not by themselves enforce authorization.

When NOT to use MCP

• A single internal function call. Use function calling.
• To hide a bad API. Fix the API. MCP can't paper over a broken contract.
• Destructive tools without scoped auth, audit logs, approval gates, idempotency, and rollback. The blast radius is too large.
• Random community servers running on developer laptops with broad filesystem and token access. Read the source first. Or run them sandboxed.
• Connecting every server to every agent. Tool bloat is a silent accuracy killer. Curate.
• Deterministic workflow orchestration. Use a queue, a workflow engine, or a direct SDK. Don't put a model in the middle of "every step has to fire exactly once."
• Treating roots as sandboxing. They're boundaries only when the client enforces them. They're not jails.
• An MCP server with vague tool names. run_query is a loaded gun. read_only_customer_invoice_summary is a tool.
• Believing registry presence means safety. A registry entry is a gravestone label, not an autopsy.

Hot takes nobody else will tell you

1. The best MCP servers are not API wrappers

They're opinionated capability products. "create_issue" is a function. "triage production incident with the on-call playbook attached" is a product. The first one ships in a weekend. The second one earns its place in your stack.

2. Evaluate the tool surface

Adding overlapping or poorly described tools can make selection harder, but every additional tool does not necessarily reduce accuracy. Measure representative tasks, limit exposed permissions and investigate wrong-tool selections.

3. Local stdio made MCP popular, but remote MCP made it enterprise-relevant

Local stdio and remote HTTP serve different deployment needs. Local processes need constrained host access; remote services need authenticated clients and service-side authorization. Either can be part of an engineered system when its boundaries are explicit.

4. Prompts may end up more valuable than tools

Tools do actions. Prompts encode operational judgment. The MCP spec treats them as equal first-class primitives, but the ecosystem still over-indexes on tools because they're concrete. A great server publishes both — tools for what to do, prompts for when and why.

5. "We support MCP" is now marketing fog

Support varies by protocol version and client. Ask which primitives, transports, authorization flows and operational controls the exact deployment supports. A product-level MCP badge is not that compatibility matrix.

6. Registries authenticate names, not behavior

A verified namespace means "this is probably the claimed publisher." It does not mean "this server will not exfiltrate your tokens." Registry entries are gravestone labels, not autopsies. Treat installation like installing an unsigned binary, because that's what you're doing.

7. MCP doesn't remove integration work — it moves it to the right boundary

Every "we'll just plug in MCP" decision underestimates auth, observability, and capability curation. MCP gives you one shared protocol; the work that used to be in a hundred adapters now lives in fewer servers, but it's still real engineering. The win is concentration, not elimination.

The bigger picture

Retrieval supplies context; MCP can expose retrieval and other capabilities through a shared interface. Neither determines what every future application will adopt. The relevant test is whether the integration improves a defined workflow under its operational constraints.

Sinapt explores a shared knowledge layer with interfaces for different agent runtimes. MCP is one proposed interface, alongside direct application access. Compatibility and useful retrieval still need to be demonstrated in the implementation.

If you take one thing from this article: MCP isn't a protocol you adopt. It's a protocol you grow into. Start with one server. Wire it to one client. Add OAuth before you put it on the internet. Curate your tool surface ruthlessly. Trace everything. Read the spec's security section more than once. The teams that win the next two years are the ones whose agents can act safely, not the ones with the longest tool list.

Primary references: versioned protocol architecture, tools and capability declaration, and the official SDK directory. Check the revision supported by the deployed host. Ecosystem references checked September 20, 2026: registry launch, registry publishing authentication, and Anthropic’s AAIF donation announcement.