It misses the server’s real behavior at tool-call time. A malicious MCP server can look harmless in its description or schema while reading files, forwarding secrets, or executing commands later. That is why metadata-only checks should be treated as partial evidence, not as proof that the server is safe to run.
Why metadata-only scanning fails for MCP servers
Metadata can tell you what a server claims to do, but it cannot show how that server behaves once a client starts invoking tools. For MCP, the security question is not just whether the description looks tidy, it is whether the server actually reads, writes, forwards, or executes anything at tool-call time. A scanner that stops at schema or description checks leaves the most important part untested.
That gap matters because MCP servers can present a narrow or benign surface in discovery while still performing broader actions after approval. The practical distinction is between declared capability and runtime behaviour: a server may advertise simple tools, then use those tools to touch local files, relay secrets, or trigger commands in a later step. Metadata-only review therefore gives a false sense of safety.
What the scanner is really missing
The missing evidence is operational, not cosmetic. A useful assessment needs to observe the server in action, including what it requests, what context it receives, and what side effects follow from a tool call. If the review never exercises the tool path, it cannot reveal whether the server escalates access, pulls in hidden dependencies, or behaves differently under real prompts and real data.
That is especially important for permissioned systems where the apparent trust boundary is thin. Tool definitions can look harmless while the implementation still has access to local resources, environment variables, network destinations, or downstream services. In other words, the metadata can be truthful and still incomplete in the way that matters for operational security.
Reviewing only the declared interface also misses deception by omission. A malicious or compromised MCP server does not need to advertise dangerous behavior in advance if it can wait until invocation time to act. That is why metadata should be treated as one signal, not as a verdict.
What a safer MCP review has to test
A meaningful review should validate runtime behavior, not just declared shape. That means checking the actual tool execution path, the data the server can reach, and whether tool output can be used to exfiltrate information or trigger unintended actions. For MCP security guidance that ties these checks together, see MCP Security Guide.
It is also useful to compare the server’s claimed purpose with what it can really do when connected to a client that has real credentials, tokens, or local context. If the server can read files, call out to other services, or operate on behalf of a user in ways the metadata does not clearly disclose, the review should flag that mismatch as a trust problem, not a documentation issue.
When the subject is agentic tooling, runtime checks should be paired with broader agent-risk review. The OWASP peer-reviewed agentic AI framework is a useful companion when you need to reason about tool misuse, privilege abuse, and trust boundaries across agent workflows, and NHIMG’s OWASP Agentic Applications Top 10 and the agentic AI applications guide both support that broader view.
Risk and Threat Considerations
Metadata-only scanning creates a blind spot that attackers can exploit by keeping the advertised surface benign while hiding harmful behavior in execution. The risk is not theoretical, because the dangerous action is often the post-discovery tool call, where files, secrets, sessions, or downstream commands become reachable.
Failure mechanism: The scanner validates the server’s declared schema or description, but never proves what happens when the tool is actually invoked. That allows a hostile server, or a compromised benign one, to appear safe until runtime behavior exposes data or performs actions the metadata never revealed.
Impact: Organisations may approve a server that reads sensitive files, forwards secrets, or executes commands under an assumed-safe label, which can lead to credential exposure, unauthorized access, or wider compromise through trusted tooling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tool calls can be abused beyond what metadata shows. |
| ASI03 — Identity & Privilege Abuse | Runtime MCP behavior can misuse the authority granted to the client or agent. | |
| Recommendation — Test actual tool execution paths for unauthorized actions and data access. Constrain granted privileges and validate that tool calls stay within approved authority. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Metadata-only review can miss runtime exposure and misconfigured tool access. |
| Recommendation — Verify the live interface, authorization, and side effects, not just declared metadata. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | MCP servers need enforced access boundaries beyond descriptive metadata. |
| Recommendation — Enforce least privilege and review access paths that the server can reach at runtime. | ||
Practitioner Guidance
What to verify: Treat metadata as a discovery aid, then test the live tool path with representative inputs and realistic permissions. A useful check is whether the server’s observed effects match its declared purpose when it runs inside the same trust context it will have in production.
Decision rule: If a server can access sensitive material or trigger side effects that are not obvious from the metadata, do not rely on description review alone. Escalate to runtime testing, tighter authorization, or isolation before granting production use.
Common mistake: Teams often equate “well-described” with “well-behaved.” For MCP, the real control question is whether the server’s runtime behavior is bounded, observable, and consistent with the level of access it receives.
Practitioner takeaway: The safest MCP assessments prove behavior, not intent, because the harm usually appears only when the tool is actually called.