What is Model Context Protocol?
Model Context Protocol (MCP) is an open specification that standardises how an AI application connects to external tools, data sources and prompts. It replaces one-off integrations with a single client-server interface.
How MCP works
MCP defines a client-server relationship. The AI application (the host) runs an MCP client. Each external capability is exposed by an MCP server, a small program that speaks the protocol. The client and server exchange JSON-RPC messages over a transport, typically stdio for a local process or HTTP with server-sent events for a remote one. The canonical reference at modelcontextprotocol.io describes the wire format and the lifecycle.
A server advertises three kinds of primitive. Tools are callable functions with a JSON Schema for their arguments, so the model can request an action such as reading a file or querying a database. Resources are readable data addressed by URI, which the host can attach to context. Prompts are reusable templates the user or host can invoke. The client negotiates capabilities during initialisation, so a host only sees what a server actually supports.
Control stays with the host. The model proposes a tool call, but the host decides whether to forward it, and the server decides whether to execute it. Nothing in the protocol requires a particular model, vendor or IDE. That separation is the whole point: a server written once can be used by any compliant client, and a client can add a server without a code change.
The transport choice matters in practice. A stdio server is a child process of the host, so it inherits the host's permissions and dies with it. A remote server introduces authentication, network failure and a trust boundary the host must manage. The specification leaves much of that to the implementer.
When you need MCP, and when you do not
MCP earns its place when the same capability must be reachable from more than one AI client, or when a team wants to publish a capability without shipping a plugin for every editor. It also fits when the integration surface is broad: many tools, many resources, or data that changes between sessions. Writing one server against a documented protocol is less work than maintaining N bespoke connectors.
It is a poor fit for a single script that calls one API from one program. A direct function call is simpler, faster and easier to debug. If your model already receives the data it needs in the prompt, adding a server adds a process, a schema and a failure mode for no gain. A terminal-only workflow with no host application has nothing to connect to.
There is also a cost that is easy to miss. Every tool definition consumes context window space, and a server with dozens of tools can crowd out the actual task. Codebase-memory-mcp, for example, ships 15 tools according to our analysis, and its README-style description claims 99% fewer tokens for indexed queries, but the tool schemas themselves still occupy the prompt. Fewer, well-scoped tools usually beat a large catalogue.
Finally, MCP is not a security model. It moves the question of what an agent may touch from the application into a server you may not control. If the answer matters, you need to answer it outside the protocol.
Common pitfalls and limits
The first limit is trust. An MCP server runs with whatever authority the host grants it. A server that can read files can read the wrong files. A server that can send messages can send the wrong ones. The protocol does not sandbox a server, and the README of modelcontextprotocol/servers states plainly that the reference servers are educational examples, not production software. Treating them as production is a mistake the documentation warns against.
The second limit is context cost. Tool descriptions, resource listings and prompt templates all occupy tokens. Headroom, an Apache-2.0 Python project, exists precisely because tool outputs, logs, files and RAG chunks can be compressed before they reach the model; its description claims 20% fewer tokens for coding agents and 60-95% fewer for JSON. Those figures come from the project, not from independent measurement. The reversible cache and the wrapped-agent setup are the parts to check before adopting it, according to our analysis.
The third limit is operational. A remote server can be unavailable, slow or version-mismatched. The specification defines an initialisation handshake, but the README of many projects does not document rollback or compatibility guarantees. Where a source is silent, assume nothing.
The fourth limit is discovery. punkpeye/awesome-mcp-servers is a curated index of MCP servers, plus a synced web directory at glama.ai. Its value is in the legend and the category split, not in any single entry. A listing is not a review, and inclusion is not a quality signal.
How MCP shows up in open-source projects
The most direct examples are servers. modelcontextprotocol/servers holds the small set of reference servers maintained by the MCP steering group, plus links to community servers. The README describes them as educational examples for building your own server, not production software. DeusData/codebase-memory-mcp takes the opposite approach: it indexes a repository into a persistent knowledge graph and exposes it to coding agents over MCP, with a native binary that reads your codebase and rewrites your agent config, 15 tools and a local 3D graph UI. ChromeDevTools/chrome-devtools-mcp exposes a running Chrome instance to MCP clients such as Claude Code, Cursor and Antigravity, so an agent can drive the page and read DevTools data back. It is Apache-2.0, TypeScript and installed through npx.
On the client side, danny-avila/LibreChat is an MIT-licensed TypeScript monorepo that puts Anthropic, OpenAI, Azure, Bedrock, Vertex AI and OpenAI-compatible endpoints behind one chat UI, and its description lists MCP among its features. Our analysis notes it is a deployment project, not a drop-in SaaS replacement. zylon-ai/private-gpt is a Claude-shaped API layer in front of any OpenAI-compatible inference server, supplying retrieval, tools, MCP and database access; it is not a model runner. farion1231/cc-switch is a Tauri desktop app that keeps provider profiles, prompts and MCP servers for several coding assistants in one place. It is convenient if you juggle relay endpoints, but it is not a gateway and does nothing for a terminal-only workflow.
Two projects use MCP as one capability among several. Headroom is available as a library, a local proxy and an MCP server. sansan0/TrendRadar collects trending items from multiple platforms plus RSS feeds, filters them by keyword and by an LLM, and pushes a digest to WeChat, Feishu, DingTalk, Telegram, email, ntfy, Bark or Slack; it is a Python 3.12 project under GPL-3.0, deployable with Docker or from source, and its description says it supports connecting to an MCP architecture. sickn33/agentic-awesome-skills describes AAS Core as a local, read-only control plane around a 2,000+ skill catalog, with a CLI, local MCP, catalog, plugins and Workbench; our analysis notes the agent picks skills, the CLI validates and plans them, and nothing is applied without human review. punkpeye/awesome-mcp-servers remains the index to consult before writing your own server, because the category split shows what has already been built.
How to evaluate an MCP server before you adopt it
Read the tool list first. Count the tools and read their schemas. A server that exposes one narrow capability is easier to reason about than one that exposes fifteen. Check what the server can read and write, and whether it runs locally or remotely. A local stdio server inherits your permissions; a remote server needs an authentication story the README should describe.
Check the maintenance signal rather than the feature list. An archived repository, or one whose last push is more than six months old, is not a safe default for a dependency, whatever its description claims. State the last push date when you mention it, and do not infer activity from a project's own summary.
Check the licence. Headroom is Apache-2.0, chrome-devtools-mcp is Apache-2.0, LibreChat is MIT, TrendRadar is GPL-3.0. A permissive licence is not the same as a supported product, and a copyleft licence may constrain how you redistribute.
Finally, test the failure path. What happens when the server is missing, slow or returns malformed output? The specification defines error responses, but the host's behaviour is the host's choice, and many projects do not document it. If the README is silent, that is the answer.
In practice
MCP is a small protocol with a large effect: it turns tool integration from a per-client chore into a server you write once. Start by reading the specification at modelcontextprotocol.io, then look at modelcontextprotocol/servers for the reference examples. If you need a server that already exists, check punkpeye/awesome-mcp-servers before writing your own. If you are choosing a host, compare LibreChat and private-gpt on the axis that matters to you: a full chat deployment versus an API layer in front of your own inference server.