Africa Compliance Data

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the meaningful behavioral fact that the result depends on a country's working-day calendar, which explains why a country code is required. It stops short of saying whether the returned date is guaranteed to be a business day, what happens with an unknown country code, or the output format.

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?

A single twenty-word sentence with zero filler, and the operative concept (N working days from a start date) is front-loaded. Nothing is redundant with the title, though the terse phrasing leaves the sentence feeling more like a type signature than a 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?

For a three-parameter, side-effect-free date utility with no output schema, the essentials are present, but the description should say what the return value looks like (a YYYY-MM-DD string, presumably) and how invalid country codes or out-of-range offsets are handled. Annotations cover safety and the schema covers input formats, so the remaining gap is modest rather than severe.

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 67%: date and country are documented in the schema, while days is not. The description compensates partly by explaining that a negative days value moves backwards and that date is a start date, which is the key semantic the bare integer property lacks. It still does not clarify the calendar/holiday source used for the country or any edge-case behavior at the ±1000 bounds.

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: a date offset by N working days from a start date, with direction determined by the sign of N. That is clearly distinguishable from counting helpers among the siblings, though it never names or contrasts with count_business_days or is_business_day. It is a noun-phrase fragment rather than a verb phrase, but the operation is unambiguous.

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?

There is no when-to-use guidance, no mention of the sibling tools that do adjacent things (count_business_days, is_business_day), and no statement of prerequisites or limitations beyond the parenthetical about negative values. An agent must infer from the name alone which of the several date/holiday siblings to pick.

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?

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses genuine behavioral traits: domestic rate vs. lower treaty maximum selection, ambiguity handling (every option returned with its condition), and failure behaviour (no amount when a rate is unrecorded). It stops short of describing determinism, rounding, or the shape of the returned source citations, but the annotations already remove the safety burden.

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?

It is a single dense but front-loaded sentence-plus clause that establishes the core computation before covering edge cases. The deep nesting of parentheticals ('5/15', 'several domestic rates') makes it slightly harder to scan, but no sentence is wasted.

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 burden of explaining returns, and it does so by naming rate, amount withheld, net payment and sources. The main remaining gap is the absence of explicit sibling routing and of any note on result currency or precision for a 6-parameter tool.

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 83%, so the schema already explains date, amount, country, amount_is and recipient_country thoroughly. The description reinforces amount_is='net' gross-up and the dated-rate constraint but adds little syntax or meaning not already present in the property descriptions; baseline 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 computation (withholding tax on one payment) with explicit scope: a payment from one country to a recipient resident in another (or the same) country. It states the exact outputs (rate, amount withheld, net payment, sources), so an agent can distinguish it from the rate-lookup sibling get_withholding_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?

Usage context is clear: it is for computing tax on a single payment, and the 'amount_is net' case is called out with its gross-up consequence. It does not, however, explicitly route the agent between this tool and get_withholding_tax (lookup of rates/treaties), which is the most likely alternative an agent would consider.

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 cover safety and determinism (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description does add two real behavioral facts beyond that — counting is inclusive of both endpoints, and the result surfaces which holidays were skipped — but says nothing about weekend definition, invalid-range handling, or what happens when from > to.

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?

One tight sentence with the core quantity front-loaded and no filler. It is a fragment missing an explicit verb ('Returns the number of...'), which slightly blunts clarity.

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?

Three required, fully documented parameters and no output schema, so the description carries the return-value burden — and it does say the output includes holidays skipped. It is still thin on edge-case behavior (weekend conventions, reversed ranges, unknown country codes) for what is otherwise a simple computation tool.

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%, with formats, ISO country code pattern, and examples already documented, so the baseline is 3. The description adds only the word 'inclusive' about the date range, which is genuinely useful but does not extend meaning on the country parameter or boundary behavior.

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 the specific quantity (working days between two dates) and the scope (per country, inclusive), which lets an agent distinguish it from add_business_days and is_business_day. It is a noun phrase rather than a verb-led statement, and it never names those siblings, so it stops short of a 5.

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?

There is no explicit when-to-use guidance and no mention of the obvious alternatives (is_business_day for a single date, add_business_days for offsetting forward). The agent must infer from the name alone which of the three related tools fits its intent.

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 cover readOnly, idempotent, and non-destructive, so the safety profile is handled. The description adds substantive behavior the annotations cannot convey: entry granularity (one per changed value), ordering (oldest first), the kind taxonomy, and that result completeness varies by subscription plan — a real caveat an agent needs before drawing conclusions from an empty or short result.

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-loads the resource and its record shape, then closes with the optional filters and plan caveat. Mostly efficient, though the first sentence is a long comma-chained list and the plan sentence reads as a fragment.

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 must carry the return-value burden, and it does list the fields and ordering. However, it says nothing about pagination, limits, or volume of entries — meaningful gaps for a log-style endpoint that could return large result sets.

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%, with both since and country already documented in the schema including the YYYY-MM-DD and ISO alpha-2 formats. The description restates the same constraints ('since (YYYY-MM-DD)', 'one country') without adding new syntax or edge-case meaning, which is the expected baseline when the schema does the work.

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?

Names a specific resource (the change log) and states its shape: one entry per changed value, oldest first, with old/new value, kind, effective date, and source. This is far more than a restatement of the name. It stops short of explicitly distinguishing itself from near-siblings like get_finance_law_changes or get_vat_history, so an agent must infer the boundary.

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 plan-tier note ('Developer and Pro: holiday changes; Compliance: every change') tells the agent what data it will get but not when to pick this tool over the sibling history/law-change tools. No explicit when-not or alternative is named, so usage is implied rather than directed.

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 establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: availability is gated by plan, with the tax parts on the Compliance plan and, for countries in its country pack, on Pro. It does not say what happens for an unsupported country code.

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?

A single front-loaded sentence where the resource is stated first and the payload is enumerated after the colon. It is dense but every clause names real content; only the parenthetical entitlement note is slightly tacked-on.

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 one required parameter, rich annotations and no output schema, the description carries the return-value burden and largely discharges it by enumerating the data sections returned. It stops short of describing the response shape or how missing/unsupported countries are reported.

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%: the single 'country' parameter already documents the ISO 3166-1 alpha-2 format, the regex pattern and examples (KE, NG, ZA, CI, EG). The description adds no further meaning about the parameter, 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+resource ('All compliance reference data for one country') and enumerates the exact payload: holiday rules, announcement authority, VAT, withholding tax, tax ID format, filing deadlines and sources. This implicitly distinguishes it as an aggregate from siblings like get_vat, get_public_holidays and get_filing_deadlines, though it never names them as alternatives.

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?

Usage is only implied: an agent can infer this is the one-shot country overview versus the topic-specific siblings, but the description never says 'use this instead of calling get_vat/get_public_holidays separately' or when a narrower tool is preferable. No prerequisites or exclusions are given.

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 closed-world, so the safety profile is covered. With no output schema, the description earns credit for enumerating the response fields and the status vocabulary (mandatory, phased, voluntary, pilot, planned, unclear, none_found), but it says nothing about coverage limits, whether a 'none_found' result is an error, or data freshness.

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?

One front-loaded sentence with no filler; the enumerated field list is dense but each item maps to a meaningful part of the returned record. It would be stronger opening with an explicit verb rather than a bare noun phrase.

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 one-parameter lookup with no output schema, describing the returned fields is the right instinct and covers a lot. It falls short on the operational side: no indication of which countries are covered, how missing or ambiguous jurisdictions are reported, or how the phased dates are formatted.

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% with a single well-documented 'country' parameter including ISO 3166-1 alpha-2 examples, so the schema does the work. The description adds nothing about the parameter, so the baseline of 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?

The description is a noun phrase enumerating the fields of the returned record ('system... tax authority, status... model... dated phases... legal basis... integrators') rather than stating an action. It is clear what data the tool surfaces, which distinguishes it somewhat from get_vat or get_country_profile, but there is no explicit verb such as 'retrieve' and no direct contrast with those siblings.

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?

There is no guidance on when to choose this tool over get_vat, get_country_profile, or get_filing_deadlines, and no stated preconditions. The only implicit cue is that the record is scoped to e-invoicing/fiscalisation, leaving the agent to infer the routing itself.

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?

The annotations already establish read-only, idempotent, non-destructive, and closed-world behavior. The description adds meaningful behavioral detail about weekend/holiday adjustment rules and the fallback to the statutory date with adjusted: false. It does not discuss authentication, rate limits, or response structure, but the adjustment semantics are the key behavioral context for this tool.

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 a single front-loaded sentence that efficiently conveys the core purpose and adjustment behavior. The semicolon-delimited fallback clause is dense but informative. No sentence feels wasted, though the sentence is somewhat long and could be split for readability.

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 simple three-parameter lookup tool with annotations covering safety and idempotency, the description is largely complete. It explains the main behavioral nuance around weekend/holiday adjustments and the fallback adjusted: false. It does not describe returned fields or provide explicit alternative-tool guidance, but those gaps are minor for this tool.

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 only 33%, with only country described in the schema. The description adds some meaning via 'given month' and 'country's rule,' but it does not clarify year usage or the month range beyond what the schema constraints already state. It partially compensates for the coverage gap but not enough to raise the score above the baseline.

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: retrieving tax filing and payment due dates. It adds scope details such as the given month and the tax types covered (VAT, PAYE, withholding, corporate tax). It does not explicitly contrast itself with siblings like get_public_holidays or add_business_days, keeping it from a 5.

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?

Usage is implied by the required country, year, and month scope, but the description gives no explicit when-to-use or when-not-to-use guidance. It does not name alternatives such as get_public_holidays for holiday lookup or calculate_withholding_tax for tax computation.

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 a safe, idempotent read, so the description's job is content disclosure and it delivers: it warns the digest is unofficial and that the cited law prevails, and it specifies that effective dates and article references are included. What is missing is any note on coverage limits or how current 'latest' is, which matters for a compliance use case.

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 dense sentences with the content scope front-loaded and the legal disclaimer trailing, no filler. The parenthetical '(Compliance plan)' is cryptic and slightly muddies an otherwise tight statement.

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 single-parameter, read-only tool with complete annotations and a fully described schema, the description supplies the one thing structured fields cannot: what the returned digest contains and how authoritative it is. That is sufficient for an agent to call it 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?

Schema coverage is 100% and the country parameter is fully documented with the ISO alpha-2 pattern and examples, so the schema carries the semantics. The description adds no parameter-level information beyond the implied country scoping, making the baseline 3 correct.

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 the resource precisely (a country's latest finance law) and the output form (plain-English digest) and enumerates the tax domains covered — VAT, withholding, corporate, payroll, procedure — plus effective dates and article references. That implicitly separates it from rate-lookup siblings like get_vat and get_payroll_tax, but it never names the closest sibling get_changes, so an agent must infer the boundary.

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?

Usage is only implied: the parenthetical '(Compliance plan)' hints at the compliance-planning scenario, and 'latest' signals recency-oriented use. There is no explicit when-to-use, when-not-to-use, or statement of what to call instead for historical law changes (get_vat_history) or static rates.

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 read-only, idempotent, closed-world behavior, so the description's added value is the status model (estimated vs confirmed) and the disclosure that each confirmed entry carries its source. The plan-tier reference is valuable behavioral context about who announces or supplies the data, though it is phrased so vaguely that an agent cannot tell whether a lower-tier caller gets errors or partial data.

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?

It is a single dense sentence that front-loads the resource ('Across countries: holidays whose date depends on an announcement'), which is good. However, the trailing parenthetical about plans is syntactically tangled and the parenthetical stack (Eid, Mawlid, status, source, plans) makes it harder to parse than necessary.

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 burden of describing return values; it partially does so via status and source, but leaves the actual shape (holiday name, date, country, confidence fields) unspecified. For a simple two-parameter read tool this is adequate but not fully 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?

Schema coverage is 100%, with both parameters documented including format examples ('KE,NG,MA') and the default of 14. The description reinforces the look-back/look-ahead window, but adds no meaning beyond the schema for the parameters themselves, 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?

The description names a specific resource (announcement-dependent holidays such as Eid, Mawlid, moon-sighted and ad-hoc days off) and a specific window (a week back to N days ahead). It implicitly contrasts with get_public_holidays by scoping to announcement-dependent dates, but never names that sibling, so differentiation requires inference from the title.

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?

Usage is only implied: an agent can deduce this is for uncertain/announcement-driven holidays, but there is no explicit 'use this instead of get_public_holidays when...' routing. No exclusions or prerequisites are given, and the plan-tier mention ('Developer, Pro and Compliance plans') is ambiguous about whether it gates access or merely labels the announcer.

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 cover read-only/idempotent/non-destructive, and the description adds real context: the response includes every dated period with legal basis, source, and confidence, and no computation is performed. This is behavior beyond the annotation set, though pagination or volume expectations are not mentioned.

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?

One dense but well-structured sentence with the scope and the reference-data caveat front-loaded, followed by the returned content. Zero filler, though the parenthetical acronym chain is slightly heavy.

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 compensates by enumerating what comes back (bands, threshold, reliefs, dated periods, legal basis, source, confidence). Combined with annotations, an agent has enough to call it correctly; only response shape/pagination detail is absent.

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 both parameters are already documented, including the YYYY-MM-DD format, the today default, and ISO alpha-2 country examples. The description only restates the date-scoping semantics at a high level, adding little beyond the schema.

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+resource: income tax bands on employment income for resident employees, including bands, tax-free threshold, reliefs, and dated periods with legal basis. It also explicitly distances itself from calculation siblings with 'Reference data only, no salary calculation.'

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?

Clearly signals the when-not case (do not use this to compute salary tax; use a calculation tool instead) and frames the tool as a lookup of in-force reference data. It stops short of naming the alternative sibling like calculate_withholding_tax or get_withholding_tax explicitly.

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, and non-destructive behavior, so safety is covered. The description earns credit for disclosing that Islamic holidays are estimated pending reviewer verification and that delays are possible, which is real behavioral context beyond the annotations. It does not address response shape or pagination, so it sits above baseline but not at the top.

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 tight sentences, with the core resource and scope front-loaded before the estimation caveat. No filler, though the parenthetical status list is dense enough that it reads as a reference rather than prose.

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 does cover the meaningful parts of the return value (status taxonomy and sources) and warns about the estimation caveat. The residual gap is that it never explains what include_religious_scopes changes about the result set.

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 67 percent: country and include_religious_scopes are described inline, and year's bounds are enforced by the schema. The description restates country and year but adds nothing about include_religious_scopes, which is the one parameter whose effect (group-limited holidays such as faith, women, or public-sector) matters most for interpretation.

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 resource and scope: public holidays for a country and year, plus what each result carries (status values and sources). That distinguishes it from siblings like is_business_day or count_business_days, though it does not name any sibling explicitly.

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?

Usage is implied by the country+year framing, but there is no explicit guidance on when to call this instead of get_holiday_watch, is_business_day, or count_business_days, and no stated prerequisites.

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, closed-world, non-destructive behavior. The description adds meaningful context beyond that: the result includes every dated period with legal basis, source and confidence, telling the agent it gets historical, provenance-tagged data rather than a single snapshot.

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?

A single dense sentence, front-loaded with the resource and followed by the returned fields. The parenthetical levy list is long but earns its place by delimiting scope; nothing is wasted or repeated.

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 by enumerating rates, base, floor, ceiling, dated periods, legal basis, source and confidence. Combined with the fully described two-parameter schema, an agent has enough to call it 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?

Schema description coverage is 100%, so both parameters are already fully documented. The description restates the date semantics (in force on a date, default today) without adding format or edge-case detail beyond the schema — baseline 3.

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 the specific resource (statutory payroll contributions: pension, health, housing, work injury, training) and the exact data returned (employee/employer rates, base, floor, ceiling, dated periods with legal basis). It is clearly distinct from get_vat or get_payroll_tax by scope, though it never explicitly names a sibling to contrast with.

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?

Usage is only implied through content: an agent can infer this is the lookup for social-security rates on a given date, but there is no explicit when-to-use guidance versus get_payroll_tax or calculate_withholding_tax, and no exclusions or prerequisites stated.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's job is content disclosure, and it delivers: it lists the rate categories, conditions, dates in force and availability of official text. The paying-country framing also discloses a non-obvious behavioral constraint on how results are oriented. Remaining gap is minor — nothing about result volume or coverage gaps, though the schema's 'not_covered' note partially addresses that.

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?

A single dense sentence that front-loads the resource and then the returned fields; nothing is redundant or padded. It is a noun phrase rather than a verb-first statement, which slightly weakens the opening but keeps it compact.

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, so the description must carry return-value information, and it does by enumerating rates, conditions, dates in force and official text. For a three-parameter read-only lookup with full schema documentation and clear annotations, this is close to sufficient; only result volume and behaviour when no treaty exists are unstated.

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 and the description must add meaning to exceed it. It does: '(as the paying country)' clarifies that the country parameter denotes the payer, not the residence of the recipient, and 'for each treaty partner' explains what the partner parameter scopes. That is real semantics the schema does not state.

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 concrete resource (double tax treaties) and enumerates what is returned: maximum withholding rates on dividends, interest, royalties and technical fees, plus conditions, dates in force and official text. The parenthetical '(as the paying country)' sharply fixes the perspective, which distinguishes it in substance from get_withholding_tax or calculate_withholding_tax. It stops short of naming an alternative outright, so sibling differentiation is inferable rather than stated.

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?

Usage is implied: an agent can infer this is for looking up treaty rate tables rather than computing a liability (calculate_withholding_tax) or reading domestic statutory rates (get_withholding_tax). However, no explicit when-to-use or when-not-to-use statement appears, and no prerequisites (e.g. that the country must have treaties in force) are mentioned.

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?

The annotations already declare readOnly, idempotent, closed-world behavior, so safety is covered. The description adds real content beyond that — registration threshold, legal basis, and that a dated lookup returns the law that set the rate — but says nothing about behavior for unsupported countries or invalid dates.

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 dense sentences, front-loaded with the resource and return contents, then the optional date behavior. Every clause earns its place; minor density at the cost of readability but no waste.

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 two-parameter read tool with no output schema, the description adequately enumerates what comes back (rates, threshold, legal basis) and the effect of the optional date. The remaining gap is sibling disambiguation against get_vat_history.

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 both parameters are already documented, including the YYYY-MM-DD pattern and ISO code format. The description adds only modest meaning: that the date affects which standard rate is returned and includes the originating law, without clarifying whether the other fields (threshold, legal basis) are also dated.

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?

Names the resource precisely (VAT/GST/TVA/IVA rates, registration threshold, legal basis) and covers the multilingual aliases an agent might search for. It is clear what the tool returns, but it does not differentiate itself from the sibling get_vat_history, which overlaps with the dated-history behavior described.

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?

Usage is only implied: pass a country to get rates, pass a date to get the historical rate. There is no explicit when-to-use or when-not guidance, and no alternative tool (e.g. get_vat_history) is named despite the obvious overlap.

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, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral scope: only 'standard' rates are returned (implying reduced/zero rates are excluded), every period is included, and each row carries the enacting law. Ordering and country coverage are not stated.

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?

One sentence that front-loads the resource and scope, then the returned fields, then the use cases. Nothing is redundant and nothing is padding.

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?

No output schema exists, and the description compensates by naming the returned tuple (from, to, rate) plus the legal basis, which is exactly what an agent needs to interpret results. For a single-parameter read tool this is sufficient; only ordering and jurisdictional coverage are left implicit.

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?

There is a single required parameter with 100% schema description coverage, including the ISO 3166-1 alpha-2 pattern and examples, so the schema carries the full burden. The description adds no meaning beyond 'for a country', which is the baseline for a fully documented parameter.

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 resource with clear scope: 'Every standard VAT rate period for a country (from, to, rate) with the law that set it.' The word 'history' plus the 'standard' qualifier separates it from the sibling get_vat (current rates), though it never names that sibling explicitly.

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?

Three use cases are given ('audits, refunds and re-invoicing'), which implies a retrospective-lookup context, but there is no explicit 'use get_vat for current rates instead' routing and no statement of when not to call it. Usage is inferred rather than directed.

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, closed-world, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — that recipient_country triggers an additional treaty-rates dimension of the response — but says nothing about coverage gaps, result shape, or what happens if recipient_country equals the paying country.

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 tight sentences, front-loaded with the core resource and followed by the conditional extension. The trailing ellipsis in the payment-type list is slightly sloppy but costs little.

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 should hint at the return structure (e.g., per-payment-type rate pairs, treaty sub-object). It signals the treaty addition but leaves the overall response shape and the behavior for unsupported countries undocumented, which is a real gap for a lookup tool.

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 75%, and the description still adds meaning: it explains that recipient_country produces treaty maximum rates and enumerates the payment-type families the enum covers. It does not elaborate on the date parameter's 'not_covered' fallback beyond what the schema already states.

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 resource (withholding tax rates) and scopes it precisely: resident/non-resident by payment type, plus treaty maximum rates when recipient_country is set. It does not, however, distinguish itself from siblings like calculate_withholding_tax or get_tax_treaties, leaving the reader to infer the rates-vs-compute vs rates-vs-treaty split.

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?

Usage is implied through the payment_type and recipient_country conditions, but there is no explicit instruction on when to call this instead of calculate_withholding_tax (to compute an amount) or get_tax_treaties (to inspect treaty text). No exclusions or prerequisites are stated.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description still adds real value by defining what counts as a business day (weekends plus national public holidays), which is behavioral semantics not present in any structured field. It stops short of covering invalid country codes or regional/sub-national holiday handling.

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?

A single compact sentence with the key definition front-loaded in the parenthetical, and zero wasted words. The clipped grammar ('Whether a date is...') makes it read as a fragment rather than a complete statement, which slightly reduces clarity.

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?

This is a simple two-parameter predicate with full schema documentation, rich annotations, and no output schema, so the description need not explain return values. The only meaningful gap is the absence of any note on invalid or unsupported country codes, which is a minor omission for a tool of this complexity.

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%: both parameters carry patterns and concrete examples (ISO 3166-1 alpha-2 country codes, YYYY-MM-DD dates). The description adds nothing about either parameter, 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?

The description names the resource (a date, in a country) and the check performed (whether it is a working day), which is specific enough to distinguish it from siblings like count_business_days and add_business_days. It is a noun fragment rather than a verb phrase, and it does not explicitly contrast itself with those siblings, so it falls just short of a 5.

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?

There is no when-to-use guidance, no stated preconditions, and no mention of the closely related siblings (count_business_days, add_business_days, get_public_holidays) that an agent could confuse this with. Usage is only inferable from the tool name itself.

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 establish read-only, idempotent, closed-world and non-destructive behavior, so the description only needs to add context — and it does, disclosing the fixed scope (54 countries), the payload fields, and the three-state coverage vocabulary an agent must interpret. It stops short of describing ordering or output shape, which is minor for a static reference list.

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?

One sentence, front-loaded with the verb and the scope, followed by the return contents and the coverage vocabulary. No filler, no restatement of the title.

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 and no parameters, the description carries the burden of explaining the return value, and it does name the key fields and status values. A brief note on how the coverage statuses should be acted on would make it fully self-sufficient.

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?

Zero parameters, so there is nothing to disambiguate; the baseline of 4 applies. The description correctly implies the call is argument-free.

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?

Specific verb ('List') plus a precise resource ('the 54 African countries covered') and the fields returned (currency, per-feature coverage status). It implicitly separates itself from get_country_profile (one country) by scoping to the full covered set, but never names the sibling explicitly.

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 phrase 'covered' and the ready/partial/gap taxonomy imply this is a discovery/pre-flight call before drilling into a country, but there is no explicit when-to-use statement and no mention of get_country_profile as the follow-up alternative among 19 siblings.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behaviour: the number is not stored, and it introduces the 'format_check' result concept with a 'partial' strength level. However it never explains what other format_check values exist or how weak vs strong results should be interpreted, so the added value is real but incomplete.

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?

Three short sentences, each front-loaded and each carrying a distinct fact: what is checked, what it does not prove, and the side-effect guarantee. Nothing is redundant with the title, and the 'not stored' privacy line is placed last where it belongs.

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 two-parameter read-only validator with no output schema, the description covers purpose, scope and side effects adequately. The notable gap is the response shape: 'format_check partial' is referenced with no indication of what the other possible outcomes are or what other fields come back, leaving the agent guessing at the result contract.

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 50% (country documented, value undocumented beyond min/max length), so the description must compensate. 'Taxpayer identification number' implicitly defines the otherwise bare 'value' parameter, which is a meaningful addition, and 'the country's known format' clarifies that country selects the rule set — a non-obvious dependency the schema does not state. It does not describe accepted characters or formatting conventions for value, so it stops short of a 5.

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 ('Check whether a taxpayer identification number matches the country's known format') and immediately scopes it against the confusable neighbour concept of registration validation. An agent can tell this is a pure syntactic/format check rather than an authoritative verification.

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 line 'Format check only: it does not confirm registration' gives a clear use condition and an explicit non-use boundary, which is exactly the distinction an agent needs before answering a compliance question. It stops short of naming a sibling alternative for the registration case, so it is clear context rather than full routing guidance.

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