Model Context Protocol (MCP)
The Model Context Protocol (MCP) is an open JSON-RPC 2.0 standard, introduced by Anthropic, that lets an AI application connect to external tools, data and prompts through one uniform interface. A host runs one MCP client per server, performs a capability handshake, then discovers and calls the server's tools, resources and prompts. MCP solves the N×M integration problem: instead of building a custom connector for every model-times-tool pairing, each side implements MCP once and interoperates with everything else that speaks it.
What the Model Context Protocol is
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic, for connecting AI applications to the outside world. It defines a single wire format — JSON-RPC 2.0 — that an AI app (the host) and an external capability provider (the server) use to talk to each other. Once an app speaks MCP, it can connect to any compliant server without bespoke glue code.
The common analogy is USB-C for AI: one connector standard instead of a different cable for every device. Before MCP, every assistant, IDE and agent framework invented its own plugin or tool-calling format, and every tool vendor had to re-implement against each one. MCP replaces that fragmentation with a protocol both sides implement once.
MCP is intentionally narrow and model-agnostic. It does not dictate which model you use or how the model reasons; it only standardizes how the model's host discovers and invokes external capabilities and pulls in external data.
The N×M integration problem MCP solves
The N×M ("N times M") integration problem is what you get when N AI applications each need to connect to M external tools or data sources. Without a shared standard, every app-to-tool pairing is a separate, hand-written integration, so the number of connectors you have to build and maintain grows as N multiplied by M. Ten apps and ten tools is a hundred bespoke integrations, each with its own auth, schema and quirks.
MCP collapses that to N + M. Each AI application implements an MCP client once, and each tool or data source implements an MCP server once. Any client can then talk to any server, because they share the same protocol. New tools become available to every MCP-capable app for free, and new apps inherit the entire existing ecosystem of servers.
This is the same leverage standard protocols brought elsewhere: the way HTTP let any browser talk to any web server, or the Language Server Protocol let any editor talk to any language tooling, MCP lets any agent talk to any capability provider. The integration cost stops scaling with the product of both sides and starts scaling with the sum.
How MCP works: host, client, server
An MCP deployment has three roles. The host is the AI application the user interacts with — Claude Desktop, an IDE assistant, or your own agent. Inside the host, an MCP client manages the connection to exactly one server: if a host uses three servers, it runs three clients. The server is the program that exposes capabilities over MCP.
A connection begins with a capability handshake. The client and server exchange an initialize message that negotiates the protocol version and advertises what each side supports. Only after this handshake succeeds does the host trust the server enough to enumerate and use what it offers — which is why a server that fails the handshake is effectively unusable.
After initialization, the host discovers capabilities by calling listing methods (tools/list, resources/list, prompts/list) and then invokes them on demand (tools/call to run a tool, resources/read to pull in data). Because discovery is dynamic, the host re-reads the server's tool definitions per session rather than pinning a reviewed copy — convenient, but the reason an approved server can later change what it exposes.
What a server exposes: tools, resources, prompts
An MCP server can offer three primitives. Tools are callable functions the model can invoke — each has a name, a human-readable description, and a JSON Schema describing its inputs (and often its outputs). Tools are the highest-leverage and highest-risk surface, because their descriptions and outputs flow straight into the model's context.
Resources are readable data the model can pull into context, addressed by URI — files, database rows, API responses. Prompts are reusable, parameterized prompt templates the host can surface to the user or the model. A given server may expose any combination of the three; many real servers are tool-centric and expose few or no resources and prompts.
One useful distinction for trust: tools are model-controlled (the model decides when to call them), resources are application-controlled, and prompts are user-controlled. Knowing which primitive carries which authority helps you reason about what an unfamiliar server can actually do once your agent loads it.
Transports: local stdio vs. remote HTTP
MCP separates the message format (JSON-RPC 2.0) from how those messages are delivered, so the same protocol works locally and remotely. The stdio transport runs the server as a local subprocess and exchanges messages over standard input/output — the common choice for desktop tools and anything that needs filesystem or local-process access.
For remote servers, MCP uses HTTP-based transports: the modern Streamable HTTP transport, and the legacy HTTP+SSE (Server-Sent Events) pairing it superseded. Remote servers commonly sit behind OAuth 2.1 for authorization, so the host completes an auth flow before the handshake.
Because one protocol spans local and remote, an agent can freely mix first-party and third-party servers — a local filesystem server next to a remote SaaS server. That flexibility is exactly why evaluating an unknown server before trusting it matters: the transport tells you where the code runs, not whether the tools it ships are safe to expose to your agent.
How CheckMCP handles it
CheckMCP is built directly on the protocol described here: it connects to any live MCP server the same way a host does — performing the capability handshake, then calling tools/list, resources/list and prompts/list — and turns what it sees into a vendor-neutral MCP Score from 0 to 100 (grade A–F). A live endpoint is graded across seven weighted pillars (security 20, tool design 18, schemas/descriptions 16, reliability 14, context-cost 12, compliance 12, coverage 8); a source repository or stdio server is graded on four (maintenance 40, license 25, adoption 20, documentation 15). The compliance pillar checks exactly the protocol mechanics on this page — JSON-RPC error conformance, a valid negotiated protocol version, annotation coverage and OAuth discovery — while a failed MCP handshake is a hard floor that caps the grade at F (a plaintext secret found in a tool schema caps it at D). You can run it with uvx checkmcp <url> (open-source, MIT, stdlib-only), at checkmcp.dev, or as a GitHub Action (uses: H129hj/checkmcp@v1) to fail a build on a score regression or rug-pull. Beyond scoring, an in-band Gateway (passive and active modes) plus drift monitoring sit between agent and server to block tool poisoning before it reaches your agent.