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

Annotations already signal read-only and non-destructive behavior. The description adds value by disclosing parallel fan-out across 80+ authoritative sources, categorized return blocks, and source attribution metadata. It does not mention latency, rate limits, or errors, but the most important behavior is covered.

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 wastes little: it states what data is returned, when to call, what triggers the call, and which sources are used—all in a few sentences. It front-loads the core purpose and places the integration note at the end without redundancy.

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 6-parameter tool with no output schema, the description is solid: it covers the operative trigger, source scope, output type, and relevant examples. It could be stronger about expected result usage or edge cases like broad domains, but it is not incomplete enough to cause confusion.

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 coverage is 100%, so the param descriptions already explain query, geo, brands, domain, graph_ids, and userId. The tool description adds context about the kinds of queries that benefit from supplemental data but does not materially deepen the meaning of individual parameters. Baseline 3 is appropriate.

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 clearly identifies the tool as retrieving supplemental market data from a set of external sources and explicitly ties it to search_graph coverage gaps. It names a concrete resource type (macro, institutional, real-time market data) and distinct behavior (parallel retrieval from 80+ sources), helping an agent distinguish this from graph or research tools.

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 description gives explicit trigger conditions: use it when curated coverage is thin/empty, or when the query is demand/attention-shaped, and after search_graph indicates thin coverage. It does not enumerate when-not-to-use scenarios or alternative sibling tools beyond search_graph, but the conditions are specific enough to guide selection.

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