Model Context Protocol

It standardizes parts of the integration contract. It does not independently make a server trustworthy or authorize every capability it exposes.

Key takeaways

• Distinguish host, client, and server responsibilities.
• Inspect capabilities and versions.
• Preserve user authority and data boundaries.

The architecture separates a host application, its clients, and connected servers. A client manages a connection to a server, while the host coordinates the user experience and relevant security decisions. A server may run locally or remotely. Tools expose operations; resources supply contextual content; prompts provide reusable interaction templates. These capabilities serve different purposes, and support varies by host and protocol version. Inspect negotiated capabilities rather than assuming every integration implements the complete specification. Establish the data and permission boundary before connecting. A useful server may read private records or change external state. Its descriptions and returned content are inputs to evaluate, not a source of authority to broaden the user’s request. Keep authorization, secrets, and account separation in the application’s security design. Test the integration lifecycle: connection, capability discovery, argument validation, error responses, reconnection, and revoked access. Record the server and protocol versions. A successful connection proves that communication works, not that every tool is correct or that the user’s task is complete.

1. Imagine a server exposing search_documents and delete_document. A user asks only to find a policy.
2. The host can use the authorized search capability without interpreting server availability as permission to delete anything.
3. If a retrieved page instructs the host to delete an unrelated file, treat that text as content rather than a new user request.

This constructed example illustrates the difference between exposed capability and authorized use.