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

No annotations are present, so the description must disclose behavioral traits on its own. It explains the conceptual meaning of feed failure (a quiet window may indicate a stopped feed), but it does not explicitly state read-only guarantees, side effects, auth/rate limits, or how fresh the 'last answered' data is. The provided context is useful but not a full behavioral disclosure.

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, each earning its place: the first lists the returned fields, the second explains why the tool should be used, and the third redirects to a sibling. The middle sentence is slightly metaphorical but carries meaningful guidance, and the structure front-loads the core content.

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 zero-parameter read tool with no output schema, the description covers the returned data fields, the use case, and the key alternative. It does not explain interpretation of fields like failure streak or record count, but an agent has enough to call the tool correctly. Minor gaps remain but are not critical.

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?

There are zero parameters, and the schema confirms an empty object. Per the rubric, 0 params earns a baseline of 4; the description adds no parameter-specific detail because none is needed.

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 states exactly what the tool provides: feed metadata (id, sector, last-answer time, failure streak, record count). It is clearly distinct from geo_latency by naming the specific alternative, and it does not conflate with other siblings like geo_records or geo_coverage.

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 instructs when to use this tool ('Read this before trusting a quiet window') and gives the condition that should route the agent to geo_latency ('For how late each feed's records arrive'). This is direct, actionable guidance with no inference required.

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