Before You Connect an MCP Server: A Dependency Review for Agent Builders

Ou1comes — Mon, 02 Nov 2026 14:08:01 +0000

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.

Building OU1COMES: AI-Native Services With a Definition of Done

Ou1comes — Wed, 28 Oct 2026 22:05:48 +0000

OU1COMES is being built around a straightforward idea: an AI-native service should be judged by the completed work it delivers and the evidence that the work meets its requirements.

For developers, this starts with a definition of done. Before choosing a model or designing an agent, specify the deliverable, the constraints, and the checks that determine whether the task is complete.

Consider a document-preparation service. Producing fluent text is only one step. The workflow also needs to check required sections, distinguish supported claims from assumptions, and produce a usable artifact. If a required check fails, the result should remain incomplete.

Our approach connects three responsibilities: define the work clearly, use AI within a bounded workflow, and verify the output against the original requirements. Human review belongs at the points where judgment, permission, or an external commitment is required.

That distinction matters when a workflow can send a message, publish an article, or change a system. A prepared result is not permission to release it. And when an external action has an uncertain outcome, repeating it can create a duplicate rather than solve the problem.

This is the direction we are taking with OU1COMES: useful services that make completion visible and give people a clear basis for accepting the work. It is a design commitment, not a claim that every task can be automated or independently verified.

Learn more about OU1COMES.

AI disclosure: This article was drafted with AI assistance.

DEV Community: Ou1comes