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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety behavior is clear without description-level disclosure. The description adds some domain context about scoped datasets and coverage/rights, but it does not mention response format, pagination, or any operational quirks. This is consistent with the annotations, so no contradiction.

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 description is a single focused sentence with no filler, and the intended action is front-loaded via 'Discover scoped...'. It is appropriately concise, though the phrase 'coverage and rights' is compressed to the point of mild ambiguity.

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 one optional parameter and no output schema, the description should clarify what product values mean and what kind of result an agent should expect. It does neither. An agent could guess the purpose but would not know how to correctly select a product or interpret the returned datasets. The description is minimally usable but 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 the description never mentions the 'product' parameter or its enum values (seiche, liquilens, undertow). The schema only provides allowed values without meaning, and the description does not explain how selecting a product changes the results. The single parameter is left semantically opaque.

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 uses a specific verb ('Discover') and a clear object ('scoped funding, institution and chain-settlement datasets') to identify the tool's core function. It conveys a catalog/discovery role, though it does not explicitly differentiate itself from the sibling research_* tools. The mention of 'coverage and rights' adds a distinguishing flavor but leaves some ambiguity.

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 guidance on when to use this tool versus research_analysis, research_entities, or other siblings. No conditions, exclusions, or alternatives are given. The imperative 'Discover' only weakly implies that an agent should call this when looking for datasets, but that is left to inference.

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