Audit a whole MCP setup

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations mark this readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description explains why: it starts (launches) every server, a real side effect on the environment. It also discloses the analytical output — toxic-flow combinations of untrusted-read/private-read/data-egress tools. It omits failure/timeout handling and any auth or resource expectations for launching many servers at once.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action, then the mechanism, then the payoff. The enumeration of toxic-flow conditions is the only length and it is doing real work, so nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the description still previews the key finding (toxic flows). It covers the launch-and-audit pipeline adequately; only edge behavior when a server cannot start or hangs is unaddressed for a tool that spins up many processes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With a single parameter at 100% schema description coverage, the schema already defines 'path' as the MCP config file. The description only repeats the same concept ('in an MCP config file') without adding format, path resolution, or relative-vs-absolute details, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (audit) over a specific resource (every server in an MCP config file) and what it produces (report of toxic flows). It also pinpoints the scope boundary against a sibling by saying it audits 'each one like inspect_server', so an agent knows this is the whole-config version, not the single-server one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'audit each one like inspect_server' frames this as the batch counterpart to inspect_server, giving clear usage context. It stops short of an explicit rule ('use inspect_server for one server, audit_config for a whole file') and never mentions check_server or scan_config, so the sibling routing is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.