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:
- Host - the AI application (Cursor, Claude Desktop, custom agent) that runs the session
- MCP client - connector inside the host that speaks MCP to servers
- MCP server - exposes resources, tools, and prompts for a domain (GitHub, Postgres, filesystem)
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.
Refer: MCP specification
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.
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.