EOR Scope

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

Beyond the readOnly/non-destructive annotations, it discloses three things an agent could not infer: results exclude Employer of Record fees, rows return in request order rather than ranked, and the data is a dated snapshot. It also adds a scope disclaimer ('cost comparison, not legal or tax advice') that matters for how an agent frames the answer.

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?

Roughly five short sentences, zero filler. The core intent and the numeric scope lead, then the sibling exclusion, then the caveats — a well front-loaded structure where every sentence carries information.

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 an output schema present and annotations covering safety, the description supplies exactly the missing layer: scope boundaries, the sibling decision rule, data currency, and exclusions from the returned figures. Nothing an agent needs in order to call this correctly 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 75%, with countries, salary_usd and salary_period already well documented in the schema. The description reinforces the 2–10 country bound and the 'same salary applied to all' semantics, but adds nothing about salary_period or payments_per_year beyond what the schema says, 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 states a specific verb and resource — the statutory employer cost of one identical gross salary across 2 to 10 countries — and gives a concrete example. It also explicitly distinguishes itself from the closest sibling (compare_offers) so an agent can route without opening either 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?

It names the triggering intent with natural-language examples in two languages, and states an explicit exclusion rule: 'Do not use when each country has its own salary (use compare_offers).' That is a when/when-not/alternative triple.

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=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: what the totals include (statutory employer charges, excluding EoR fees), how monthly salaries trigger the statutory 13th/14th month, row ordering, and a data snapshot date. However, with an output schema present and annotations covering safety, these additions are helpful context rather than filling a disclosure gap, so a 3 is warranted.

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 'Use this when' trigger and the exclusion, which is the right ordering. It is somewhat long and repeats the monthly-salary point twice with two long parenthetical examples, a small amount of redundancy for an otherwise tight single paragraph.

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?

Given an output schema exists, the description need not explain return values, yet it still sketches them (totals, ratio to smallest, contribution ceilings) which only helps. For a read-only comparison tool with a fully documented schema, nothing an agent needs to call it correctly is missing.

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 nested field (salary, country, salary_period, salary_currency, payments_per_year) is already documented in the schema. The description reinforces the monthly case and gives currency examples ('240,000 PLN'), but adds no semantics the schema does not already carry. 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 operation (compute total employer cost) over a specific input (2-6 country/salary offers) and immediately names the sibling it is not: 'Do not use when the salary is the same in every country (use compare_countries)'. An agent can distinguish it from compare_countries, compare_structures or employer_cost without opening a 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?

It gives explicit entry conditions (multiple offers in 2-6 countries, each with its own gross salary), an explicit exclusion plus the alternative tool to use instead, and two worked natural-language examples including one in French. Nothing about selection is left to inference.

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/non-destructive/closed-world, and the description adds genuine context: the method (user-entered fees plus statutory employer charges), the computed output (crossover headcount), the data snapshot date 2026-10-22, and a clear 'cost comparison, not legal or tax advice' boundary. It does not discuss currency/rate assumptions or how the statutory charges are sourced, leaving a little undisclosed.

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 trigger scenario, then the method, then the scope exclusions and data vintage. Five sentences, all load-bearing — the example query and the 'costs only' caveat each prevent a distinct class of misuse.

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 12 parameters, a nested assumptions object, annotations, and an output schema, the description carries its share: it states the horizon, the method, the crossover output, the cost-only boundary, and data freshness. It does not explain the assumptions override keys or the USD-vs-local currency interaction, though the schema points to the employer_cost answer for the former.

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 parameters are already documented, yet the description adds framing that explains why the inputs exist: entity setup and annual costs and EOR/contractor fees come 'from the user' as quoted, while statutory employer charges are filled in by the tool. That mapping of user-supplied vs computed inputs is exactly the semantics an agent needs when deciding what to ask the user for.

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 comparison (EOR vs own entity vs contractor) with a defined output — total cost over a 1-5 year horizon and the headcount crossover point. The example question ('from how many employees should we open an entity in Poland instead of using an EOR?') makes the tool's distinct role unmistakable against siblings like employer_cost or compare_countries.

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?

Opens with an explicit trigger ('Use this when the user is deciding between hiring through an EOR, setting up their own entity, or engaging contractors') and scopes the horizon to 1-5 years. It adds a clear exclusion (cost only, not lawfulness or legal/tax advice) but never names a sibling tool such as employer_cost as the alternative for a single-country cost breakdown, so routing depends on inference.

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?

Goes well beyond the readOnly annotations by disclosing the computation method (annual cost incl. statutory employer charges and optional EOR fee, divided by working days), the default working-day basis (260 minus statutory leave and holidays), the data snapshot date, and a scope disclaimer. These are exactly the behavioral details an agent needs to trust and frame the answer.

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?

Four sentences, front-loaded with the trigger and example, then the formula, then scope exclusions and date. Dense but every sentence carries signal; only the trailing disclaimer could be trimmed slightly.

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 an 11-parameter tool with an output schema and full param descriptions, the description supplies the remaining gaps: methodology, defaults derivation, data vintage, and scope limits. Nothing an agent needs to invoke or interpret it correctly is missing.

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 100% schema coverage the baseline is 3; the description adds real meaning by explaining that working_days defaults from 260 minus country leave/holidays, that both are adjustable, and that the EOR fee only applies when the user supplies one. It doesn't clarify salary_period/payments_per_year interplay, but that is already handled in 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: converting an employee's total annual cost into a contractor day/hour rate, with a concrete example query. It is clearly distinct from siblings like employer_cost or compare_offers, which don't produce a contractor-rate equivalent.

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?

Opens with an explicit trigger ('Use this when the user asks what day or hour rate a contractor would need...') and includes exclusions ('it does not say whether a contractor arrangement is lawful or how to classify a worker'). The agent knows both when to call it and what it must not be used to answer.

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 description adds substantial behavioral context beyond the annotations: only enacted dated changes are applied, budget-announced changes are a separate flagged variant, deduced dates are flagged, untracked countries return today's cost plus 'not yet tracked' rather than a projection, and currency formatting is specified. These details materially affect interpretation of results.

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 dense and front-loaded, beginning with the usage trigger and then layering projection rules, edge cases, and output currency behavior. Every sentence carries operational value, including the snapshot date and disclaimer, with no 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?

For a complex projection tool with an output schema, the description covers the important unknowns: what changes are included, how unenacted or deduced changes are treated, how untracked countries behave, and what currency the response uses. Nothing an agent needs in order to invoke or interpret the tool correctly appears to be missing.

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 all parameters are already documented in the schema. The description reinforces a few behaviors, such as same gross salary and exchange rate and default date behavior, but does not add meaningful parameter semantics beyond the structured schema. 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 states a specific verb and resource: projecting statutory employer cost to a future date. It clearly distinguishes this from a current-cost lookup by explaining that it returns both today's cost and the future cost, applying only enacted dated changes. An agent can identify the scope without needing sibling schemas.

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 gives a clear triggering scenario: the user budgets an employee for next year or a future date and asks how employer cost will move. It also explains edge cases such as untracked countries and budget-announced changes. It stops short of explicitly naming employer_cost as the alternative for present-day cost, so it lacks full when-not guidance.

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 and non-destructive behavior, and the description adds substantial context: per-contribution rates, bases, ceilings, sources, check dates, totals, floor/ceiling wording, local-currency return with USD in brackets, and the data snapshot date. It also discloses the 13th/14th month treatment and that results exclude Employer of Record fees.

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 long but front-loaded and logically ordered: purpose, output contents, special-case rules, exclusions, and data caveats. The multiple parenthetical example queries add some bulk, but every sentence carries useful routing or behavioral information.

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?

Given seven parameters, a nested assumptions object, and an output schema, the description is complete enough for correct invocation. It covers the calculation basis, currency behavior, unusual salary period handling, total-cost definitions, and the important disclaimer that this is a cost comparison rather than legal or tax advice.

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, but the description usefully reinforces salary_period semantics: monthly salaries are passed as given and the country's statutory extra months are applied. It also gives a concrete assumptions override example, though much of the remaining parameter detail is already in 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 and resource: computes the employer-side cost of an employee in a country, including social security, payroll taxes, pension, insurance, and levies. It clearly distinguishes itself from siblings like compare_countries and max_salary_for_budget by focusing on a single country's statutory employer burden.

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 explicit when-to-use cues with concrete example queries in multiple languages, plus strong exclusions: not for net pay, income tax, legal advice, or provider fees. It does not explicitly route the agent to a named sibling for related alternative tasks, which keeps it just short of a 5.

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 this as a safe, closed-world read. The description adds real context beyond them: each term carries its source and check date, and the data snapshot is dated 2026-10-22, telling the agent how fresh and how auditable results are. It does not state coverage limits (which countries have data), which would have earned a 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 trigger condition, then examples, then exclusions — good ordering with no filler. The trailing 'Cost comparison, not legal or tax advice' reads as boilerplate that is slightly off-topic for a statutory-terms tool rather than a cost comparison.

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?

An output schema exists, so return values need no explanation, and the description covers scope, exclusions and data currency. The only omission is country coverage — whether every country is supported or where list_countries fits — which an agent might reasonably want before calling.

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?

A single parameter at 100% schema coverage, with the schema already specifying ISO 3166-1 alpha-2 or country name. The description adds no format or edge-case guidance beyond that, 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 ('statutory minimums') and enumerates the exact dimensions covered: paid leave, public holidays, probation, notice period, 13th-month pay. This clearly separates it from the compare_* siblings, which are about cost comparison rather than statutory facts.

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?

Explicit trigger ('when the user, hiring in a country, asks about statutory minimums'), two concrete example queries, and an explicit exclusion ('Do not use for legal advice on a specific dismissal, contract dispute or visa'). Nothing is left for the agent to infer.

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/destructive annotations, it discloses the data snapshot date (2026-10-22), the rate basis (official rate of the snapshot, with source and date returned), exactly what cost components are included (gross plus statutory employer charges, excluding EOR fee), and a scope disclaimer ('Cost comparison, not legal or tax advice'). It also previews the response shape: cost at each move and the breakeven move for a budget.

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?

Information is front-loaded: when to use, then what is returned, then the exclusion, snapshot date, and disclaimer. It is a dense single block and the return-value sentence is long, but nearly every clause carries decision-relevant content.

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 a full output schema, 100 percent parameter documentation, and annotations covering safety, the description still supplies the pieces structured fields cannot: the snapshot vintage, the rate source, cost-component boundaries, and the breakeven-move behavior. An agent has everything needed to decide and call 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 percent, so all six parameters are already documented, including the country/salary/budget roles and the assumptions override. The description only implies the budget parameter's effect on output (headroom) and adds nothing about salary_period, payments_per_year, or override semantics, so it sits at 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?

States a specific operation on a specific resource: returns USD cost at the official rate plus the USD cost under 5/10/20 percent moves, and budget headroom if a budget is supplied. It also carves out a boundary ('Do not use for currency conversion alone'), which separates it from the plain cost and comparison siblings such as employer_cost or compare_offers.

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 trigger is explicit and even quoted bilingually ('pays, or plans to pay, an employee in local currency... asks about exchange-rate risk or a USD budget'), and an exclusion is given for pure conversion. What is missing is naming the sibling to use instead for baseline employer cost or for finding the max affordable salary, which would complete the routing picture.

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=true, destructiveHint=false, and openWorldHint=false. The description adds useful context beyond them: the returned fields, the data snapshot date, and a cost-comparison/legal-advice disclaimer.

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 main use case, then the exclusion, then freshness and disclaimer context. Each sentence carries useful information with no repetition.

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?

Given one optional parameter, a present output schema, and clear read-only annotations, the description supplies everything needed: use case, exclusions, return contents, snapshot date, and scope disclaimer.

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?

The single optional region parameter is fully documented in the schema, so the schema does the heavy lifting. The description reinforces regional filtering and gives examples, but adds little syntax or behavior beyond the schema 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?

Names a specific verb and resource (list countries), states the EOR Scope coverage scope and regional filtering, and distinguishes the tool from employer_cost. An agent can identify it without 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?

Explicitly says when to use it (user asks which countries are covered or wants countries in a region) and when not to use it (detailed country cost, use employer_cost). This is strong routing guidance against a relevant sibling.

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 (read-only, non-destructive, closed-world), and the description adds substantive behavior: employer charges plus optional EOR fee are deducted from the budget first, ceilings/floors/bands/fixed amounts are honored, the monthly salary is expressed at the country's statutory payment count, and currency round-tripping is stated. It also discloses the data snapshot date and the not-legal-advice caveat, which go well beyond structured fields.

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 use case and quoted examples, then the mechanics, then caveats — a sensible order with no filler sentences. It is a dense single paragraph, but nearly every clause carries decision-relevant information.

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 annotations, a full input schema, and an output schema, the description supplies the remaining essentials: budget semantics, fee ordering, rounding/period behavior, and data freshness. Nothing an agent needs to invoke it correctly appears missing.

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 earns an extra point by clarifying that the budget is all-in and that eor_fee_usd_month is removed from the budget before solving, plus that local-currency input returns local currency with USD in brackets. It still leaves the `assumptions` override barely explained beyond the schema text.

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 computation (largest gross salary whose statutory employer cost fits the budget) on a named resource, and ties itself to the employer_cost ledger, which distinguishes it from siblings. The inverse relationship to employer_cost is clear enough that an agent can pick correctly.

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 concrete trigger phrasing in two languages and an explicit exclusion ("Do not use for net pay"), which is strong when-to-use guidance. It does not name the alternative tool to use instead for net pay or for budget-free salary lookups, so routing is clear but not fully closed.

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 declare read-only, closed-world, non-destructive behavior. The description adds valuable context beyond annotations: how monthly quotes in 13/14-payment countries are interpreted, that local currency amounts are returned in local currency with USD in brackets, the data snapshot date, and a clear 'cost comparison, not legal or tax advice' disclaimer. No contradiction with 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?

Front-loads the when-to-use clause and then provides logical supporting details. However, it is lengthy with multiple examples and could be tightened; some sentences overlap in purpose. Still, every sentence contributes useful context for a complex tool.

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?

Given 9 parameters, nested objects, and an existing output schema, the description is complete: it covers when to use, what the tool checks, how currencies and payment periods are handled, and includes a data snapshot and disclaimer. An agent has enough to invoke it correctly without needing to consult siblings or external docs.

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 high (89%), so baseline is 3. The description adds meaningful guidance: 'Pass the amounts as written on the quote; the provider's name is never needed' and explains the interaction of salary_period with statutory payments (e.g., 14 salaries in Spain). This supplements the schema without duplicating it.

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 ('checks') and resource ('quote lines against the statutory ledger of the country'), and details what it computes (expected vs quoted amounts, missing lines, non-statutory charges, gap split). This distinguishes it from siblings like compare_offers by focusing on validating a user-provided quote against statutory data.

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?

Explicitly says when to use ('when the user shares a quote... and asks whether it is fair, correct...') and includes a when-not condition ('Do not use without figures from the user'). However, it does not name alternative tools (e.g., employer_cost) for cases where the user lacks a quote, leaving routing to siblings implicit.

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?

Goes well beyond readOnlyHint: it discloses that each change carries a status (enacted vs announced), whether the date is stated or deduced, and a word-for-word source quote with reading date. It also warns that 'not yet tracked' does not mean nothing is scheduled, and pins the data snapshot date — exactly the kind of epistemic caveats an agent needs to avoid overstating results.

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 trigger condition before the return semantics, and every clause (status, deduced dates, quotes, snapshot date, disclaimer) carries information. It runs long and bundles the disclaimer into the same sentence as the data snapshot, but nothing is 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?

An output schema exists, yet the description still summarizes the meaningful payload (status, date provenance, source quote) so the agent knows what it is getting. With one fully-documented parameter and annotations covering safety, nothing needed to call this correctly is missing.

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% (ISO alpha-2 or country name), so the parameter is already fully documented. The description only refers to 'a country's' contributions and adds no format, ambiguity, or edge-case guidance beyond the schema, so 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: retrieving scheduled statutory employer contribution changes (rates, ceilings, floors, thresholds, effective dates, budget announcements). None of the siblings (compare_countries, cost_next_year, employer_cost) cover forward-looking statutory change tracking, so the boundary is implicit but unmistakable.

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?

Opens with an explicit trigger ('use this when the user asks what is changing...') and gives concrete multilingual query examples that make the intended intent recognition unambiguous. It stops short of naming which sibling to use instead for current-year rates or cost comparison, so the negative case is only covered by the 'cost comparison, not legal or tax advice' caveat.

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 read-only, non-destructive annotations, the description discloses what is computed (gross salary, statutory employer charges, total employer cost, difference and ratio to the smallest total, contribution ceilings) and notes the data snapshot date. It also clarifies that this is a cost comparison, not legal or tax advice, which is useful behavioral context.

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 dense but front-loads the main usage condition and keeps the most important details early. It includes some extra clauses, but they generally earn their place by clarifying invocation order, display mode, data freshness, and legal scope.

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?

Given the rich annotations, full schema coverage, and presence of an output schema, the description is complete enough for correct invocation. It covers purpose, when to call, relationship to sibling tools, display behavior, computed outputs, data snapshot, and disclaimer.

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 offer fields are already well documented. The description adds limited parameter-level meaning by saying it takes the same offers as compare_offers and is limited to 2 to 6 countries, but most of that is also evident from 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?

The description states a specific presentation action (showing employer cost of job offers or salaries as a readable table) with a precise scope of 2 to 6 countries. It clearly distinguishes this display tool from comparison siblings by saying it computes the figures itself and takes the same offers as compare_offers.

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 tells the agent when to use this tool (when the user wants employer cost shown or displayed as a table) and how to call it (directly with no data tool first, or after compare_offers or compare_countries with their widget arguments). It also gives display-mode guidance: inline up to 3 countries, full screen above.

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/destructive annotations it discloses what the output actually contains (salary basis, per-line rate, base, floor/ceiling, source and check date, monthly/annual toggle, recalculation field, CSV copy) and the data snapshot date 2026-10-22, plus an explicit non-advice disclaimer. This is substantive behavioral context an agent cannot get from 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?

Front-loaded with the use case, then invocation rule, then output contents — a sensible order. It is dense with stacked parentheticals and example phrases, so it runs long, but almost every clause carries information.

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?

An output schema exists, so return structure need not be explained, yet the description still tells the agent what will be rendered and that a CSV copy is available. Combined with the snapshot date and the 'computes figures itself' note, an agent has everything needed to call it correctly on the first try.

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 schema already documents salary, country, assumptions, salary_period, salary_currency and payments_per_year including the monthly/statutory-payments interaction. The description's own parameter contribution is mostly the cross-tool rule that it accepts the same country/salary/assumptions as employer_cost, which is useful but marginal. 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?

States a concrete verb-and-resource: display the line-by-line employer cost of one employee in a country as a table or card. The split from employer_cost is explicit — that tool computes, this one renders the figures and computes them itself — so an agent can distinguish it from siblings without reading schemas.

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 explicit when-to-use triggers ('show me the breakdown', 'display it as a table', plus a non-English example) and an explicit invocation rule: call directly with no data tool first, or after employer_cost passing through the `widget` arguments. Alternatives and ordering are both spelled out.

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