What is the Model Context Protocol?

Every team that ships an AI feature hits the same wall: the model is capable, but it cannot see your data or act on your systems. The Model Context Protocol (MCP) is the open standard that closes that gap — a single, reusable way to hand a model your tools, files, and live data without rewriting the wiring for every new model or feature.

MCP is an open protocol that standardises how an application supplies context and capabilities to a large language model. Instead of bolting bespoke "function calling" glue onto each integration, you expose your data sources and actions through one well-defined interface, and any MCP-aware model — Claude included — can discover and use them at runtime.

Think of it the way USB standardised peripherals. Before USB, every device shipped its own connector and driver. After it, one port spoke to keyboards, drives, and cameras alike. MCP is that port for AI: write the integration once, and the model on the other end knows how to call it.

Without a shared protocol, connecting models to systems is a combinatorial mess. If you have M models (or model versions) and N internal systems — your CRM, a ticketing tool, a document store, a payments ledger — naive integration means building and maintaining M × N bespoke connectors. Swap a model, and you re-do a column. Add a system, and you re-do a row.

MCP collapses that into M + N. Each system exposes one MCP server. Each model speaks MCP as a client. The two meet at the protocol, so adding a model or a system is additive, not multiplicative. This is the same architectural win that drove USB, language server protocols in code editors, and ODBC for databases.

• Integrations are written once and reused across models, not rebuilt per model.
• Swapping the underlying model — say from Claude Sonnet 4.6 to Claude Opus 4.8 — does not break your tool wiring.
• New systems plug in by shipping a server, with no change to the model side.
• The same server can serve a chat product, an agent, and an internal tool.

MCP has two roles. An MCP server wraps a system — it advertises what it can do and answers calls. An MCP client lives inside the AI application (or the model host) and connects to one or more servers, surfacing their capabilities to the model. Between them sits a transport layer that carries structured JSON-RPC messages.

What a server exposes

• Tools — actions the model can invoke, each described by a name, a human-readable purpose, and a typed input schema so the model knows exactly how to call it.
• Resources — readable data the model can pull in as context, such as files, records, or documents.
• Prompts — reusable, parameterised prompt templates the host can offer to users.

How they connect

For a local integration the transport is typically standard input/output — the host launches the server as a subprocess and they exchange messages over the pipe. For remote or networked integrations, a streamable HTTP transport carries the same JSON-RPC traffic over the wire. Either way the protocol is identical; only the pipe changes.

The flow at runtime is simple: the client connects and asks the server to list its tools; the schemas are passed to the model as available capabilities; when the model decides to act, the client forwards the call to the server, the server executes it against the real system, and the result returns as context for the next step.

Here is the smallest useful server using the TypeScript SDK: it exposes a single tool, declares a typed input schema, and runs over stdio. This is the whole shape — declare the tool, validate inputs, return a result.

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'import { z } from 'zod' const server = new McpServer({ name: 'inventory', version: '1.0.0' }) // One tool: look up stock for a SKU against your real system.server.tool(  'get_stock_level',  'Return the current stock count for a product SKU.',  { sku: z.string().describe('Product SKU, e.g. "LL-1024"') },  async ({ sku }) => {    const count = await inventoryDb.countBySku(sku)    return { content: [{ type: 'text', text: `${sku}: ${count} in stock` }] }  },) // Speak MCP over stdio; the host launches this as a subprocess.await server.connect(new StdioServerTransport())

That is the entire contract. The model never sees your database, your credentials, or your query language — only the tool name, its description, and its input schema. The server stays the trust boundary, which is exactly where access control and validation belong.

MCP turns "an AI that can chat about your business" into "an AI that can operate inside it." The value shows up wherever a model needs live, governed access to systems rather than a stale copy pasted into a prompt.

• Internal copilots that read live records — orders, tickets, accounts — and act on them through audited tools rather than screenshots.
• Customer support agents that resolve, not just summarise, by calling refund, lookup, and escalation tools behind one server.
• Knowledge access over private document stores, exposed as resources so answers cite real internal sources.
• Multi-step automation where a single agent orchestrates several servers — billing, CRM, calendar — through one consistent interface.

Because MCP is part of the Anthropic build surface alongside the Messages API, the Claude Agent SDK, and Claude Code, the same servers you write for an internal copilot can power an agent or a Claude Code workflow without rework. That reuse is where the M + N maths becomes a budget line, not just an architecture diagram. We size most of this kind of work in short, fixed cycles — see how engagements are scoped and priced.

The protocol is simple; the engineering judgement is not. The difference between a demo and a server you can operate under an SLA lives in the details that the spec leaves to you.

1. Tool design — clear names and tight schemas so the model calls correctly the first time, instead of guessing across vague, overlapping tools.
2. Least privilege — each tool reaches only the data and actions it needs, with auth enforced server-side, never in the prompt.
3. Error handling — failures return structured, legible messages the model can recover from, rather than opaque stack traces.
4. Observability — every tool call is logged and traceable, so you can audit what the model did and why.
5. Versioning — schemas evolve without silently breaking the agents that depend on them.

This is where most of the work goes when we build for clients. We design the tool surface, draw the trust boundary, wire the transport, and operate the result — see MCP server development for how that engagement runs. It pairs naturally with AI workflow automation when the goal is an agent that does real work, and with custom SaaS when the server underpins a product.

We are Claude specialists — we build on Claude by default, across the current model family (Claude Opus 4.8, Claude Sonnet 4.6, Claude Haiku 4.5, and Claude Fable 5), all with a 1M-token context window, and available on AWS Bedrock and Google Vertex AI. Because MCP is an open standard, the servers we write are not locked to one model, but our defaults, tooling, and operational experience are deepest on Claude.

If you want context on the broader picture — how MCP fits agents, the Claude Agent SDK, and governed deployments — the related reading below is the place to start.