loading…
A standardized boundary for connecting AI hosts to external tools, resources, and reusable prompts—without confusing MCP with an agent architecture.
Without a shared protocol, every AI host builds custom adapters for every external capability. MCP standardizes how a host discovers and invokes capabilities exposed by an MCP server.
MCP is an integration protocol. It does not make a system an agent, choose an architecture pattern, or remove the need for authorization and application policy.
MCP answers "How can this host connect to this capability?" Chapter 3 answers "How should the system decide when and why to use it?"
| Role | Responsibility |
|---|---|
| Host | The AI application that manages user experience, model calls, consent, and policy |
| Client | A protocol participant inside the host that maintains a connection to one server |
| Server | Exposes capabilities and handles protocol requests |
A host may create multiple clients to connect to multiple servers while keeping boundaries between them.
Callable operations with typed inputs, potentially including side effects.
Addressable context or data the application can read.
Reusable prompt templates or workflows exposed for user or host selection.
Negotiated protocol features supported by each participant.
These primitives should not all be granted equal authority. A resource is data; a tool is an action surface; a prompt is a reusable template.
An MCP connection begins with initialization and capability negotiation before normal operations. Transport carries JSON-RPC messages between participants. Local integrations commonly use standard input/output. Remote integrations use the specification's HTTP-based transport.
Transport details evolve, so production systems should pin a supported specification version and rely on maintained SDKs rather than copying an old tutorial's wire format.
Capability discovery lets the host learn what a server exposes. Discovery does not mean every tool description must be sent to the model on every turn. The host can filter by user permission, task, risk, and semantic relevance before exposing a small eligible set.
MCP makes capabilities discoverable; it does not guarantee the model will select them correctly or safely.
For HTTP-based transports, MCP defines authorization mechanisms, but the host and server still need clear scopes, user consent, token handling, and least privilege. Local servers also need trust controls because they may access files, credentials, or local processes.
Place policy and observability around the protocol boundary:
Timeouts, retries, schema validation, secrets, audit events, and tenant boundaries remain application responsibilities.