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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds valuable behavior: it confirms the tool queries the corpus directly, avoids web fetching due to EUR-Lex blocking, and requires a Premium API key. It also clarifies that the corpus is authoritative. This goes beyond the annotations by explaining the data source and access prerequisites. However, it does not disclose potential error conditions or response format, though an output schema exists, so it never falls below a 4.

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 is well-structured: a purpose sentence, rationale, key requirement, supported codes, and an Args section. It front-loads the primary action. The list of 20 supported codes is somewhat long but necessary for correct invocation; it could arguably be moved to an external reference, but keeping it in the description prevents errors. No redundant words, and each sentence adds value. Slightly verbose due to the code list, but appropriately so.

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?

Given the tool's complexity (two parameters, one optional; read-only; output schema present), the description covers all necessary ground: what it returns, data source, why not to use web fetch, API key requirement, supported inputs, and the behavior of omitting article. The output schema handles return structure, so no additional format explanation is needed. It is complete for an agent to select and invoke correctly.

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?

The schema provides only titles without descriptions (0% coverage), so the description carries full responsibility. It delivers: 'regulation: Short regulation code (case-insensitive, e.g. 'gdpr', 'dora')' and 'article: Optional article number (e.g. '28', '30', '5'). Omit to browse all obligations for the regulation.' These are clear, include examples, and explain default behavior for article. The list of acceptable regulation codes is also included, making both parameters fully self-documenting.

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 opens with a clear statement: 'Return verbatim obligation text from the Velvoite corpus for an EU regulation article, plus the canonical EUR-Lex URL for reference.' This names a specific verb (return), resource (EU regulation article in Velvoite corpus), and output (verbatim text + URL). It also lists supported regulation codes, further clarifying scope and distinguishing it from broader tools like get_obligations.

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 explains why this tool exists: 'Queries the Velvoite corpus directly — no web fetching required. EUR-Lex blocks direct web fetch; the corpus has the authoritative text.' This gives the agent a clear decision heuristic (use when you need verbatim obligations and want to avoid web fetch issues). It also states the API key requirement and the optional article parameter behavior. However, it does not explicitly name alternatives or exclusions (e.g., vs. search_eu_regulation_text), so it doesn't fully earn a 5.

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