MCP (Model Context Protocol): the missing AI piece

For two years, connecting an LLM to a real tool — a GitHub repo, a Postgres database, an S3 bucket, a Slack workspace — took artisanal work. Every model had its function-call format, every client (Claude Desktop, Cursor, an internal notebook) its integration pipeline, and every tool its homegrown wrapper. For M models and N tools, you rebuilt M×N bridges. That was sustainable with three models and five tools; it became unmanageable once teams started deploying dozens of agents across dozens of systems.

The hidden cost wasn't just code. It was duplicated security policies (every integration reinvented its permissions), maintenance debt (when a tool's API changed, you had to patch N wrappers), and the impossibility of reusing a tool across clients. A developer who wrote a Slack integration for Claude Desktop couldn't plug it into Cursor without rewriting everything.

MCP (Model Context Protocol), announced by Anthropic in late 2024, attacks the problem at the root. It doesn't define a new model or a new agent framework. It standardises the interface between an LLM host and a tool provider. One integration per tool, usable by any compatible client. Anthropic's metaphor — the "USB-C of AI" — is accurate: a universal connector, a clean contract, and extensibility for future cases.

MCP describes three clearly separated roles. The **host** is the application in which the user interacts with the LLM: Claude Desktop, Cursor, Zed, Claude Code, or your internal agent. The MCP **client** is a component inside the host, responsible for managing connections to MCP servers. The MCP **server** is an independent program that exposes capabilities — tools, resources, prompts — under the protocol. A host can connect several servers in parallel; a server can be used by several hosts.

The transport builds on **JSON-RPC 2.0**, a lightweight, deterministic format. Two modes are supported. **stdio** mode launches the server as a subprocess of the host: simple to deploy, ideal for a developer workstation or a local agent. **SSE/HTTP** mode (Server-Sent Events) exposes the server over the network: essential for sharing a server between several users, machines, or cloud agents. The transport choice doesn't change the server's business logic — only its entry point.

This separation of roles is what distinguishes MCP from a mere "LLM plugin". The server knows neither the model, nor the client, nor the end user. It exposes a stable, documented, versioned contract. The host orchestrates. The model decides. It is an architecture built to last, not to demo.

MCP doesn't stop at exposing "functions". It defines three distinct primitives, each with its own semantics. **Tools** are actions the model may decide to invoke — send a message, create a ticket, run a query. They follow the classic function-calling pattern: name, description, JSON schema of parameters, result returned to the model. It is the most used primitive today.

**Resources** are addressable data the client can expose to the model, on demand or in context. A configuration file, a documentation page, a knowledge-base entry. The key difference from a tool: a resource is read, not executed. It triggers no side effects. That lets a client offer contextual sources to the model without risking unintended actions.

**Prompts** (prompt templates) are reusable templates the server provides. A Sentry server can expose an "analyse this error" prompt, pre-filled with the right context. That turns the MCP server into a library of business know-how, not just a toolbox. Together, these three primitives cover nearly every integration pattern encountered in production.

One year after the announcement, adoption exceeds the most optimistic forecasts. Anthropic maintains some twenty **reference servers**: filesystem, git, GitHub, Slack, PostgreSQL, Google Drive, Puppeteer, Memory, fetch, Sequential Thinking. These servers are open source, auditable, and serve both as production-ready components and reference patterns for the community.

On the client side, the whole developer ecosystem aligned. **Claude Desktop** has supported MCP natively since late 2024. **Cursor** integrated MCP as its primary tool-extension mechanism. **Zed** added it for code assistance. **Claude Code** (Anthropic's agentic CLI) makes heavy use of it to wire up filesystem, git, and bash. Cline, Continue, and other editors followed. This client-side convergence is what turns a promising protocol into an effective standard.

The pivotal moment of 2025 was **OpenAI's endorsement**: in March, OpenAI announced MCP support in the Agents SDK and in ChatGPT. When your direct competitor adopts your protocol, it's no longer an option — it's infrastructure. Today, writing an MCP server means writing an integration that works for Claude, GPT, Cursor, and any compatible agent. The marginal cost of a new client trends towards zero.

The two official SDKs — **TypeScript** (`@modelcontextprotocol/sdk`) and **Python** (`mcp`) — make creating an MCP server trivially simple. In TypeScript, you declare your tools with a Zod schema, implement the handler, and mount the stdio transport in four lines. In Python, the `@mcp.tool()` decorator serves as the declaration. No glue code, no network plumbing to write yourself.

The transport choice boils down to one question: is your server local to one workstation, or shared? For a developer tool (local repo introspection, queries against a test database), **stdio** is the right answer — zero network configuration, automatic launch by the client. For an enterprise tool (business API, production database, CRM), **SSE/HTTP** wins: centralised deployment, authentication, monitoring, and the ability to serve several sessions simultaneously.

The security rule to never break: **the server is the keeper of permissions**. It must never expose a raw API key to the model. The model requests an action; the server verifies the user's identity (passed by the host via the context), checks authorisation, executes, and returns the result. A Stripe or AWS key has no business transiting through the LLM's context. It is the server that talks to the external API, never the model directly. That discipline is what lets you deploy MCP in production without turning your LLM into an exfiltration channel.

These three mechanisms aren't competitors — they operate at different layers. Native **function calling** (OpenAI, Anthropic, Google) is the lightest: ideal for a one-off integration, a chatbot with two or three actions, a prototype. No abstraction, no protocol, but no sharing between clients either. **LangChain tools** (or LlamaIndex, or the Vercel AI SDK) add an orchestration layer: parallel execution, retries, state management, integration with chains and agents. Very useful for a complex pipeline inside a single application.

**MCP** shines when the value lies in **multi-client reuse**. You write an MCP server for your internal invoicing API once. It works in Claude Desktop for support teams, in Cursor for debugging developers, in your Slack agent for accounting, and in Claude Code for ops. One contract, several contexts. It is also the only one of the three that standardises capability negotiation and the server lifecycle (initialisation, listing, execution, teardown).

In practice, we recommend: function calling for demos and throwaway scripts; LangChain for full application pipelines; MCP as soon as the integration is meant to serve more than one client, team, or agent. For a studio like VALRY LABS, where every client has its own tool landscape, MCP divides by five the cost of integrating a new agent into the existing stack.

The most powerful production pattern we deploy in 2025 is the MCP **"toolhub"**. A single server, internal to the company, that exposes every business API (CRM, ERP, data lake, tickets, monitoring) behind a unified MCP contract. Any agent — Claude Desktop for marketing, Cursor for dev, a custom support agent — plugs into the toolhub and immediately gets access to the set of tools authorised for its context.

The operational efficiency is immediate. Before MCP, adding a new tool to an agent meant: develop the integration, deploy it, maintain it. With a toolhub, you declare the tool once on the server side, and every compatible agent benefits. The marginal cost of a new agent trends towards zero. So does the marginal cost of a new tool. That's the winning equation: M×N becomes M+N.

The angle that wins over CIOs is **governance**. Because everything goes through the MCP server, you get a complete audit log for free: which user, through which agent, called which tool, with which parameters, at what time. On the security side, the server enforces a centralised RBAC policy — impossible to bypass from the client. On the compliance side, you get a single trace for SOC 2, ISO 27001, or GDPR. MCP is no longer just a developer protocol: it has become an architecture lever for the CIO's office.