Model Context Protocol (MCP)

What it is and how it works

Model Context Protocol (MCP) is not a tool in the conventional sense — it's a wire protocol, analogous to LSP (Language Server Protocol) but for connecting language models to external context and capabilities instead of connecting editors to language servers. Before MCP, every LLM application that wanted to call a GitHub API, query a Postgres database, or read a Slack channel had to write bespoke integration code against that specific vendor's function-calling schema. MCP standardizes the boundary: an "MCP server" exposes a set of tools, resources, and prompts over a well-defined JSON-RPC interface, and any "MCP client" (the application embedding the LLM) can discover and invoke them without custom glue code per integration.

The architecture has three moving parts. MCP servers are lightweight processes — often a single script or small binary — that wrap an external system (a database, a SaaS API, a filesystem, a set of local commands) and translate it into MCP's primitives: tools (callable functions with JSON Schema input/output), resources (readable data like files or query results), and prompts (reusable prompt templates the server can suggest). MCP clients are the applications that hold the conversation with the model — Claude Desktop, Cursor, Windsurf, Goose, and a growing list of others — and are responsible for discovering available servers, presenting their tools to the model as part of the function-calling context, and executing the round-trip when the model decides to call one. Transport between client and server is typically stdio for local processes or HTTP/SSE for remote servers, with JSON-RPC 2.0 as the message format underneath either.

Critically, MCP is model-agnostic at the protocol level: it rides on top of whatever function/tool-calling capability the underlying LLM already has. This is why it works with local models served through Ollama or similar runners, not just hosted frontier models — if the model can emit a structured tool call, an MCP client can route that call to an MCP server and feed the result back into context. The protocol itself doesn't care whether the model weights live on Anthropic's servers or on a workstation GPU.

Deployment patterns

For a solo developer, the typical shape is a handful of MCP servers running as local subprocesses launched by the client on startup — Claude Desktop's claude_desktop_config.json or an equivalent config file lists server commands (e.g., npx @modelcontextprotocol/server-filesystem /path/to/project), and the client spawns and manages their lifecycle via stdio. This is zero-infrastructure: no ports, no auth server, just a JSON config pointing at local executables. It's the dominant pattern for individual use — filesystem access, git operations, a local SQLite database, a code search server.

Homelab and small-team setups start to introduce remote MCP servers over HTTP/SSE, usually because the resource being wrapped (a shared Postgres instance, an internal API, a Kubernetes cluster) isn't something you'd want each teammate running a separate local process against. This is where the protocol's authentication story gets thinner — OAuth flows for remote MCP servers exist in the spec but implementations and client support have been maturing unevenly, and it's common to see teams bridging the gap with reverse proxies, API gateways, or simple bearer-token schemes in front of an MCP server rather than relying on protocol-native auth end to end.

At team-server scale, the pattern that has emerged is a small fleet of shared MCP servers (GitHub, Slack, internal ticketing, internal databases) run centrally and exposed over HTTP, with individual developers' MCP clients (Cursor, Claude Desktop, custom agents) connecting outward. Because each tool call is a network round trip through the server process, and potentially through a proxy layer, latency and rate limits on the wrapped API become the practical bottleneck, not the protocol itself.

How it compares

The closest historical analogue is OpenAI's function calling / plugins ecosystem, which solved a similar problem but as a vendor-specific, non-portable schema — you wrote your tool definitions against OpenAI's API shape and they didn't transfer elsewhere. MCP's pitch is portability: write a server once, use it from any compliant client regardless of which model is behind it. The tradeoff is that MCP servers are a separate process/deployment concern, whereas OpenAI-style function calling is just a JSON schema you pass inline with your API request — simpler for a single hardcoded integration, more cumbersome if you want the same tool available across many different client apps.

LangChain (and LangChain's tool/agent abstractions) sits at a different layer: it's a Python/JS framework for building the agent logic itself, with a large library of pre-built tool wrappers. LangChain tools live inside your application process; MCP servers are out-of-process and language-agnostic, so an MCP server written in TypeScript can be called by a Python-based client with no shared runtime. LangChain is more oriented toward orchestration and chaining; MCP is narrower and more explicitly about the client-tool boundary — in practice a LangChain agent can itself act as an MCP client.

Zapier/IFTTT-style integration platforms are the closest analogue on the "no-code connector" side, but they're hosted, closed platforms with their own auth and billing — MCP is a self-hostable open standard where you own the server process and its data path, which matters if you're running local models specifically to keep data off third-party infrastructure.

Best use cases and honest limitations

MCP is the right choice when you're building or using an LLM client that needs to talk to more than one or two external systems and want to avoid writing custom integration code for each — the 500+ public servers covering GitHub, Slack, Postgres, Stripe, Figma, Docker, and Kubernetes mean many common integrations are already written and just need to be pointed at credentials. It's also the right choice specifically for local-model users: because it's model-agnostic, a local Ollama or Qwen model with function-calling support gets the same tool ecosystem as a hosted Claude or GPT session, which is a real advantage over ecosystems that assume a specific vendor API.

The honest limitations, echoed in the field today: permissioning and auth for remote/shared servers are still maturing relative to the maturity of, say, OAuth in web applications — expect to build some of your own access control if you're exposing sensitive systems to a team. Community server quality varies significantly since anyone can publish one; treat third-party MCP servers with the same scrutiny as any dependency pulling code into your environment, especially ones with filesystem or shell access. And every tool call is a network round trip (even for local stdio servers, it's inter-process communication with serialization overhead), which adds latency compared to an in-process function call — for latency-sensitive or very high-frequency tool use, that overhead is worth measuring rather than assuming away. It's not a good fit if you need a single tightly-coupled integration inside one application and don't care about portability — a direct API call is simpler than standing up an MCP server for a one-off use.