AIStackWatch
Back to wiki

Model Context Protocol

Model Context Protocol (MCP) is an open specification Anthropic released in late 2024 and that has since been adopted across the agent ecosystem. It standardizes how an LLM client discovers and calls external tools, resources, and prompts — the same way a printer driver standardizes device I/O for an operating system.

The three primitives

  • Tools — functions the model can call with JSON arguments. Same shape as native function-calling.
  • Resources — read-only data the client can attach to context (files, database rows, HTTP responses).
  • Prompts — parameterized prompt templates the server exposes.

A server implements any subset. A client (Claude Code, Cursor, Windsurf, plus IDE plugins) connects to one or more servers, aggregates their capabilities, and exposes them to the model.

Why it exists

Before MCP, every agent tool integration was a bespoke wrapper. Every editor reinvented the GitHub tool, the Jira tool, the Postgres tool. MCP decouples the integration from the client. One "Linear MCP server" works in every MCP-compatible agent.

Transports

  • stdio — the server is a subprocess the client spawns. Simple, local, good for CLI tools.
  • HTTP + SSE — the server runs anywhere reachable. Good for hosted, multi-tenant services.

The ecosystem

A registry of community servers exists for Postgres, Slack, Linear, GitHub, Playwright, filesystems, and many others. Most are thin; writing your own server in the SDK of your choice is a 100-line afternoon.

Failure modes

  • Tool-name collisions. Two servers both expose search. Clients namespace them; still confuses the model.
  • Schema drift. A server updates its tool schema; agents using old cached definitions start getting validation errors.
  • Auth leak. An MCP server with OAuth tokens running as a user-level subprocess can be called by any agent on the box. Treat MCP servers like any other privileged service.
  • Over-exposure. Registering 50 servers floods the model's tool list. Keep the attached set small and task-relevant.

When NOT to use MCP

If you're building a single product where the tool surface is fixed and private, raw function-calling is simpler than spinning up a server. MCP pays off when you want the same tool callable from multiple clients — or when you want to publish something others can plug into their agent.