What is MCP (Model Context Protocol)?
Model Context Protocol (MCP) is an open standard, released by Anthropic in November 2024, that gives AI agents a consistent way to connect to external tools and data: databases, CRMs, APIs, file systems. Anthropic donated it to the Linux Foundation in December 2025. The idea is straightforward: instead of building a custom integration every time you connect an agent to a tool, you build one MCP server per data source and any MCP-compatible agent can use it.
As of late 2025, there are over 10,000 public MCP servers and 97 million monthly SDK downloads. OpenAI, Google, Microsoft, AWS, and Salesforce have all adopted the standard.
If you keep seeing "MCP" in AI coverage and want a clear explanation of what it actually does, including where it falls short, this is that post.
What is MCP?#
the one-sentence definition#
MCP is an open standard that defines how AI agents connect to external tools, data sources, and services, so you build the integration once and any MCP-compatible agent can use it.
why it was built: the N x M integration problem#
Before MCP, every AI agent-to-tool connection was a one-off engineering project. Build a new agent? Write new connectors for every tool. Switch AI providers? Rewrite the integrations. Anthropic described it internally as an N x M problem: N agents multiplied by M tools, a sprawling web of brittle, incompatible code.
If you have three AI agents and fifteen tools, that is potentially forty-five custom integrations to build and maintain. Every time a tool's API changes, or you want to swap the underlying model, things break in ways that are hard to predict and expensive to fix.
MCP collapses that to N+M. One server per tool, one client per agent. Any MCP-compatible agent can reach any MCP-compatible server without rework. The forty-five custom integrations become eighteen standard connections.
the USB-C analogy: what it gets right and where it stops#
The comparison Anthropic and most of the industry reaches for is USB-C: a single connector standard that made decades of proprietary cables irrelevant. A USB-C cable carries power, data, and video through one port on any device. MCP carries context, tool calls, and prompts through one protocol between any AI agent and any connected system.
Where the analogy breaks down: USB-C is physical hardware. A cable either meets the spec or it does not. An MCP server might technically comply with the protocol while still having authentication gaps, unstable schemas, or security vulnerabilities. The standard enables connection. It does not guarantee anything about what runs over it.
How MCP works#
three roles: host, client, and server#
MCP splits responsibility across three roles. The host is the AI application, Claude Desktop, a custom agent, an IDE plugin. It manages the overall session. The client lives inside the host and handles the actual back-and-forth with MCP servers: translating the model's requests into MCP calls and returning results. The server is a lightweight process that wraps a specific tool or data source and exposes it to any MCP-compatible client.
When a session starts, the client connects to configured servers and asks each one what it can do. Each server responds with its capabilities, and the model can use those capabilities during the conversation.
three primitives: tools, resources, and prompts#
Every MCP server exposes some combination of three building blocks:
| Primitive | What It Does | Analogy |
|---|---|---|
| Tools | Functions the agent can call to take action: write to a database, send an email, run a query | A REST API POST endpoint |
| Resources | Read-only data the agent can access: files, records, documents | A REST API GET endpoint |
| Prompts | Pre-defined templates that give the model structured context for common tasks | A system prompt for a specific workflow |
Most production use cases rely primarily on tools. Resources and prompts are valuable but less universally used in current deployments.
transport layer: local (stdio) vs. remote (HTTP/SSE)#
MCP supports two transport modes:
- stdio (Standard Input/Output): The server runs as a local process on the same machine as the client. Simpler to set up, appropriate for developer tooling and local agents.
- HTTP with Server-Sent Events (SSE): The server runs remotely. The client sends requests over HTTP; the server streams responses over SSE. This is the model for production deployments where the server needs to be accessible to agents running in cloud infrastructure.
a concrete example: an AI agent pulling Salesforce data#
A sales manager asks their AI assistant: "Pull last quarter's deal data from Salesforce and summarize where each deal stalled."
With MCP: the agent calls an MCP server wrapping your Salesforce instance. The server queries the relevant records and returns structured data, no Salesforce credentials baked into the agent's code, no custom API wrapper, and with an audit trail of every tool call.
Without MCP: either the agent has no access to Salesforce at all, or someone built a proprietary integration that breaks when Salesforce updates its API or when the team switches AI providers.
The MCP ecosystem today#
from 100 servers at launch to 17,000+ indexed by late 2025#
MCP launched in November 2024 with roughly 100 servers built by Anthropic and early partners. By late 2025 the ecosystem had grown to over 10,000 production-quality servers tracked by major registries, with broader indexes listing upwards of 17,000 entries across all quality tiers (Glama, December 2025).
97 million monthly SDK downloads across Python and TypeScript#
The Python and TypeScript SDKs crossed 97 million combined monthly downloads in December 2025 (Anthropic / Linux Foundation announcement, December 2025). From near zero to nine figures of monthly downloads in under 14 months is faster than most developer infrastructure standards reach at this stage.
who adopted MCP: OpenAI, Google, Microsoft, AWS, Salesforce, and more#
OpenAI adopted MCP in March 2025 and integrated it across ChatGPT products. Google, Microsoft Azure, AWS, and Salesforce followed, making MCP the default agent integration layer across the major cloud platforms. Developer tooling companies including Zed, Replit, and Sourcegraph built MCP support into their AI coding features.
An MCP server you build today is usable by any AI agent on any of these platforms without modification.
the Linux Foundation donation: what vendor-neutral governance means in practice#
In December 2025, Anthropic donated MCP to the Linux Foundation, where it became a founding project of the Agentic AI Foundation (AAIF), a directed fund co-founded with Anthropic, Block, and OpenAI.
Vendor-neutral governance matters here. When a standard lives under an open foundation rather than a single company, no vendor can change the spec to advantage their own products, and enterprise adopters can build on it without worrying that a business decision at Anthropic will deprecate their investment. This is the same model that made Linux, Kubernetes, and OpenTelemetry safe infrastructure choices.
Why MCP matters for AI agents#
context is the bottleneck, not reasoning#
The limiting factor for most AI agents is not reasoning ability. It is context. A model that cannot see your CRM records or customer history cannot give useful answers about them, only guesses.
MCP addresses that gap. An agent connected to the right MCP servers can query live data before answering instead of relying on training knowledge, take action inside real business systems, and combine data across multiple sources in a single interaction. It can do this consistently regardless of which model is doing the reasoning.
what agents can do with tool access vs. without it#
Without tool access, an AI agent is a sophisticated text processor. It can reason about information it has been given, but it cannot go get new information and it cannot take action.
With tool access via MCP, the same agent becomes a participant in your systems. It can check whether an appointment slot is available before offering it, pull a client's history before a call, look up a policy before answering a coverage question, and write its conclusions back to the system of record. The gap between a demo agent and a production agent is usually the data plumbing, not the model.
fewer hallucinations, more grounded answers#
When an agent retrieves live data through MCP tools instead of relying on training knowledge or a static context window, its answers reflect reality. The appointment slot it offers actually exists. The policy it cites is the current one. The client's balance is from today's records, not something interpolated from training.
Hallucination is most likely when models generate factual claims from memory. It is least likely when models are reasoning over data they just retrieved. MCP shifts agents toward the latter.
demo agents vs. production agents#
Most agent demos look compelling because they run in a controlled environment with hand-crafted context. What breaks in production is usually not the model: the agent cannot reach the system it needs, gets stale or partial data, or has no structured way to act on what it learns.
MCP does not eliminate that plumbing work. It standardizes it. Teams that have built production MCP integrations report that the protocol itself is not the hard part, authentication, schema management, and security hardening are where complexity lives. But without a standard like MCP, even getting to those harder problems requires building proprietary glue code first.
What MCP does not solve#
Being clear about the limits is as useful as explaining what it does.
authentication and access control are still your problem#
MCP does not define how your server authenticates clients or manages credentials for the underlying service it wraps. You still need to build or integrate an auth layer, OAuth2, API keys, token scoping, and get it right. In production builds, authentication commonly adds four to six weeks to a project that teams did not initially budget for (Intuz / Zeo, 2025-2026).
security: prompt injection, over-permissive tool scopes, and lookalike tools#
Research published in 2025 identified active production risks in MCP deployments: prompt injection (where a malicious input tricks an agent into calling destructive tools), over-permissive tool scopes (agents with more access than they need), and lookalike tool attacks (a compromised MCP server impersonating a trusted one) (Zuplo MCP Security Report / Astrix State of MCP Server Security, 2025). The protocol does not protect against any of these by default. Hardened production servers require explicit security architecture.
schema drift as your underlying systems change#
When the system your MCP server wraps changes, a CRM that updates its API, a database schema that shifts, the server breaks. An MCP server that returns unexpected data types will cause hard failures in downstream agents. A human-written integration might degrade gracefully; MCP servers generally do not. You need a versioning strategy before you hit this in production.
quality varies widely across the ecosystem#
Among the thousands of publicly available MCP servers, quality ranges from production-ready to barely functional demos. Many were built to demonstrate a concept, not to handle real load, edge cases, or error conditions. Using an off-the-shelf server without understanding what you are running is a risk, particularly for servers that touch sensitive systems.
Do you need a custom MCP server?#
when an off-the-shelf server is enough#
If you are integrating with widely-used SaaS tools, GitHub, Slack, Google Drive, HubSpot, and your requirements are standard, well-maintained community servers exist and are actively used in production. Curated registries like Glama track production-quality servers and are a reasonable starting point.
when you need something custom-built#
You need a custom server when the system you are connecting to is proprietary: an internal database, a legacy EHR, a bespoke API built by your team. The same applies when your compliance requirements (HIPAA, SOC 2, financial regulations) demand specific access controls and audit trails that generic servers do not provide, or when your integration requires business logic that an off-the-shelf server does not encode.
There is also a maintenance question. A server you build and own, you can update when your underlying system changes and patch when a security issue surfaces. A community server is someone else's maintenance burden.
what a production-ready server actually requires#
A production-ready MCP server has proper authentication and access controls, explicit tool scope restrictions, error handling that fails gracefully and logs clearly, a versioning strategy for schema changes, a security review against known attack vectors, and documented maintenance ownership.
This is not a high bar. It is an engineering bar, not a prototype bar. Most of the publicly listed MCP servers do not meet it.
For teams evaluating production AI deployments, the MCP server question is usually a subset of a larger systems question: what does your agent need to see and do, and who is responsible for keeping that connection working? Silverthread Labs builds production MCP servers as part of agentic AI deployments. For a review of your specific integration requirements, book a free audit.
Frequently asked questions#
What is MCP in one sentence? MCP is an open standard that gives AI agents a consistent way to connect to external tools, databases, and services, so you build the integration once and any MCP-compatible agent can use it.
Is MCP the same as an API? No. An API is how a specific service exposes its functionality. MCP is a layer on top of APIs that standardizes how AI agents discover and call those capabilities. An MCP server typically wraps one or more APIs and presents them to the agent in a format the model can reason about.
Which AI tools support MCP? As of 2026: Claude (Anthropic), ChatGPT (OpenAI), Google Gemini and Vertex AI, Microsoft Copilot and Azure AI, and a growing set of developer platforms including Cursor, Zed, Replit, and Sourcegraph.
How many MCP servers exist? Indexes tracked over 17,000 entries by late 2025. Quality varies: curated registries like Glama maintain closer to 10,000 production-quality listings. New servers are added daily.
Is MCP free to use? Yes. MCP is open source (MIT licensed), and the specification is maintained under the Linux Foundation. There is no licensing fee for building MCP servers or clients.
What programming languages support MCP? Official SDKs are available for Python and TypeScript. Community SDKs exist for Go, Java, C#, and Rust. The TypeScript SDK is currently the most widely used in production deployments.
If I build an MCP server today, will it still work when AI models change? Yes. Model-agnosticism is a core design goal of MCP. A server that works with Claude today will work with any other MCP-compatible model without changes to the server itself. The protocol separates the integration layer from the model layer deliberately.
