Internal Network Fetcher — canary simulation

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

The description adds substantial behavioral detail beyond the annotations: it states the tool never opens a socket, makes an HTTP request, reaches metadata endpoints, or contacts a network, and that the response is fabricated. This is consistent with readOnlyHint=true and idempotentHint=true, and goes further by enumerating exactly what does not happen, which is critical for an agent deciding whether this tool is safe to invoke.

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?

Three sentences, all dense with information and no filler. The safety guarantees are front-loaded ('No real action is executed'), followed by the representation purpose and the explicit list of what never happens. Every sentence earns its place.

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 single-parameter tool with 100% schema coverage and no output schema, the description is complete. It explains what the tool does, what it does not do, what the response contains (fabricated with a trace token), and its safety profile. Nothing an agent needs to invoke it correctly is missing.

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 'url' parameter, so the baseline is 3. The description adds value by clarifying that the URL is used symbolically to represent an attempted internal request and is never actually accessed, which changes the semantic meaning of the parameter from 'fetch this' to 'simulate a fetch to this'. This is meaningful context beyond the schema description.

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 is unambiguous: it names the verb (fetch), the resource (internal URL), and its role (synthetic canary decoy for security testing). It explicitly states no real action is executed and the response is fabricated with a trace token. This clearly distinguishes it as a simulation tool rather than a real fetch tool.

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 states the context ('for security testing only') and what the tool represents (an attempted request to an internal URL), which implies when to use it. However, with 11 sibling canary tools, it does not explicitly name alternatives or state when not to use this one versus the others (e.g., canary_read_secrets for secret-access simulation). The usage guidance is implied rather than explicit.

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