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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses what annotations cannot: the upstream source, the $0.002 USDC cost per successful call, the x402 payment rails (Base, Solana, Arc), and the charge policy that failed calls are free. It also clarifies that criteria are returned as text, which is behavioral detail an agent needs before committing to a paid call.

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?

Two sentences, front-loaded with the verb, source and regulation before pricing. The first sentence is long and semicolon-stacked, which slightly hurts scannability, but every clause (source, outputs, scope boundary, cost, payment rails, refund policy) carries information an agent needs.

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 an output schema present, return-value detail is unnecessary, and the description covers what remains: authoritative source, regulatory basis, scope limits, both query modes, payment/auth requirements and charge policy. An agent can decide whether to call and how to call it without further context.

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 100%, so the baseline is 3; the description still adds value by framing activityId as the second step of a two-call workflow ('from a list result') and by tying NACE/keyword inputs to the returned sector, NACE codes and objectives. It stops short of explaining filter interaction or defaults beyond language.

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 names a specific verb and resource — an EU Taxonomy (Regulation 2020/852) activity lookup from the European Commission's Taxonomy Compass API — and enumerates both output modes (eligible activities by NACE code/keyword with sector, NACE codes and objectives; screening criteria for a single activity). It also draws an explicit boundary ('Activity rules only, not company disclosures'), which distinguishes it from disclosure-oriented siblings such as energy_sec_esg_climate_filings.

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?

It clearly signals the two usage paths — keyword/NACE lookup for lists versus activityId for substantial-contribution and DNSH criteria — and states an exclusion (company disclosures). What's missing is any guidance on picking among the mutually exclusive filters (q vs nace vs objective) or what happens when none is supplied given zero required parameters.

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