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

The description discloses that the tool 'does not invoke any target tool or make LLM calls,' ensures results are deterministic, and limits headers to reading the remote tools/list response. It also warns against using file paths/$ref and instructs reading definitions from client context. These behavioral traits go well beyond the annotations (read-only, idempotent) and add meaningful context.

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?

The description is about three sentences, front-loaded with the core purpose, then behavior, then input guidance. Each clause provides necessary information without fluff, fitting comfortably in one paragraph.

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?

With an output schema present and no sibling tools, the description covers the tool's inputs, behavior, fallback, and exclusions. The instructions on how to obtain snapshot from client context and ask user for endpoint fully contextualize when and how to invoke this tool.

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?

Schema already describes all parameters, and the description adds critical semantics: snapshot can be an MCP `name` or Cursor-style `tool`, should not be file paths/$ref, and should contain a tools array. It clarifies that headers are optional and only used while reading the remote tools/list response. This meaningfully enriches the schema definitions.

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?

The description opens with 'Statically audit an MCP tool surface' and specifies both input sources (public HTTPS URL or tools/list snapshot) and the scope (deterministic scores and findings). It clearly distinguishes this as a read-only audit tool that never invokes target tools, making the purpose unambiguous.

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 description explicitly instructs when to pass another installed server's definitions as a snapshot, when to ask the user for a public endpoint or tools/list JSON, and what to avoid (file paths or $ref). It also says 'instead of inventing an audit,' providing clear fallback guidance. This addresses usage and alternatives very well.

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