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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the live window turnover (~2 minutes) and the error message behavior that distinguishes aging out from typos. It also clarifies the tool returns only that row. This goes beyond annotations, though it does not detail the return format or any rate limits, which are not covered.

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 a compact paragraph with no filler. The purpose is front-loaded, and every sentence contributes: purpose, comparison to siblings, parameter guidance, behavioral note, and alternative routing. No redundancy.

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?

Given the tool's low complexity (one parameter) and the rich annotations covering safety, the description is largely complete. It explains the single-row return, the time-window behavior, and error messages. The only minor gap is that it does not explicitly state the return format or object structure, but since there is no output schema, a more explicit statement would be helpful. Still, the description covers the critical operational aspects.

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 description coverage is 100%, so the parameter correlation_id is already fully described in the schema, including accepting the full id or short handle. The description reiterates this and adds a usage hint ('cite the handle, pass it back here') but does not introduce new semantic information beyond the schema. Baseline 3 is appropriate.

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 clearly states the verb ('Fetch') and resource ('one signal by its id'), and immediately adds the condition 'when you already know which one you want.' It distinguishes from siblings by explaining that other read tools return sets and bound them, while this returns a single row. This is specific and non-tautological.

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?

Explicitly provides when to use (when you already know the id) and when not to, naming alternatives: 'To find signals rather than re-read one, use search_signals or scope_signals; to reach the ones about the same subject, use get_related_signals.' This is direct routing guidance with no ambiguity.

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