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

Annotations only declare readOnlyHint=true and openWorldHint=false; the description goes well beyond that by disclosing the staleness behavior, the caller_verifies verification obligation, the bearing proof-token handoff, and an epistemic caveat that a citation is not evidence the claim is true. With no output schema, this is exactly the behavioral context the agent needs before acting on the text.

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 purpose and required inputs are front-loaded in the first sentence, and each clause carries information. The closing epistemic caveat is somewhat tangential to invocation mechanics, but it is short and relevant to how the returned text should be treated.

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?

With no output schema, the description fully covers the return contract (source_url, text_fragment_url, caller_verifies, bearing/null), the stale-result failure mode, and the follow-up tool. Nothing an agent needs to invoke this correctly or interpret its response 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 description coverage is 100%, so all three parameters are already documented, including the 'exact query string' and 'exact limit' semantics. The description restates the q/limit/id coupling but adds no format, boundary, or edge-case detail beyond the schema, so the baseline of 3 applies.

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 and resource ('Get one cited result from source_search') and scopes it to a single fragment, which cleanly separates it from the sibling source_search that produces the result set. The relationship to source_verify_bearing (bearing token) is also named, so an agent can place the tool in the workflow without opening any schema.

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?

Gives a hard prerequisite (reuse the exact q and limit from the originating source_search plus a result id) and a recovery path ('If the results have changed since your search, the call says so; run source_search again'). It also tells the agent what to do when caller_verifies is true. There is no explicit when-not-to-use or alternative-tool comparison beyond the implied dependency on source_search.

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