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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial context beyond them: data provenance (bundled from the acts, reviewed as of `verified`), computed fields (days_until computed today), ordering (date then id, no paging), dataset scale (26 obligations under 12 laws from 19 acts, 11 moved dates across 7 amending acts with history retained), and metering/free-quota behavior. The rate-limit and partial-sample disclosure ('up to 3 records, without file proof, history or paging cursor') is exactly the kind of behavior an agent cannot infer from annotations.

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 first three sentences are exemplary and front-loaded: purpose, alternatives, inputs, output. But roughly the final third is a long, repetitive metering paragraph, including an off-topic clause about 'a sanctions name search with no match' that has nothing to do with compliance deadlines, and it restates free/paid error policy twice. That bulk dilutes an otherwise tight definition.

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, the description carries the return-shape burden and does so: as_of, verified, count, laws[], and deadlines[] field-by-field including id, days_until, status, source URL, quote, SHA-256 and history. It also documents the empty-filter case and the degraded free-tier response, so an agent knows what it will actually receive in each mode.

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 baseline is 3; the description earns one more by stating the combination semantics the schema does not encode — 'all optional, they narrow together' — which tells the agent the filters AND rather than OR. It also clarifies that `law` must come from the returned laws list and is case-insensitive, and that omitting all filters yields the full set. It stops short of adding format nuance beyond the schema's own YYYY-MM-DD notes.

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?

Opens with a specific verb+resource+scope: 'Returns statutory EU compliance dates (CBAM, EUDR and other laws) with the Official Journal source, quote and SHA-256'. It explicitly separates itself from three named siblings (compliance_get_deadline, tenders_list_deadline_changes, funding_list_changes), so an agent can route without opening any schema.

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?

Gives both when-to-use ('browse or filter deadlines and to find ids') and when-not-to-use with the exact alternative for each case: one known id -> compliance_get_deadline, tender deadlines -> tenders_list_deadline_changes, grant deadlines -> funding_list_changes. It also states the no-filter default behavior ('returns every date... without paging'), removing the main ambiguity for an optional-param list tool.

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