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

With no annotations, the description carries the full burden, and it does add real behavioral semantics: it defines what a RESOLVED verification means (offsets match hash-verified text and the graph quote) and states that gaps such as pending custody and unresolved citations are surfaced rather than hidden. However, it says nothing about auth requirements, error/not-found behavior, or how the claims_limit/claims_offset pagination behaves despite those parameters existing.

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?

It is front-loaded with the resource, but the bulk arrives as one long run-on sentence stuffed with parentheticals that is hard to parse. 'One request' is cryptic and does not clearly earn its place. Dense but not well-structured.

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 rightly spends its words on the return shape, and that coverage is genuinely good. But for a tool with zero annotation coverage, 0% schema coverage and paginated parameters, the missing parameter semantics, pagination behavior, and routing guidance leave the definition materially incomplete.

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% and there are 3 parameters, so the description needed to compensate and largely does not. 'One opportunity' loosely implies nb_id targets a single record, but claims_limit and claims_offset are never mentioned, so pagination semantics are documented nowhere. None of the three parameters is explained.

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 makes it clear this fetches the evidentiary bundle for a single opportunity, and the enumeration of documents plus Graphify claims pins down the resource precisely. It never states an explicit verb ('returns'/'fetches'), but an agent can tell it is a read-style retrieval of aggregated evidence. It does not contrast itself against siblings like get_opportunity or get_document_text.

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?

There is no when-to-use or when-not-to-use guidance and no named alternative; an agent cannot learn from the text when get_evidence beats several targeted calls to get_document_text/get_document_download/list_documents. The trailing 'One request' hints at batching efficiency but is too terse to count as routing guidance. No prerequisites or context conditions are given.

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