Learning outcomes
- Explain host client and server boundaries
- Validate negotiated capabilities and tool schemas
- Preserve authorization outside protocol discovery
Mental model
A protocol is a shared wire contract, not a security decision. The host coordinates isolated clients; each client maintains a session with one server; servers expose focused resources, prompts, or tools through negotiated capabilities.
Theory
The Model Context Protocol uses a host-client-server architecture and JSON-RPC messages. Initialization negotiates supported capabilities. Tool discovery returns names, descriptions, and input schemas; invocation sends typed arguments and receives content, structured output, or errors. Resources and prompts provide other forms of context exchange.
Protocol conformance does not establish trust. Treat server-provided descriptions and annotations as untrusted metadata. The host decides which servers may connect, what context each receives, whether a user must approve an operation, and how results are sanitized before they reach a model or interface. Pin protocol versions and handle capability absence explicitly.
Alternatives and trade-offs
Provider-specific tool APIs can be simpler for one application. OpenAPI and ordinary service clients remain appropriate for deterministic integrations. A context protocol becomes useful when multiple hosts need to discover interchangeable AI-facing capabilities. The abstraction adds version negotiation, lifecycle, and new trust boundaries.
Failure modes and misconceptions
Discovery is not authorization. A valid JSON Schema does not validate business policy. Passing the full conversation to every server violates isolation. Assuming all clients support every optional capability creates brittle integrations. Tool errors must be distinguished from protocol errors so recovery behavior remains correct.
Knowledge check
What must a host validate after a protocol-compliant server returns a successful tool result?
Decision scenario
An engineering assistant connects to separate repository and ticket servers. The host grants each client only the necessary roots, displays tool inputs before write operations, validates structured results, and keeps repository credentials outside model-visible context.
Learning outcomes
- Explain Context and Tool Protocols as a system mechanism rather than a slogan.
- Compare its alternatives, trade-offs, and production failure modes.
- Apply the concept to a decision and identify evidence that would validate it.
Trade-offs
Using Context and Tool Protocols can improve capability or control, but it also introduces cost, latency, complexity, and failure modes that must be measured against an explicit objective.
Evidence assessment
Theory and decision mastery
Decision scenario
A production team must adopt Context and Tool Protocols while meeting quality, latency, security, and operating constraints.
Which decision process is most defensible?
Relationships
Primary sources
- Model Context Protocol Architecture and Tools Specification — Model Context Protocol, verified 2026-07-21