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

Annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false) already signal an external side-effecting call, and the description aligns rather than contradicts. It adds substantial context beyond annotations: the tool makes an outbound network request and analyzes whatever text the server returns, the verdict is bound to a hash so a server that later changes its tools cannot inherit an old clean verdict, and the call is metered with explicit cost and endpoint details. This is rich behavioral disclosure that materially affects how an agent should use the result.

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 dense but front-loaded: the core purpose and usage trigger occupy the first sentence, followed by mechanism, detection categories, return shape, and metering. The pricing details ($0.03 USDC, endpoint path, target type) are slightly beyond what is needed for tool selection, but they are legitimate operational context for a paid tool. Every sentence earns its place; the only cost is length.

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?

For a tool of this complexity — an outbound scanner with hash-bound verdicts — the description covers purpose, mechanism, output shape (verdict, evidence line, hash), threat categories, and cost. The output schema exists, so return values need not be fully re-explained. The only notable gap is failure behavior (unreachable servers, non-MCP endpoints, timeouts), which is minor given how much else is disclosed and the presence of structured schemas.

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 coverage is 100% for the single required `url` parameter, so the schema already documents it and the baseline is 3. The description adds only marginal parameter context — the url is the MCP server endpoint to check before connecting — and does not give format constraints beyond what the schema presumably provides. It does not compensate or contradict, landing at the baseline.

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 a specific verb and resource — "Check an MCP server BEFORE you connect to it" — then explains the mechanism (ask the server to introduce itself and list tools, analyze the returned text) and enumerates the specific threats detected (tool poisoning, secret-exfiltration parameters, cross-server shadowing, invisible unicode). This is clearly distinguished from the lockfile/attestation siblings by domain and from scan_artifact by target type, so an agent can pick it correctly without opening the schema.

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?

"BEFORE you connect to it" gives an explicit temporal trigger for when this tool should be called, and the threat list tells the agent what kinds of servers warrant scanning. It does not, however, name when-not-to-use conditions or route to an alternative for the same task — scan_artifact is mentioned only for metering parity, not as a decision point. Clear context without exclusions.

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