Verify the server
Record the server source, owner, version or digest, transport, and expected identity before an agent can connect.
MCP tool review
Secure every tool before your agent can use it.
Verify the server. Freeze each tool contract. Reduce its access. Require approval for consequential actions. Compare the live setup with the approved baseline before trust carries forward.
MCP connects models to executable capabilities. A familiar tool name is not enough: review the server, schema, credentials, side effects, isolation, and evidence as one trust boundary.
The review sequence
Five checks before trust.
Freeze the tool contract
Capture every tool name, description, input schema, output schema, and annotation; review any later list or schema change before use.
Reduce each tool's reach
Limit files, data, credentials, scopes, network destinations, and side effects to the minimum required for the approved task.
Gate consequential calls
Require a human decision for writes, deletes, payments, identity changes, external sends, production access, and other high-impact operations.
Validate, log, and compare
Validate arguments and results, keep privacy-reduced invocation evidence, and compare the live server and tool contracts with the approved baseline.
Blank MCP register
Review one tool per row.
Keep the server identity beside the tool contract and its effective authority. The register is blank and contains no real server, credential, customer, or security result.
| Review | Question | Decision |
|---|---|---|
| Server identity | Who published this server, what exact build is connected, and how is that identity verified? | Pin the reviewed source and version |
| Tool contract | Did a name, description, input schema, output schema, annotation, or available tool change? | Re-review before invocation |
| Effective reach | Which files, data, credentials, systems, and network destinations can this tool reach? | Remove every unnecessary path |
| Side effects | Can this tool write, delete, deploy, pay, send, change identity, or perform another external action? | Require a human decision |
| Evidence | Can the team reconstruct the exact server, tool, arguments, decision, and privacy-safe result? | Log enough to investigate |
Contract changes are security changes
Do not approve a name. Approve an exact capability.
Identity
Pin the reviewed server source and version or digest. A display name alone does not establish which code is running.
Schema
Hash the complete tool definition. New parameters, wider schemas, changed descriptions, and added tools require another decision.
Authority
Review the actual credential, filesystem, database, API, and network reach behind the tool rather than its friendly description.
Invocation
Validate arguments before execution and treat returned text, links, files, and instructions as untrusted input.
Primary guidance
Check the protocol and security sources directly.
Model Context Protocol
Tools specification
MCP tools are model-controlled, tool definitions can change, annotations are untrusted unless they come from a trusted server, and users should be able to deny invocations.
Read primary sourceModel Context Protocol
Security Best Practices
MCP implementations should minimize scope, prevent token passthrough, validate authorization boundaries, and isolate local servers with restricted filesystem and network access.
Read primary sourceOWASP Cheat Sheet Series
Secure Coding with AI Cheat Sheet
AI coding workflows should allowlist reviewed MCP servers and tools, detect tool-definition changes, restrict tool invocation, and validate arguments before execution.
Read primary sourceOWASP GenAI Security Project
A Practical Guide for Securely Using Third-Party MCP Servers
Third-party MCP review should address tool poisoning, prompt injection, memory poisoning, tool interference, authentication, authorization, sandboxing, discovery, and governance.
Read primary sourceNIST
SP 800-207: Zero Trust Architecture
Resource access should be evaluated explicitly and continuously, with least privilege restricting both visibility and accessibility.
Read primary sourceSources checked July 28, 2026. Recheck the current protocol revision and provider configuration before use.
Continue the evidence trail
Connect the review to the exact risk.
Use the focused evidence pages to inspect connector access, autonomous actions, and prompt injection. Use the integrity benchmark to reproduce what should happen when a reviewed MCP contract changes.
Evidence boundary
A completed register documents a review. It does not prove that a server is safe, that its runtime matches its published code, or that an agent cannot be compromised. It is not protocol-conformance testing, an OAuth, token, transport, session, or SSRF audit, a server or dependency code audit, sandbox validation, or a penetration test.
Treat unreadable identity or configuration as unknown, not safe.
Never put raw credentials, customer data, or private paths in public evidence.
Re-review after a server, tool, schema, scope, credential, transport, or policy change.
Disable or quarantine the server when a material change has no approved explanation.
From review to evidence
Use CapitalGuard when a blank register is not enough.
CapitalGuard Pro adds repository evidence, permission analysis, prioritized findings, policy assets, and the prevention material included with the license.