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

Well beyond the readOnly/idempotent annotations, it discloses that translations come back flagged non-authoritative with the original attached, and that the gated.citedByArticle and gated.nationalMandate counts require an API key on a signed-in account while the provision text is always free. This tells an agent which response fields may be unavailable and why. No contradiction with 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?

Two dense paragraphs where every sentence earns its place: core payload, parameter guidance, citation-row handoff, and the free-vs-gated access model. The purpose is front-loaded in the first sentence and nothing is repeated from the annotations or schema.

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 present, the description compensates well by naming the return payload (text, in-force window, status, concept tags, transposition edges, provenance, gated counts) plus the translation and auth caveats. It does not address error behavior or the exact shape of non-gated fields, a minor gap for a complex legal-data tool.

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?

All four parameters are already documented in the schema (100% coverage), so the baseline is 3; the description adds real value by framing asAt as point-in-time law and revealing that lang triggers translation behavior with a non-authoritative flag and attached original. eId and work gain little beyond the schema, keeping this at a modest bump above baseline.

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 statement — 'Authoritative text of one provision' — and enumerates the enriched payload (in-force window, repealed/prospective status, concept tags, transposition edges, provenance). This clearly separates it from siblings like provision_history and search_legislation, which concern a provision's change over time and discovery rather than single-provision retrieval.

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 explicit parameter usage ('Use asAt (YYYY-MM-DD) for point-in-time law and lang for a translation') and routes one concrete case to an alternative — 'the rows themselves... come from provision_context.' It does not, however, map other relevant siblings (e.g., provision_history, search_legislation) to their selection conditions, so the when-not guidance is partial rather than systematic.

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