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

Annotations already mark the tool as readOnlyHint=true, and the description adds value beyond that by explicitly stating 'No fresh provider requests' – confirming it does not trigger external API calls. It also clarifies the data semantics ('Unknown and failed reads are distinct from not named'), which is a meaningful behavioral disclosure about how missing data is represented. This goes beyond the annotation and provides useful 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 only one long sentence, which is brief, but it is awkwardly phrased and packs multiple concepts into a comma-separated list. It is not front-loaded with a clear verb or resource; the most important action (returning saved observations) is never explicitly stated. It could be reworded into clearer, more structured sentences.

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 has no parameters and no output schema, the description covers the cached nature and data distinctions, but it still lacks an explicit statement that this tool retrieves prior regional observations. It also does not mention any limits (e.g., how much data, time range, or format), leaving some gaps for an agent deciding to call it. It is minimally complete but not thorough.

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?

The tool has zero parameters, and the schema is an empty object with 100% coverage by definition. Per the calibration baseline, a 0-parameter tool defaults to 4. The description does not need to explain parameters, and it doesn't attempt to, which 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 lists what is 'saved' (areas, buyer questions, engine naming observations, retained samples, read coverage) and states 'No fresh provider requests,' implying a cached retrieval. However, it never explicitly uses a retrieval verb like 'returns' or 'gets,' leaving the action to inference from the tool name. It also does not distinguish itself from sibling tools like get_visibility, so purpose is clear but not sharply defined.

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 provides no direct guidance on when to use this tool versus alternatives. The statement 'No fresh provider requests' hints that this is a cached snapshot, which could imply using request_rescan for fresh data, but this is not stated. There is no explicit when-to-use or when-not-to-use guidance, leaving the agent to guess.

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