uae_corporate_tax

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.