Connecting a Model Context Protocol server adds more than a convenient tool menu. It introduces an implementation, an identity relationship, and a path to data or actions. Each needs an owner and an operating boundary before the agent uses it.
MCP makes integrations easier to describe and discover. It does not make an unfamiliar tool description trustworthy or turn access to one system into permission to use another. The right review starts with what a connection can reach and what happens when its behavior changes.
Treat discovered descriptions as untrusted input
The MCP tools specification describes tool discovery and change notifications. It also cautions clients about trusting tool annotations from untrusted servers. In practical terms, the words describing a tool and the implementation behind it belong in the review, not above the review.
An illustrative document-search tool might return a useful excerpt alongside instructions to send other files to a diagnostic endpoint. The excerpt can be evidence for the user's question. The extra instruction cannot create a new authorization. The client must preserve that distinction even when the text resembles a system notice.
Record the server owner, deployment or package version, tool inventory, credentials, reachable resources, outbound destinations, and revocation method. Revisit the decision when those facts change.
Review three surfaces separately
First, implementation. A local server may execute with access to the machine that launches it. A remote server shifts execution elsewhere but still receives requests and may receive sensitive inputs. Inspect the installation or deployment path, maintenance owner, dependency updates, and the permissions of the actual process.
Second, identity. The MCP security guidance prohibits token passthrough and discusses confused-deputy risks. Tokens must be intended for the receiving service. The authority to invoke an MCP tool should be distinct from whatever downstream authority the server uses.
Third, network reach. The same guidance identifies server-side request forgery risks during OAuth metadata discovery. An untrusted server can influence URLs fetched by the client. Review discovery and redirects as network operations; apply destination controls and account for private, loopback, and metadata services in the deployment environment.
Use an adapter that understands the operation
A generic HTTP or shell tool is flexible but difficult to constrain with a meaningful business rule. A narrow adapter can enforce allowed record types, tenant identifiers, field limits, and destinations before sending a request. Keep authorization checks in code that does not depend on the model remembering a warning.
For an illustrative supplier-search integration, the adapter could accept a supplier identifier from the authorized workspace and return a bounded set of approved fields. A request for another workspace should fail without fetching its records. A request to email those records should require a separate tool and a separate decision.
Tool output needs limits too. Preserve provenance, constrain payload size, and prevent a returned document from silently replacing the task objective. A useful result should remain useful after suspicious instructions are excluded. Denial should not require abandoning every benign item in the packet.
Test a connection before granting useful credentials
- Use a synthetic dataset and confirm a permitted query produces the expected, bounded result.
- Attempt access outside the allowed resource scope and verify the denial at the service boundary, not only in the assistant's wording.
- Change a tool description or schema and confirm the inventory change is visible to the operator before broader authority is inherited.
- Revoke the credential, interrupt a session, and verify that resume does not restore old authority from cached state.
- Inspect event records for sufficient action evidence and for accidental capture of credentials or unnecessary source content.
What a defense supplier should be able to show
Present a dependency and access record for the proposed workflow: which component runs where, who maintains it, what it can read, and which actions remain human-controlled. Distinguish a public-data demonstration from the intended program environment. A working connector is evidence of interoperability, not evidence that a particular protected-data use is authorized.
The procurement-friendly artifact is a small, testable operating envelope with a revocation procedure. It lets a reviewer challenge a specific boundary instead of accepting a broad assurance that the agent is secure. That work also reduces the cost of replacing the integration later.
Review the tool implementation, identity path, and network reach independently. A connection should earn narrowly scoped access through evidence, then retain it through controlled changes.
Continue the conversation
Bring Agent9 one workflow, its operating constraints, and the evidence you need before deployment. Discuss the engineering problem.