MCP as the cross-vendor tool layer

Why you'd careThe problem it solves

You have a capability to ship — let the agent query the reporting warehouse — and two ways to package it. Write a skill describing how to query it, or stand up an MCP server that exposes the query as a tool. The packaging choice looks cosmetic and is not: one of them works when the agent has no database access at all, and the other does not.

The second trap arrives later. Your server works beautifully in the client you built it against. A colleague wires it into a different one and the model behaves as though half the server is missing — because it is. You exposed the schema documentation as an MCP resource, and their client implements tools and nothing else. No error is raised. The tool list is simply shorter than you designed for.

ConceptWhat it is

Model Context Protocol is a wire protocol between a host application and a capability server. The server exposes some combination of three primitives: tools, which the model can call; resources, which are addressable content the client can read; and prompts, which are named templates a user can invoke. In the other direction the protocol also defines client-side features — sampling, where a server asks the host to run a model completion; roots, which tell the server what filesystem scope it has; and elicitation, where a server asks the user a question mid-call.

Transports are stdio for a server running as a local subprocess, and Streamable HTTP for a remote one, with the older HTTP-plus-SSE arrangement still in the wild. Versioning is by dated spec revision. Through revision 2025-11-25 the version was negotiated in an initialize handshake along with each side's capabilities; the current revision, 2026-07-28, removed that handshake, so every request carries its protocol version and client capabilities, and servers advertise theirs through a server/discover call.

Governance moved: MCP started at Anthropic and was contributed to the Agentic AI Foundation under the Linux Foundation in December 2025. It is now wired through OpenAI's Responses API, its Agents SDK and ChatGPT connectors, as well as Anthropic's own surfaces and most serious IDEs.

The boundary against skills is clean and worth memorising as a rule. MCP grants capability — access the agent did not previously have. A skill supplies procedure — knowledge about work the agent could already do. If the answer to "can the agent reach this at all?" is no, you need a server. If it is yes and the agent just does it badly, you need a skill.

How it worksThe mechanics

Under revisions up to 2025-11-25, a session begins with a handshake: client and server exchange a protocol version and a capabilities object, and each side learns which primitives the other actually implements. Revision 2026-07-28 is stateless instead — no handshake and no protocol-level session; each request carries the client's version and capabilities, and the server answers server/discover with its own. Either way, the client then lists what the server offers, and the tool names, descriptions and JSON schemas go into the model's context. When the model emits a call, the client dispatches it, gets a result, and feeds it back as another turn.

Configuration differs by host, but only in shape. A local subprocess server, as a harness config entry:

{
  "mcpServers": {
    "reporting": {
      "command": "uvx",
      "args": ["reporting-mcp", "--warehouse", "prod"]
    }
  }
}

A remote server as a tool on OpenAI's Responses API:

{
  "type": "mcp",
  "server_label": "reporting",
  "server_url": "https://mcp.example.com/mcp",
  "require_approval": "never"
}

Anthropic's Messages API takes remote MCP servers through a dedicated top-level field, mcp_servers, with each server switched on by an mcp_toolset entry in tools, and the feature is beta-gated — read the current header name out of the docs rather than copying one from a blog post, because those strings are dated and rotate.

Three things bite in practice. Uneven implementation: a client may support tools and quietly ignore resources, prompts, sampling and elicitation. Capability negotiation — the initialize handshake on older revisions, server/discover and per-request capabilities on 2026-07-28 — is where this is visible, and almost no UI surfaces it. Test your server in each client you intend to support rather than reasoning from a support matrix.

Locality: a hosted API cannot reach a stdio server on your laptop. Any connector-style integration is remote-URL-only by construction. If your server needs local filesystem access, it belongs in a local harness.

Context cost: every tool's name, description and schema sits in the window on every turn. A sixty-tool server is a five-figure token tax before the user has typed anything, and it measurably degrades selection accuracy. Split the server or filter the tool list per session.

At a glanceSee it

One MCP server reaching three clients, and where the non-tool primitives quietly fall away.

Where it runsSurfaces and availability

The clean two-cluster story is gone. Local harnesses still take any transport, but hosted services no longer stop at public URLs: OpenAI ships a Secure MCP Tunnel, Anthropic's Managed Agents have MCP tunnels in research preview, and Foundry Agent Service accepts private VNet endpoints. What remains uniformly true is the primitive ceiling — Anthropic's connector supports tool calls only, and coverage of resources, prompts and sampling varies everywhere else. So still build HTTP-first with tools as the only primitive you depend on, and treat the rest as enhancements some clients will not render. But stop assuming a private server rules a hosted surface out; check whether that surface has a tunnel before you re-architect around it.

ExampleIn the real world

A data team ships reporting-mcp. It exposes three tools — run a read-only query, describe a table, list recent dashboards — and, because the spec allows it, publishes the warehouse's schema documentation as MCP resources so the model can read table definitions without burning a tool call.

In Claude Desktop it is excellent. The model reads a schema resource, writes correct SQL on the first attempt, and calls the query tool once.

An engineer wires the same server into a hosted API integration and query quality collapses. The model guesses at column names and retries three times. Nothing errors, nothing logs. The client implements tools and does not implement resources, so the schema documentation was never in the picture; the capability exchange said so and no UI showed it.

The fix is a design decision, not a bug fix: promote the schema documentation to a tool called describe_table, so the capability travels wherever the protocol's lowest common denominator does. The resources stay for the clients that support them.

Then a skill goes on top — how we query the warehouse: always filter on the partition column, never scan the events table without a date range, prefer the dashboard list over guessing at metric names. The server made the warehouse reachable. The skill made the model use it like someone who works there.

Not thisWhat it is often confused with

• Not a skillMCP grants capability; a skill supplies procedure. They compose: the best pairing is a small server exposing clean tools plus a skill telling the model how to use them well.
• Not an agent frameworkthe protocol defines how a capability is described and invoked. It has no loop, no planner, no memory and no opinion about when a tool should be called.
• Not a uniform guarantee"supports MCP" almost always means tools. Resources, prompts, sampling and elicitation are separately implemented, and transports differ. Test a server in each client rather than reading a badge.
• Not RAGa retrieval tool can be served over MCP, but MCP is the connection, not the retrieval design. Chunking, embedding and ranking are still entirely your problem.
• Not a plugin formatplugins are how a bundle of skills, commands and server configs is distributed to a team. MCP is what one of those servers speaks once it is running.

LimitsWhen not to reach for it

• The capability is one HTTP call the agent could already make.A script inside a skill is less infrastructure, less latency and no context tax.
• One harness, one machine, one function.A local function tool or a shell script is simpler than a server, a config entry and a lifecycle to supervise.
• You are about to expose sixty tools.Every schema is in context on every turn, and selection accuracy falls as the list grows. Split the server, or filter what each session sees.
• The problem is that the model uses the tool badly.That is a description-and-procedure problem. Sharpen the tool descriptions and write a skill; adding another server will not help.
• The server must run locally but you are calling a hosted API.A connector cannot reach your laptop. Either host the server or make the call from your own code.

RelatedGo deeper