Distinguish host, client and server
The host is the AI application. A client inside it manages a connection to a server. The server offers capabilities or context: tools perform actions, resources provide content and prompts supply templates. These roles explain the technical path. A shared interface does not mean every client supports every server feature.
Example: an approved knowledge source
A server can expose search over internal manuals. The task provides a question; the tool returns permitted references. Another tool might modify a record. Those effects need different permissions and tests. Record each tool’s input, output, accessible data and possible changes. This makes its value and boundary concrete.
Assess protocol and trust separately
MCP is not a security certification. Review the operator, transport, authentication and downstream-service access. HTTP and local STDIO processes use different authentication arrangements. Acceptance therefore checks more than successful connection: an unauthorised request must be denied and revocation must take effect.
Decision matrix
| Decision point | Proceed when | Stop when |
|---|---|---|
| Access and data path | Documented: client, server, tool, resource, permission and human approval. | Scope, data or accountability remains unresolved. |
| Connection under test | A traceable diagram maps client, server, tool and resource to a concrete example and marks data access, possible write effects and the approval point. | There is only an unevaluated demo without acceptance evidence. |
| External effect | Owner, approval, fallback and next review date are defined. | Avoid: treating a technical standard as a security guarantee. Using a common protocol establishes neither the server's trustworthiness nor the appropriateness of its permissions. |
Keep it verifiable
Primary sources
- Model Context Protocol: Specification 2026-07-28Source checked:
- Model Context Protocol: Authorization 2026-07-28Source checked:
