The wire protocol that turns hardcoded tool registries into discoverable, versioned, independently-deployable services. The platform turn.
A tool is a function the model can call. A tool server is a process that exposes tools, resources, and prompts over a wire protocol — discoverable, versioned, independently deployable. MCP is that wire protocol. This deep-dive is about building production tool servers: the lifecycle, the capability negotiation, the schema validation, the registry, and the failure modes that turn a clever integration into a production outage.
The platform turn. Pi's four tools are compiled-in function references. Adding one means editing source, shipping a build, restarting. MCP externalizes tools into services. A vendor ships a server; the agent discovers it at runtime. This is the structural difference between a personal harness and a platform.
Three primitives, three trust boundaries. Tools (model-initiated, untrusted input, schema-validated). Resources (user/client-initiated, semi-trusted). Prompts (user-initiated, server-authored, trusted). Confusing them — exposing as a tool what should be a resource — is a security bug.
Capability negotiation is the contract. The initialize handshake exchanges what both sides support. The session may only use the intersection. A client built once works against every server — including future and third-party ones — using whatever subset both offer.
JSON Schema is the validation boundary, not documentation. additionalProperties: false is a security control — it prevents a steered model from injecting unexpected fields. The server re-validates on every call. Never trust the model or the client to validate.
Three error classes, three recovery paths. Unknown tool, validation failure, execution failure. Each returns a distinguishable isError payload. The model's response differs per class — conflating them produces a confused loop.