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

With no annotations, the description carries the full burden and does so well: it discloses per-call cost ($0.02), both auth paths (x402 USDC-on-Base settlement vs. subscriber API key via Bearer/X-API-Key/query), the ranking behavior (NOT_YET_ON_X first), and a data-accuracy disclaimer. It stops short of rate limits, pagination, or return-shape behavior, so it is strong but not complete.

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?

Purpose and source coverage are front-loaded, which is good, but the payment/auth paragraph and the get_catalog cross-sell are dense and consume a large share of the text. The filter list is a bare comma run rather than structured guidance, so the length is only partly earned.

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 and no annotations, the description covers what the tool returns (verbatim snippets from primary documents), how it is paid for, how to authenticate, and which filters exist. Gaps remain around result structure, pagination, and the limit parameter, but the core calling requirements are present.

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% across 5 parameters, so the description is the only source of parameter meaning. It merely enumerates four names (since, min_score, event_type, not_yet_on_x) without explaining accepted date formats, the score scale for min_score, or valid event_type values, and omits 'limit' entirely; only the NOT_YET_ON_X ranking note adds real semantics.

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+resource ('ranked primary-source scoops for a posting desk') and enumerates the exact upstream sources (SEC EDGAR 8-K/Exhibit 99.1, Form 4, PR Newswire, BEA/BLS/Census/Fed/Treasury), which is far more specific than a bare name. However, it never contrasts itself with near-neighbors like get_recent_intel or get_spaces_intel, so an agent must infer the boundary from the source list alone.

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 names the four filters and notes 'NOT_YET_ON_X ranks first', which implies usage, but it gives no explicit when-to-use/when-not guidance and never routes the agent to a competing sibling for a different need. The only routing hint, 'Browse every tool + price first with the FREE get_catalog tool', is about pricing discovery, not tool selection.

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