A practical MCP server review method based on protocol boundaries, authority, schemas, credentials, and safe defaults.
Start an MCP server review with authority, not tool names.
Ask two questions:
- What information does this server need?
- What actions can this server perform?
If the answer is "all model context" or "every action in the upstream API," the server has too much authority.
This review uses version 2025-06-18 of the Model Context Protocol (MCP) specification. The architecture defines a host that manages consent and policy. Each client keeps one isolated connection to one server. A server should receive only the context that it needs, and it should not see other servers or the full conversation.
Separate context from action
MCP primitives have different risk profiles:
| Primitive | Purpose | Primary risk |
|---|---|---|
| Resource | Provides context such as files or application state | Exposes too much data |
| Prompt | Provides a reusable interaction template | Introduces unsafe instructions or resource references |
| Tool | Performs an external action | Changes state or sends data without proper authority |
| Sampling | Requests model output through the client | Produces output that the user did not intend |
| Elicitation | Requests structured information from the user | Collects sensitive or unnecessary data |
Do not combine these paths behind an interface that only says the agent can "do stuff." Use specific names, narrow descriptions, explicit schemas, and separate read operations from write operations.
Check every tool beyond its schema
MCP tools are model-controlled. The model can discover and call a tool from its context. A valid JSON Schema does not make the operation safe.
Check each tool as follows:
- Give the tool a name that describes one operation.
- State every material side effect in the description.
- Mark required fields as required.
- Use enumerations when the valid choices are known.
- Validate the input again in the server after schema validation.
- Apply authorization checks to the resolved resource, tenant, or account.
- Set a timeout and a rate limit.
- Sanitize the result before it returns to the model.
- Require user confirmation for sensitive actions in the host interface.
The MCP tools specification assigns related duties to both sides. Servers validate inputs, enforce access control, rate-limit calls, and sanitize outputs. Clients show tool inputs, validate results, apply timeouts, log use, and request confirmation for sensitive operations.
Keep credentials inside their trust boundary
For HTTP transports, the MCP authorization specification builds on OAuth. The client sends access tokens in the Authorization header. It must not put tokens in a query string.
The server must validate that a token was issued for that MCP server. It must not accept a token for another resource and pass that token to a downstream API. The MCP security guidance calls this token passthrough and forbids it because it breaks the trust boundary.
Use this authorization design instead:
- The MCP server validates the client token for itself.
- The MCP server uses a separate downstream authorization relationship.
- The downstream token has an audience and scope for the downstream API.
- Audit logs preserve the client and user that initiated the action.
A server that forwards any token can bypass rate limits and validation. It can also lose accountability and make incident analysis harder.
Parse and authorize every resource URI
A resource URI must identify one resource. The server must not reinterpret the same string as another file, tenant, branch, database, or internal endpoint.
For each resource:
- Parse the URI with a real URI parser.
- Reject path traversal and alternate encodings.
- Resolve the resource before you check its tenant or workspace boundary.
- Check authorization before you read sensitive data.
- Encode binary data safely.
- Document custom URI schemes.
- Use an
https://link only when the client can retrieve the resource directly.
This control matters because a resource can become context for a later tool call. Excess context can therefore lead to excess action.
Treat prompts and sampling as trust boundaries
Prompt arguments are user input, not trusted configuration. Validate prompt inputs and outputs. Prevent prompt injection and unauthorized resource access.
Sampling lets a server request model output through the client. The client should let the user inspect and edit the prompt when the risk requires it. The user should also review the generated response before the client delivers it to an external system.
Ask one direct question: Can this server cause the model to say or do something that the user did not request? If it can, add review controls, capability limits, and logs.
Do not request secrets through elicitation
Elicitation lets the server request missing structured information. The MCP specification says that servers must not use elicitation to request sensitive information.
Use elicitation for low-risk workflow choices. Use an authorization flow, local configuration, or a secret manager for credentials and other sensitive values. Show which server asks for the information, and let the user decline or cancel the request.
Publish the method, not private findings
When a review comes from private code, do not publish details that identify the system. These details include repository names, vendors, endpoint paths, payloads, screenshots, tokens, exploit strings, and issue counts. Do not imply that a third party has a vulnerability.
You can publish the review method:
- Draw the host, client, and server boundaries.
- List each tool, resource, prompt, sampling path, and elicitation path.
- Mark each path as read-only, write-capable, credential-bearing, or user-facing.
- Check schemas and server-side validation.
- Check token audience, scope, and downstream handling.
- Check URI parsing and resource authorization.
- Check user confirmation for sensitive actions.
- Check logs, timeouts, and rate limits.
- State what the server must never be able to do.
That final statement defines the server's authority. A safe MCP server has a focused job and a small authority surface.