Model Context Protocol (MCP)

Before MCP, every AI application built its own custom integrations. If you wanted your AI agent to read from Slack, query a database, and update Jira, you had to write separate integration code for each one. Every model provider had a different way of handling tool connections. This meant a lot of duplicated work.

MCP changes this by defining a standard protocol based on JSON-RPC 2.0 over either stdio or HTTP with Server-Sent Events. A tool provider implements the MCP server specification once, and any MCP-compatible AI application can use that tool. An AI application implements the MCP client specification once, and it can connect to any MCP-compatible tool. This is the same pattern that made the web work: standardize the protocol, and everything becomes interoperable.

The protocol covers three main capabilities: tools (functions the model can call), resources (data the model can read, addressed by URI), and prompts (templates for common interactions). A single MCP server might expose all three. For example, a CRM integration might provide tools for creating and updating records, resources for reading customer data, and prompts for common sales tasks.

MCP supports both local servers (running on the user's machine, useful for file system or local tool access) and remote servers (hosted services, useful for SaaS integrations). Authentication in remote MCP uses OAuth 2.1, and the transport layer supports streaming responses for long-running operations.

For enterprise AI development, MCP reduces integration cost and increases flexibility. You can swap AI models without rebuilding your tool integrations. You can add new tools without modifying your AI application's core logic. The ecosystem of pre-built MCP servers has grown quickly, covering GitHub, Slack, Google Drive, Postgres, BigQuery, Notion, and hundreds of other services.

Where MCP isn't the answer: one-off integrations where a direct API call is simpler, or latency-critical paths where the MCP round-trip overhead matters. MCP shines when you have many tools, multiple models, and you want the integration to outlive any one of them. MCP adoption accelerated through 2025 with first-party support from Anthropic, OpenAI, Google, and most major AI dev tools. For teams building AI agents, designing around MCP from the start means integrations stay portable and future-proof.

A mid-sized logistics company wants Claude to help their operations team answer customer questions about shipments. Before MCP, they would have built a custom tool integration coupled to Anthropic's tool-use API. When they later wanted to try GPT-4o for cost reasons, they'd have to rewrite the integration against OpenAI's function calling format.

With MCP, they build one MCP server using the TypeScript SDK. It exposes three tools: track-shipment (by tracking number or PO), get-customer-contract (pulls service-level terms from Salesforce), and estimate-delivery (calls an internal ML model). Each tool is defined with a Zod schema for arguments and a short description. The server is deployed behind their existing auth gateway as a remote MCP server over HTTP+SSE with OAuth 2.1.

Claude Sonnet running in their agent framework connects to the MCP server at startup via the Claude Agent SDK. When a customer emails asking "where is my shipment PO-48291?", the agent calls track-shipment with the PO, then estimate-delivery with the result, then composes a reply. Three months later they A/B test GPT-4o using the same MCP server. The agent framework swaps providers with a config change. Zero tool code is rewritten. Cost comparison runs in a day instead of a week. The operations lead says the cleanest architectural decision they made that year was wrapping their internal APIs behind MCP from the start.