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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds non-obvious context beyond that: an API key is required, and no fresh sampling or website fetch occurs, which tells the agent the records are previously returned artifacts. Return format and pagination behavior are still unstated.

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 short sentences, front-loaded with what is read, then the caveat, then the constraint. Every sentence carries information; it could be tightened only marginally by folding the caveat into the usage sentence.

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 read-only tool with no output schema the safety and no-fetch behavior are adequately covered, but the description omits any mention of paginated results or result limits despite the schema exposing limit and cursor. An agent gets enough to call it but not enough to handle the response.

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 0% across 3 parameters, so the schema names fields without explaining them. The description mentions the owning observation but never explains check_id, and says nothing about limit/cursor pagination semantics, leaving the burden unmet.

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?

States a specific verb ('Read') and resource ('source/citation records') scoped to 'an owned observation', which separates it from geo_get_observation and geo_get_answers at a glance. It stops short of explicitly naming the sibling it is not, so it does not reach the top of the range.

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?

'A URL alone does not prove support for a claim' implies the intended interpretive use, and 'no new sampling or website fetch' tells the agent this is a retrieval, not a triggering operation. However, there is no explicit when-to-use-vs-alternative routing (e.g., get_sources vs geo_get_answers), so usage is only implied.

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