Adding an MCP server to an agent takes a few lines of configuration. That convenience hides a real decision: you are giving software you did not write a path into your agent's actions and, often, into your users' data.
We treat every MCP server as a dependency and review it before it reaches production. Here is the review, grounded in what the Model Context Protocol specification actually says.
Start with what the spec says about tools
The specification does not soften this point: tools represent arbitrary code execution and must be treated with appropriate caution.
Servers can also attach annotations that describe how a tool behaves. On those, the spec is just as clear: clients must consider tool annotations to be untrusted unless they come from trusted servers. So a tool that describes itself as harmless is making a claim, not proving anything. Decide how far you trust the server before you trust its descriptions.
Review 1: who maintains it, and what can it reach?
- Maintainer and releases. Who publishes the server, how are releases made, and can you pin an exact version?
- Reach. List every system the server can touch with the credentials you hand it. If it only needs to read, do not give it write access.
- Data. Write down which user data could flow through it. That list is what you are really approving.
Review 2: authorization and tokens
Authorization is optional for MCP implementations. In practice, "it speaks MCP" tells you nothing about whether it checks who is calling.
The spec also scopes where its authorization rules apply: implementations using an HTTP-based transport should conform to the authorization specification, while implementations using an STDIO transport should not follow it and take credentials from their environment instead. For a local STDIO server, that makes your environment variables part of the review.
For HTTP servers, two token rules are worth checking explicitly. Clients must not send tokens to the MCP server other than ones issued by the MCP server's authorization server, and MCP servers must not accept or transit any other tokens. If an HTTP server expects your client to send it a token meant for some other service so that it can pass that token along, treat that as a finding.
Review 3: the obligations on both sides
The specification lists what servers must do: validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitize tool outputs. Ask the maintainer how each one is handled. "We trust the model" is not an answer to any of them.
It also lists what clients should do: prompt for user confirmation on sensitive operations, show tool inputs to the user before calling the server, validate tool results before passing them to the LLM, implement timeouts for tool calls and log tool usage for audit purposes. If your agent framework does not do these, that gap belongs in the review too.
Above all of it sits one principle: there should always be a human in the loop with the ability to deny tool invocations.
A checklist to paste into the pull request
- [ ] Maintainer identified; exact version pinned
- [ ] Every reachable system listed, with the narrowest credentials that work
- [ ] User data that can pass through the server written down
- [ ] Authorization: HTTP server conforms to the spec, or STDIO credentials reviewed
- [ ] No pass-through of downstream tokens
- [ ] Tool annotations treated as untrusted unless the server is trusted
- [ ] Server obligations confirmed: input validation, access control, rate limits, output sanitization
- [ ] Client side: confirmation prompts, visible tool inputs, result validation, timeouts, audit logging
- [ ] A person can deny any tool call
Why we care
This review is the thinking behind the MCP dependency reviews we are building at OU1COMES. AIVE, the autopilot being developed behind OU1COMES, is designed to coordinate agents and tools within defined policies, and deciding which tools it may use starts with a review like this one. More at OU1COMES.
Sources: Model Context Protocol specification, version 2026-07-28: overview, tools and authorization.
Created with AIVE
This article was drafted with AI assistance in AIVE, the publishing autopilot being developed behind OU1COMES, and reviewed by the OU1COMES editorial team.
AIVE powers the intelligence. OU1COMES delivers the outcomes.
Top comments (0)