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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful operational context beyond that: 'Algeria only (country DZ); other countries return country_not_available' and the key_required behaviour for TN/MA, plus the note that abrogated rules are excluded by default.

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 purpose is front-loaded, but the body is a sprawling wall of text that dumps the entire substantive VAT content — article numbers, abrogated points, individual exempt goods, historical changes — most of which is answer content rather than selection or invocation guidance. Much of it does not earn its place in a tool description.

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?

There is no output schema, and the description does compensate by describing what each item carries (legal basis, article, finance law, official text read in) and by covering scoping, error cases and default filtering. An agent has enough to call it correctly, though the sheer volume makes the operative guidance harder to extract.

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 the schema already documents every parameter, including the q example and the treatment enum values. The description's 'Filters: q ..., treatment ..., in_force ...' paragraph largely restates that structured content, adding only a sample query word ('formation'), so the baseline 3 applies.

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 — 'Get the VAT (TVA) regimes of Algeria in force in 2026' — and immediately enumerates what a returned item contains (legal basis, article, finance law, official text). It is clearly distinct from siblings like get_tax_rates or get_tax_code_article, which cover rates or single articles rather than the full regime list.

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 an explicit decision rule: 'Use it before saying which VAT rate applies to an activity: an activity that is not in the 9 % list or the exemptions is taxed at 19 %, unless the business is under the IFU or the auto-entrepreneur status.' That is strong when-to-use guidance, but it never names the alternative tools (e.g. calculate_ifu, get_tax_rates) or states when this tool is the wrong choice.

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