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

Annotations already cover read-only, idempotent, non-destructive and open-world, so the safety profile is set. The description adds real behavioral context beyond that: it defines prepared_response as 'evidence is available to review, not freshness, safety or completion,' states there is no account or execution authority, and notes that source restrictions, dates, units, missingness and hashes stay explicit. Those caveats materially change how an agent should interpret results.

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 compatibility role and per-workflow formats are front-loaded, and every sentence adds information rather than restating the name. Some phrasing is telegraphic ('Source restrictions, dates, units, missingness and content hashes remain explicit'), which is dense but still earns its place.

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?

An output schema exists, so return structure needn't be described, and the description still usefully interprets the prepared_response field. Combined with per-workflow selection semantics and the no-execution-authority caveat, it is nearly complete; the remaining gap is guidance on choosing this tool over the exposed siblings.

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%, so the description must carry the load, and it does: it explains what `selection` means for each of the three enum values, including cardinality and format, plus the empty-string default behavior. Only the 160-character limit and validation-failure behavior are left unaddressed.

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 first sentence states a specific role: a compatibility entry point that fronts three named sibling tools (funding, institutions, exit). That is concrete and distinguishes it from the individual workflow tools by name. It stops short of explaining why an agent would pick this dispatcher over calling those siblings directly, which leaves the core purpose slightly ambiguous.

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 per-workflow selection formats (three-letter currency; 1-5 slugs; 1-4 USD sizes) and the 'empty selection uses published defaults' rule give practical invocation guidance. However, the crucial routing question — when to use this compatibility wrapper versus the individually exposed siblings — is only implied by 'No additional operation is available,' never stated explicitly.

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