ToolBench shows MCP quality still lags enterprise adoption

At a glance

What this is: Arcade's ToolBench rescan shows MCP adoption has scaled quickly, but server quality, safety guidance, and failure handling still lag behind enterprise use.

Why it matters: IAM and NHI teams should treat MCP servers as governed identity and authorisation surfaces, because weak tool metadata and unsafe execution paths expand agent privilege risk.

By the numbers:

• Only 260 of the open-source servers we scored earn an A, and none earn an A+.
• Stateless handling appears on 5.8% of servers, and those servers average about eight points higher.

Context

MCP is the protocol that lets AI agents connect to tools and data sources, so the quality of an MCP server directly shapes what an agent can do, what it can change, and how safely it can fail. That makes MCP security guide issues about tool exposure, credentials, and authorization part of the same governance problem, not a separate technical niche.

Arcade's rescan matters because enterprise use is no longer hypothetical. Once MCP becomes the connective layer for agent workflows, tool descriptions, failure handling, and execution boundaries become governance controls, not documentation polish.

The important shift is that MCP quality now affects both security posture and operational reliability. Weak server metadata does not just confuse developers; it creates ambiguous authority for agents that may call destructive tools, retry blindly, or inherit credentials through poorly constrained parameters.

Key questions

Q: What breaks when an MCP server's tool descriptions do not match its actual actions?

A: The trust model breaks. AI systems use the declared tool surface to decide when to call a function, so a harmless description masking a destructive action creates hidden privilege. That mismatch also undermines review, because security teams may approve the stated purpose while the runtime capability is materially broader.

Q: Why do stateless MCP servers require tighter authorization than session-based designs?

A: Stateless handling removes reliance on a prior handshake or session ID, so each request has to stand on its own. That reduces the value of session continuity as a trust signal and makes per-call authorization and policy enforcement essential. If the server cannot establish authority at request time, an agent can reach tools that were never meant to be broadly callable.

Q: What are the signs that an MCP deployment is being used unsafely by agents or downstream users?

A: Warning signs include unknown fields being accepted, risky write operations proceeding without approval, repeated retries creating duplicate actions, and tool calls reaching unexpected hosts or regions. You should also treat budget overruns, excessive concurrency, and missing audit spans as indicators that the control plane is not constraining behavior as intended. Those symptoms usually point to weak policy enforcement.

Q: Should teams prioritise safety annotations or richer tool documentation first?

A: Safety annotations come first when tools can delete, reset, or otherwise change state irreversibly. Rich documentation still matters, but a clear warning about consequence is the minimum control for high-risk actions. In practice, teams should fix both, then validate that the agent can distinguish safe reads from destructive calls before the server is approved for production.

Technical breakdown

How MCP server metadata shapes agent behaviour

MCP servers expose tools through machine-readable definitions, so the tool name, description, input schema, and error handling become the agent's operational map. When those fields are incomplete, the agent can still discover the tool, but it cannot reliably infer intent, safe inputs, or what a failure means. That is why descriptive quality matters as much as access control: the agent is making runtime decisions from the metadata. In practice, the protocol's stateless model reduces conversational memory, which increases the importance of each request carrying enough context to be safe and predictable. See the MCP Security Guide.

Practical implication: Treat tool definitions as security-relevant control surfaces, not developer convenience fields.

Why destructive tools need explicit safety signalling

A destructive or irreversible tool is one whose successful call changes state in a way that cannot be trivially undone, such as deleting, resetting, or clearing records. If the server names the tool neutrally and omits safety annotations, the agent has no built-in warning that the action carries material consequences. This becomes sharper in MCP because tool calling is the point of policy enforcement, not just discovery. The article shows that many such tools still lack annotations or elicitation, which means the protocol can route a harmful action before the user understands the consequence. Safety has to be expressed where the call is made. Read OWASP Agentic Applications Top 10.

Practical implication: Require explicit consequence signalling on irreversible tools before an agent can invoke them.

What stateless MCP changes for authorization and recovery

The July 28 spec makes MCP stateless, removes the handshake and session ID, and formalises Tasks and MCP Apps. That shifts trust from a long-lived session relationship to per-request and per-task handling. In a stateless model, authorization has to be asserted at the moment of each action because the server cannot rely on a prior session context to establish continuity. The same design also makes recovery guidance more important: if an agent retries after failure without knowing whether the operation partially succeeded, you get duplicated actions or unsafe escalation paths. The protocol's architecture therefore pushes governance upward into request design and server discipline. See the NHI Authentication Guide.

Practical implication: Design authorization and recovery so every request stands on its own.

Threat narrative

Attacker objective: The objective is to induce unsafe tool execution or credential exposure through weak MCP governance, then use that access path to alter data or operational state.

1. Entry occurs when an agent discovers and invokes an MCP tool through server metadata that is incomplete or ambiguous.
2. Credential exposure or misuse can follow when credentials are passed through tool parameters and then persist in prompt history or logs.
3. Escalation happens when destructive or irreversible tools are called without clear safety annotations or failure guidance, so the agent retries or proceeds blindly.
4. Impact is state change, data loss, or unintended action execution across production workflows, because the server allowed a harmful call path without adequate governance.

Breaches seen in the wild

• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP tool definitions have become a governance boundary, not a developer convenience. When an agent chooses between tools at runtime, the metadata attached to those tools is effectively part of the authorization surface. Missing descriptions, weak schemas, and unclear failure handling do not just reduce usability; they change how authority is exercised inside the workflow. Practitioners should treat server quality as a control issue, because the agent can only remain bounded if the tool contract is explicit.

Stateless MCP breaks the assumption that session continuity can carry trust forward. The protocol's new model is designed for request-level handling, not persistent conversational state. That means the old assumption, that a prior handshake or session context will keep access bounded long enough to supervise it, no longer holds in the same way. The implication is that governance has to move from session oversight to per-call authority design, because the trust boundary is now thinner and shorter-lived.

Destructive tool safety is a privilege management problem in disguise. When a server lets an agent call a reset, delete, or clear action without explicit annotations, it is effectively granting high-risk authority without making the consequence legible. That is why the 14% safety-annotation figure matters more than the average score. The field is still describing authority in ways agents can misread, and that is an NHI governance failure, not a documentation issue.

Credential handling inside tool parameters creates avoidable secret sprawl. The article's warning about keeping credentials out of tool parameters reflects a simple but still common failure mode: secrets end up in prompt history, logs, and downstream traces. Once that happens, the MCP server becomes a secret distribution path rather than a controlled access point. Practitioners should assume that any parameter-based credential flow expands the blast radius of compromise.

MCP quality is now separating systems that can be governed from systems that merely function. The ecosystem's growth is real, but the quality distribution shows that many servers are still not ready for production agent use. That gap is the new selection pressure in the market: builders who can prove safe tool semantics, recovery guidance, and bounded authority will be easier to operationalise. Organisations should use governance evidence, not popularity, to decide what enters the agent stack.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Security Guide

What this signals

Ephemeral authority is now the right mental model for MCP governance: once MCP becomes stateless, the old assumption that trust can accumulate across a session stops helping practitioners. A server must prove safety at the moment of the call, because the protocol gives the agent no durable trust envelope to lean on.

MCP governance should now be evaluated with the same seriousness as identity governance for workloads: what the server lets the agent do, how it signals risk, and how it recovers from failure are all part of the control plane. As adoption grows, the weakest point is not discovery, but whether the environment can keep tool authority legible under runtime pressure.

The growth curve matters because scale exposes the same structural issue at higher speed. More servers and more tools mean more opportunities for misdescribed actions, hidden destructiveness, and credential sprawl, so programme owners should expect governance work to move from design review into continuous validation.

For practitioners

• Define tool semantics as governance artefacts Document what each tool changes, what it returns, when it should be used, and when it should not. This gives agents enough context to avoid blind retries and ambiguous actions.
• Annotate destructive and irreversible actions Mark reset, delete, and other state-changing tools with explicit safety annotations and require user confirmation before execution proceeds.
• Remove credentials from tool parameters Pass secrets through controlled identity channels instead of embedding them in prompts or inputs where they can be logged or replayed.
• Test failure guidance as part of acceptance Verify that each server tells the agent whether to retry, correct an input, or stop when a call fails, rather than returning generic errors.
• Limit toolkit growth until definitions stay coherent Add new tools only when descriptions, schemas, and error handling remain consistent enough for an agent to use them safely at runtime.

Key takeaways

• MCP server quality is now an identity and governance issue because agents act on tool metadata, not just on human review.
• The ecosystem has grown quickly, but only 260 open-source servers earned an A and none earned an A+, which shows that maturity still lags adoption.
• Teams should focus on tool semantics, safety annotations, failure guidance, and credential handling before treating MCP servers as production-ready.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Agentic AI Security Guide · AI Agent Authorisation Guide

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool Annotation: Tool annotation is metadata attached to an MCP tool that helps the agent harness understand how the tool should be treated. Annotations can flag read-only behavior, destructive actions, or open-world content, allowing systems to add confirmation steps and reduce unsafe execution.
• Stateless protocol: A stateless protocol does not depend on a persistent session to understand or authorise a request. In MCP 2026-07-28, that means each call carries the context needed for routing and validation, which improves scale but makes request binding and integrity checks essential.
• Destructive tool: A tool that can materially change state, delete data, reset systems, or perform actions that are difficult to undo. For agentic workflows, destructive tools require explicit consequence signalling because the runtime decision-maker may not understand the impact without it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.