Model Context Protocol (MCP)

An open standard for connecting AI applications to external tools, data sources, and workflows.

Problem MCP Solves

Before MCP, every IDE, chat client, and agent framework built custom integrations for databases, Git hosts, ticketing systems, and local files. Each integration duplicated auth, schema description, and transport logic. MCP standardizes how hosts discover and call capabilities exposed by servers, so one MCP server works across multiple clients.

Think of MCP as USB-C for AI tooling: a common plug shape, with the host deciding which devices to allow.

Architecture

MCP uses a client-host-server model:

Servers declare capabilities with schemas. The host aggregates them, applies policy, and presents them to the model. Users explicitly enable servers rather than exposing every integration by default.

Primitives

Tools

Callable actions with JSON Schema inputs (query database, create issue, read file). Similar to function calling in LLM APIs but standardized at the protocol level.

Resources

Readable data URIs (file contents, ticket JSON, config snapshots) the model can fetch for context without imperative side effects.

Prompts

Reusable prompt templates packaged with servers for consistent workflows (e.g., "summarize this repo").

Sampling (optional)

Servers can request LLM completions from the host under user-controlled policies, enabling nested agent patterns without embedding API keys in servers.

Transport

MCP supports stdio for local subprocess servers (common in desktop apps) and HTTP with Server-Sent Events for remote services. Local stdio keeps secrets on-machine; remote HTTP needs TLS, auth tokens, and network isolation like any microservice.

Security mindset: An MCP server is arbitrary code with access to your systems. Only install servers from trusted sources, scope credentials narrowly, and review tool definitions before enabling in production hosts.

Building and Consuming Servers

Official SDKs exist for TypeScript, Python, and other languages. A minimal server implements capability listing plus tool/resource handlers. Package servers for distribution (npm, pip) with clear README on required env vars and OAuth flows.

Hosts configure servers in JSON (command, args, env). Enterprise deployments may centralize allowlists, audit logs of tool invocations, and per-tenant server registry instead of per-user ad hoc installs.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/projects"],
      "env": {}
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {"GITHUB_TOKEN": "${GITHUB_TOKEN}"}
    }
  }
}

MCP vs Custom Tool APIs

Custom REST tool wrappers remain fine for single-product backends. MCP shines when the same integration must plug into many clients (IDEs, agents, eval harnesses) without rewrite. It does not replace your business API; it standardizes the adapter layer between LLM hosts and those APIs.

Ecosystem growth means more off-the-shelf servers, but quality varies. Treat third-party MCP servers like third-party browser extensions: convenient, potentially risky.

Operational Considerations

Log tool calls with correlation IDs across host and server. Version server capabilities; breaking schema changes should bump server version and notify hosts. Rate-limit expensive tools at the server. For multi-user SaaS, never share one filesystem MCP server across tenants without strict path sandboxing.