Bindler: UAE Corporate Tax, CSRD scope, EU AI Act and CBAM calculators

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

Annotations already declare this is a read-only, idempotent, closed-world calculation, so the safety bar is met. The description goes further by disclosing the internal model: the free-allocation phase-out factor from Directive Article 10a(1a), crediting carbon price already paid in origin, and pricing the same basket every year so the trajectory is visible. That is genuine behavioral context beyond the 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 structure is front-loaded with the example questions that both explain scope and aid retrieval, followed by the concrete regulatory mechanics. The question list is somewhat repetitive with the following sentences, but each element earns its place as a semantic trigger. No filler or marketing language.

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 calculation tool with no output schema, the description never indicates what the response looks like (total cost, per-line breakdown, certificate count, year-by-year trajectory). The input side is thoroughly covered, but the return shape is left entirely to inference, which is a real gap for a tool whose whole purpose is producing a number.

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 the baseline is 3. The description adds meaning beyond the schema: it anchors the 'year' parameter to the 2026-2034 phase-in window, enumerates the applicable sectors, and reinforces the origin carbon-price offset. The rationale for the certificate price (the server will not invent a market price) is carried in the schema, so this is reinforcement rather than novel detail.

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 states a specific computation ('Computes the CBAM certificate cost of importing goods into the EU'), names the governing regulation and the exact input domain (all six Annex I sectors, 2026-2034 phase-in). It is unmistakable against the unrelated siblings eu_ai_act_classify and uae_corporate_tax. An agent knows exactly what resource this produces before opening the 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?

The opening question list is an explicit set of when-to-use triggers ('what will CBAM cost me', 'do I have to pay CBAM on this shipment'), and 'Use this rather than estimating' names the alternative approach and the reason (the phase-in factor changes yearly and is often wrong). It lacks an explicit exclusion or named sibling alternative, but the routing intent is clear and unambiguous.

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

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.

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

Annotations already declare readOnly/idempotent/non-destructive, and the description supplements them with what is returned (risk class, article-numbered obligations, application date, fine ceiling) and the specific trap areas (Annex III list, Article 6(3) exemption, staggered dates) where models commonly err. It omits any caveats about input completeness or determinism, so a 4 rather than 5.

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?

Front-loaded with the user-facing questions before the formal definition, so an agent can pattern-match quickly. The enumerated question list is long but each item maps to a distinct use case; no sentence is pure filler.

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-value burden and does so explicitly (class, obligations, dates, fine). For a 10-parameter, zero-required classifier it does not address the legacy/pre-cutoff pathway despite placed_on_market_before_cutoff being an input, leaving one meaningful gap.

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 70% and the schema enum lists are already exhaustive for annex_iii_use_case and prohibited_practice. The description loosely maps concepts to parameters (Article 5 to prohibited_practice, Article 53 to general_purpose_model, Article 50 to transparency_obligation_article_50), which is helpful, but it never explains does_profiling, placed_on_market_before_cutoff, or how role changes the answer.

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?

States a specific verb and resource ('Classifies an AI system under Regulation (EU) 2024/1689') and enumerates the concrete outputs (risk class, obligation set with article numbers, application date, maximum fine). It also names the legal domains covered (Article 5, 6, Annex III, 53, 50), which cleanly separates it from the unrelated siblings cbam_cost and uae_corporate_tax.

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 final sentence gives an explicit alternative: 'Use this rather than recalling the classification,' and lists example questions that trigger use. It gives no conditions under which NOT to use the tool and no prerequisites, but the retrieval context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that: it discloses that the result is returned as a full line-by-line computation with the governing Article behind each line, and that elect_small_business_relief defaults to showing tax with and without the election.

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 opening question list is long but front-loaded and functions as a query-matching surface that helps an agent recognize relevance. The computation sentence that follows is dense and information-rich, with little filler. Slightly verbose but each clause carries routing or domain value.

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 complex tax-computation tool with no output schema, the description does the heavy lifting: it explains the computation model, the rules applied, and the return format (line-by-line with Articles). The remaining gap is parameter-level detail for roughly two-thirds of the 23 inputs, but the operational picture is largely complete.

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?

With 23 parameters and only 35% schema description coverage, the description must compensate and it does so partially: it names the SBR threshold, the AED 375,000 0% band, the 9% rate, QFZP/de minimis, the Article 30 AED 12,000,000 safe harbour, and the 75% loss cap. However, a large share of inputs (interest_income, exempt_dividends, foreign_tax_credit, fines_and_penalties, depreciation_and_amortisation, participation_exemption_income, etc.) receive no semantic coverage in either schema or description.

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 states a specific verb and resource: 'Computes UAE Corporate Tax payable for one tax period under Federal Decree-Law 47 of 2022.' The opening list of concrete questions and the enumeration of computation components (SBR, 0% band, 9% rate, QFZP, Article 30 interest cap, Article 37 loss relief) make the tool's scope unmistakable and clearly distinct from the unrelated siblings cbam_cost and eu_ai_act_classify.

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 explicitly instructs 'Use this instead of estimating UAE Corporate Tax' and explains why the tool is preferable (thresholds and interactions between SBR, QFZP and the interest cap are commonly got wrong). This gives clear when-to-use context and names the alternative (manual estimation), though it does not state exclusions or when a simpler estimate might suffice.

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