csrd_scope

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

Annotations already declare this as a safe, idempotent, closed-world read, so the description correctly focuses on substance: it discloses that the result is a per-financial-year verdict and that the size test and third-country test are reported separately. It also pins the legal basis to specific directives and amendments, which is valuable behavioral context. It stops short of describing the verdict's shape or edge-case handling, but no output schema exists to cover that either.

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 concrete question set before the return description. The question enumeration is long but earns its place by helping an agent pattern-match a natural-language query to this tool. No filler sentences.

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?

For a nine-parameter, zero-required tool with no output schema, the description carries the return-value explanation ('verdict per financial year ... with the size test and the third-country test shown separately'), which compensates for the missing output schema. The schema handles which parameters feed which test. Minor gap: no guidance on what happens when all optional inputs are omitted.

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 every one of the nine parameters is already documented in the schema. The description adds only indirect linkage (mentioning the size test, third-country test, and Omnibus postponement), which loosely maps to parameters but supplies no format or constraint detail beyond the schema. The baseline of 3 is appropriate.

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 capability (answering CSRD scope/applicability questions) and enumerates the exact question types it resolves, from applicability to first reporting year to ESRS standard and assurance level. It is unmistakably distinct from the sibling regulatory tools (cbam_cost, eu_ai_act_classify, uae_corporate_tax) because it anchors on CSRD and the ESRS framework.

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 question list makes the usage context clear: invoke this when an agent needs a CSRD scope verdict. It also distinguishes the size test from the third-country test, implying the routing condition for the two evaluation paths. However, it never states when not to use it or names an alternative tool for overlapping regulatory questions.

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