Geo-Parity

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

The description goes well beyond the readOnly/idempotent annotations by disclosing that the total is a floor when 'complete' is false, that 'missing' names unpriced components, that a zero total is legitimate and potentially misleading, and that depositMonths is a stated assumption rather than a measurement. This gives the agent the mental model needed to interpret results safely.

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 every sentence earns its place: it defines the resource, gives reading order, explains floor semantics, warns about zero totals, and clarifies the epistemic status of depositMonths. The key scoping statement is front-loaded before the caveats.

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 schema's strong parameter coverage, the read-only annotations, and the presence of an output schema, the description covers all critical calling and interpretation aspects: input components, output caveats, missing-data behavior, assumptions, and passport/destination edge cases. Nothing essential is left for the agent to guess.

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 input schema already covers 100% of parameters with useful descriptions, so the baseline is 3. The description adds important meta-semantics, especially that depositMonths is an assumption with no underlying global dataset, and that income is irrelevant to the arrival total. This extra context improves parameter understanding 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?

The description states a specific resource and scope: the cash needed to arrive somewhere, itemized as entry fee, first month's rent, deposit, and verified long-stay visa fee. It explicitly contrasts this with ongoing monthly costs, which distinguishes it from related cost tools like compare_total_cost and estimate_micro_costs without requiring the agent to infer intent.

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 description clearly frames when to use the tool ('to ARRIVE somewhere' versus 'what a month costs once you live there') and gives operational guidance like 'READ complete BEFORE totalUsd'. It does not explicitly name sibling tools to use for the monthly-cost case, so it stops short of a full when-not/alternatives statement.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by disclosing the calculation formulas, the data providers (World Bank, IMF, OECD, Penn World Table), and the US baseline of 1.0. It does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two focused sentences. The first sentence front-loads the input conditions and exact outputs; the second sentence adds data provenance and baseline context. There is no filler or redundant restating 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?

Given a rich input schema (100% parameter coverage), the presence of an output schema, and annotations covering read-only/idempotent behavior, the description is complete enough. It covers the core computation, inputs, outputs, and data provenance, while edge details like source defaults and city behavior are already captured in the schema.

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 each parameter already explained in detail. The description adds value by clarifying how income and pppIndex relate in the formulas, but it does not add significant semantics for the target or source parameters beyond what the schema already provides.

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 ('returns') applied to a clear resource (purchasing power parity calculations), lists the exact computed outputs with formulas, and specifies the input conditions (US-denominated annual income + target country code). This clearly distinguishes it from siblings like localize_salary or compare_total_cost.

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 description implies when to use the tool: when you have a US-denominated annual income and want purchasing-power-adjusted local figures for a country. However, it does not explicitly state when not to use it or name any alternative sibling tools, leaving the agent to infer routing from context.

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 idempotent behavior. The description adds valuable behavioral context: the fixed/local burn split, city-level vs national cost-of-living scaling, and the list of returned fields. It also appropriately frames the output as estimates from purchasing-power data, not financial advice.

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 compact, front-loaded with the user benefit, and each sentence contributes: audience, computation, method, output, and caveat. No filler or redundant restatement of the tool name or schema.

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 tool with 7 parameters and an output schema, the description covers the calculation approach, inputs, output fields, and limitations. Combined with the 100% schema coverage and safe annotations, an agent has everything needed to invoke it correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how burn is split into fixed and local slices and how only the local slice scales by cost of living, which directly clarifies burn, fixed, and targets. This is genuine semantic enrichment, not schema repetition.

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 immediately states the specific outcome: computing extra months of runway from relocating to a cheaper hub. It defines the audience, the method, and the returned metrics, making it clearly distinct from siblings like compare_total_cost or calculate_ppp.

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 clear context for when this tool fits: founders/freelancers stretching savings by relocating to a cheaper hub. It does not explicitly name alternatives or exclusion conditions, but the use case is specific enough to guide selection among the sibling tools.

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 detail beyond the annotations: log-normal modeling, GNI/Gini calibration, null statutory minimum behavior, monthly/annual and USD/local currency outputs, and optional salary/percentile behaviors. This is rich context that would not be visible from annotations or schema alone, and it contradicts none of the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but purposeful, packing the model, output dimensions, and parameter behavior into one structured paragraph. All content earns its place, though the formula line is technical and slightly heavy for an agent that mainly needs to understand what the tool returns.

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 and rich annotations already present, the description covers the remaining essentials: model inputs, full band list, currency and period variants, optional parameter behavior, and data caveats. Nothing needed to call the tool 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%, so the parameters are already documented. The description adds useful interpretive detail, such as salary being located on the curve to yield percentile plus 'out-earns %' and percentile returning an exact threshold wage, which enhances parameter understanding 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?

The description clearly states what the tool does: it models a country's wage distribution and returns a specific set of salary bands (survival floor, statutory minimum, p50, p75, p90, p99), so purpose is unambiguous. It does not explicitly distinguish itself from a sibling like localize_salary, though the 'benchmark' framing and band output make the distinction reasonably clear.

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 description gives a clear use boundary: results are 'model estimates for benchmarking, not payroll data,' which tells the agent where this tool is and is not appropriate. It does not name alternative tools or provide exhaustive when-to-use versus when-not-to-use guidance, so it stops short of full routing instructions.

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 mark the tool read-only and idempotent, so the description does not need to cover safety. It adds useful behavioral context: days are distinct (deduplicated), counted per calendar year, and assessed under the generic 183-day rule, the US SPT weighted formula, and the UK tax-year test; the 'early-warning, not tax advice' qualifier also sets expectations about precision.

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 tightly written sentences; the first packs the core computation and the three tests, and the second adds an important scope disclaimer. Every phrase earns its place and the most important information is front-loaded.

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 read-only calculation tool with an output schema, the description covers the computation, the three tests, the per-calendar-year scope, and the advisory nature. The main gap is the lack of differentiation from overlapping sibling tools, which matters given the long sibling list.

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 schema documents referenceDate and the country code format, leaving the stays array only structurally defined. The description supplies the missing semantics: stays represent periods of presence and are counted as distinct days per country per calendar year, which clarifies how entry/exit pairs are interpreted. It does not discuss overlap handling or date parsing, but it adds meaningful value 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?

The description opens with a concrete verb ('Count') and a specific resource ('distinct days of presence per country per calendar year'), then names the exact tax tests evaluated. It is clear what the tool computes, but it never distinguishes itself from similarly named siblings like check_tax_residency_risk or check_travel_residency.

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?

No explicit when-to-use or alternative routing is given; the closest is the 'Early-warning day counter — not tax advice' boundary, which implies use for preliminary counts rather than official determinations. Since it neither names any alternative tool nor gives clear exclusion conditions beyond the disclaimer, guidance is only implied.

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 convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: entry and exit days both count, overlapping trips are de-duplicated, and the exact output items (days used, days remaining, compliance flag, first overstay date) are spelled out. 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?

Three sentences with zero filler: purpose and rule in the first, counting nuances in the second, return-value summary in the third. The most decision-relevant information (what rule is checked) is front-loaded, and every sentence earns its place.

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 full schema parameter coverage, an output schema, and annotations covering safety/idempotency, the description only needed to explain edge-case behavior and result meaning — which it does. An agent knows what inputs to provide, what computation will be performed, and what the response will contain. Nothing material 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 each parameter (trips, plannedEntry, referenceDate) is already documented inline with formats and semantics; the description adds no parameter-level information beyond the rule mechanics that map to the trips field. Baseline 3 is correct here because the schema carries the heavy lifting.

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?

Description opens with a specific verb-resource pair ('Validate a set of trips against the Schengen Area rule') and concretely defines the rule (90 days in any rolling 180-day window). This cleanly separates it from siblings like check_residency, check_travel_residency, and find_nomad_visas, which deal with different constructs (residency status, visa discovery), so an agent can select it without opening 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?

The domain context is explicit: this is the tool for compliance-checking trip itineraries against the Schengen 90/180-day rule. It does not name alternatives or state when-not-to-use conditions, but the rule specificity makes the intended selection obvious among the residency/tax/visa siblings. Lacks the explicit exclusion language that would earn 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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that this is an estimation tool, explicitly disclaims tax advice, mentions per-country variation across 43 jurisdictions, and explains optional Schengen-warning behavior. This gives the agent a clear model of what the tool will and will not reliably provide.

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 information-dense but not bloated; it front-loads the core purpose and then details optional behavior and caveats. The list of example regimes adds credibility but is slightly more detailed than strictly necessary, keeping it from a perfect score.

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 output schema exists, the description does not need to explain return values. It covers purpose, inputs, optional behavior, jurisdictional scope, and a clear not-tax-advice disclaimer, making the tool adequately specified for correct invocation.

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%, and the schema already documents country, days, income, and arrival. The description adds useful context by tying 'arrival date' to leave-by/residency dates and income to the residency cliff, but it does not substantially extend the parameter meaning 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?

The description names specific actions — evaluating proximity to tax-residency triggers, estimating tax owed on full annual income, comparing standard vs expat/nomad regimes, and optionally computing leave-by/residency dates. This clearly differentiates it from sibling tools like check_residency or check_schengen by emphasizing tax liability and regime comparison, not just presence rules.

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 description establishes a clear use case: remote workers abroad needing an early-warning tax-residency risk assessment, including tax exposure if a threshold is crossed. It does not explicitly state when to prefer an alternative tool, but the context is specific enough that an agent can infer appropriate usage.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond those hints: it explains the Cyprus 60-day rule is flagged only when not 183+ resident elsewhere, that results include safe days left, leave-by dates, and a safe/warning/triggered rating, and that optional income enables tax-cost projection. It also hedges with 'Early-warning day math — not tax advice.' 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?

The description is dense but organized with numbered output categories, making complex information scannable. The disclaimer and supersession note are useful and short. It could be slightly more streamlined, but every sentence contributes meaningful guidance.

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 multi-result tool, the description covers the main inputs, outputs, rating semantics, jurisdiction-specific logic, and alternatives. Since an output schema exists, the description does not need to enumerate every return field. The combination of detailed prose, schema, and annotations leaves little ambiguity about what the tool does and how to invoke it.

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 67%, so the description carries meaningful weight. It enriches 'stays' by framing it as a travel itinerary, and 'income' by explaining it enables tax-cost projection for at-risk countries. It does not explicitly describe 'referenceDate', but the schema already documents it as an optional 'as of' date defaulting to today. This is strong but not exhaustive.

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 verb ('returns') and a precise resource ('from one travel itinerary'), then enumerates three specific outputs: Schengen 90/180 status, per-country tax-residency risk, and tax-cost projection. It also explicitly distinguishes itself from sibling tools by saying it supersedes check_schengen, check_residency, and check_tax_residency_risk.

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 description gives direct routing guidance: 'Supersedes check_schengen / check_residency / check_tax_residency_risk (all still available).' This tells an agent this unified tool should be preferred over those alternatives while acknowledging they remain callable. That is explicit when-to-use guidance relative to 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?

Beyond the read-only/idempotent/non-destructive annotations, the description discloses key behavioral traits: the comfortable-day definition is a stated, temperate-biased preference rather than an objective measure, the data is reanalysis rather than station observations, and country queries return a named representative city. It also explains that mean maximum temperature and rainfall travel with each row, which is important context for callers who want alternative ranking criteria.

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 not bloated; every sentence contributes substantive information. It front-loads the core purpose, then explains modes, then the comfort-day caveat and data source. It is a bit longer than strictly necessary, but the additional context about temperate bias and reanalysis data earns its place.

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 tool's complexity, the rich output schema, and the read-only annotations, the description is complete. It covers data provenance, metric definitions, mode selection, country handling, and ranking behavior. Minor edge cases like what happens if both `city` and `country` are supplied are not addressed, but they are well-covered by the schema and not essential for correct invocation.

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 input schema already covers all five parameters at 100% coverage, providing a baseline of 3. The description adds meaningful semantic context beyond the schema: the distinction between returning a single place's months versus ranking cities, the representative-city behavior for `country`, the meaning of omitting `month`, and the subjective definition of comfortable days. This pushes the score above 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 clearly identifies the tool's function: retrieving monthly climate normals and comfortable-day counts from ERA5/Open-Meteo. It distinguishes itself from sibling comparison tools by specifying the data source, metrics, and modes (city/country vs. ranked cities), so an agent understands what this tool uniquely 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 description explains when to pass `city` or `country` versus when cities will be ranked, and why a country resolves through a representative city. It also gives guidance on choosing month-level vs. annual ranking. It does not explicitly name alternative tools or state when not to use this tool, but the mode-based instructions are clear enough for most selection scenarios.

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 and idempotent behavior, but the description adds important behavioral context beyond that: data is aggregated over a 28-day window, comes from real connections rather than self-reported sources, and missing countries are absent rather than reported as zero. It also explains the call-quality verdict is derived from latency and jitter rather than bandwidth, which clarifies a potentially surprising output.

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 composed of four dense sentences, each covering a distinct useful aspect: metric definitions, data provenance, geographic coverage, and missing-data semantics. It is front-loaded with the central purpose and contains no redundant or filler 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?

For a read-only comparison tool with rich schema descriptions and an output schema, the description covers the key unknowns: what is measured, from what source, over what period, how missing data behaves, and why call quality is not simply bandwidth. An agent has all information needed to select and invoke the tool 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%, with parameter descriptions already explaining sort directions, units, and filter thresholds. The description adds broader context about the measured metrics but does not add further meaning to individual parameters beyond what the schema already provides, so the baseline score 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 clearly states the tool measures connection quality per country from Cloudflare Radar, listing specific metrics: median download/upload, latency/jitter, and a call-quality verdict. It distinguishes itself from sibling comparison tools by focusing specifically on internet connectivity rather than climate, healthcare, or cost.

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 provides clear context on when the tool is useful, noting coverage extends beyond the site's country pages and that it works for places with no dedicated page. However, it does not explicitly name sibling alternatives or state conditions when another tool would be more appropriate, so it stops short of a full usage decision rule.

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 mark it read-only and idempotent; the description adds meaningful behavior beyond that: it relies on country-specific effective-rate tax presets, supports overrides, and is expressly an estimate, not tax advice. This helps set expectations about accuracy and configurability.

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 three sentences, front-loaded with the core computation, then method and caveat. No sentence is wasted; each earns its place.

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 a rich output schema, the description covers the central calculation, overridability, country-preset behavior, and estimation caveat. Remaining details like country-specific fallbacks are present in the schema, so nothing needed for correct invocation 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?

The input schema already documents all 11 parameters with descriptions, and schema coverage is 100%, so the baseline applies. The description reinforces the role of tax presets and overrides but does not add substantial meaning beyond what each parameter description already provides.

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 exact computation (gross-to-net parity between contractor and employee hourly rates), the inputs considered (self-employment/income tax, self-paid health insurance), and the output (break-even contractor rate). This clearly distinguishes it from sibling cost/salary tools.

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 description provides clear context for when to use the tool: comparing net take-home between a self-employed contractor rate and an employee/W2/EOR rate. It does not explicitly name alternatives or exclusions, but the use case is specific enough to route an agent.

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 read-only, idempotent, non-destructive nature of the tool. The description adds useful context about US-relative price levels and both-direction salary equivalence, but does not disclose additional behavioral traits such as data freshness, coverage caveats, or limits. This is adequate given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one dense, front-loaded sentence that names the action first and then enumerates the distinct outputs. There is no filler or redundant 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?

For a simple two-parameter read-only tool with annotations and an output schema, the description is largely complete: it names the data sources and the derived metrics. The main missing piece is a brief statement about when to prefer this over sibling comparison tools, which is primarily a usage-guideline gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented as ISO alpha-2 country codes with clear constraints. The description adds little beyond confirming 'two countries' and implying a US-relative frame, but it does not clarify the role of a vs. b in the comparison.

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 action ('Side-by-side comparison of two countries') and a clear resource: cost-of-living data across named datasets. The output list ('consensus ratio, percent difference, $100k salary equivalence') makes it distinct from sibling tools like compare_climate or compare_healthcare.

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 use this tool versus alternatives such as compare_total_cost or other compare_* siblings. The recommended use is only implied by the title and description, with no explicit exclusions or routing.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral quirks: the 'ABSENT, never zero' semantic distinction, the default sorting behavior, and the warning that an unassessed country would incorrectly rank first if treated as zero. It also explains that maxRisk always filters on the composite, which prevents misinterpretation when sorting by other dimensions.

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 moderately sized but every sentence earns its place: scale, dimensions, real-world interpretation, default ordering, coverage, missing-data semantics, and integration philosophy. It front-loads the most decision-critical fact (higher is worse) and then moves to the comparison-relevant nuance. It is slightly dense, but not padded.

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 that an output schema exists and the annotations cover safety, the description is largely complete. It explains the scale, the missing-data encoding, default order, and the conceptual importance of copingCapacity. The only minor gap is that it doesn't describe the output row structure beyond the fact that the composite and three dimensions are returned, but the output schema presumably covers that.

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 baseline is 3. The description adds meaning for the composite scale and the copingCapacity dimension, but it does not elaborate on the exact format of the country parameter (ISO alpha-2 is already in the schema) or the numeric constraints. The description's additional context about sort dimensions is useful but not essential; the schema already documents each 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 opens with the exact source (INFORM Risk, EC JRC), the 0-10 composite scale with the higher-is-worse direction, and the three component dimensions. It names the specific resource and the verb 'compare', and it distinguishes itself from sibling tools like rank_livability and compare_countries by stating it is deliberately not folded into other rankings.

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 description gives concrete selection context: it is the tool for risk flags, it covers 191 countries wider than the site's country pages, and it notes the safest-first default sorting. It also states that the tool is not folded into other rankings, which implicitly tells an agent when not to use it for composite livability/cost comparisons. It does not explicitly name alternative sibling tools for the exclusion case, but the 'deliberately not folded into any other ranking here' sentence is a clear usage boundary.

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 annotations, the description discloses important behavioral details: figures are measured from World Bank/WHO and never derived from a price index, share and burden are separate facts, dental is access not price, results are national averages not individual quotes, and it is not advice. This is substantial contextual disclosure that prevents misuse.

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 with the core scope and metric list, and every sentence adds useful caveats. It could be slightly shorter without losing value, but the length is justified given the tool's interpretation pitfalls.

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, the description does not need to explain return values. It covers the country scope, metric definitions, data provenance, major interpretation caveats, dental limitation, and advice disclaimer. This is complete for an agent to call the tool correctly and interpret results appropriately.

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 input schema already documents all parameters with 100% coverage, including enum meanings and filter semantics. The description adds general context about metrics like out-of-pocket share and dental access, but it does not need to repeat parameter-level detail and does not substantially extend what the schema already provides.

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 exactly what the tool offers: healthcare cost and financial exposure across 41 countries, with a precise and rich metric list. This makes the resource and scope unmistakable and clearly separates it from broader comparison tools like compare_total_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?

The description gives clear context for when this tool is relevant: comparing healthcare spending, out-of-pocket exposure, doctor/dentist availability across countries. It does not explicitly name alternative tools or give when-not-to-use rules, but its domain-specific scope is enough for an agent to select it over non-healthcare 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?

The annotations already signal readOnly=true, idempotent=true, and non-destructive, but the description goes well beyond them. It explains what each metric means, warns that affordability percentages are country-own historical comparisons rather than cross-country rankings, discloses that mortgage rates are absent outside the euro area rather than estimated, and reveals the material up-to-40% understatement for modelled rents. This is exactly the kind of non-obvious behavioral nuance an agent needs before trusting 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?

Although the description is long, every sentence carries operational value: what is returned, how ratios relate, the crucial own-history caveat, the rentBasis reliability warning, and the data-coverage limits. It is front-loaded with the core purpose and then layers caveats in a logical order. No filler or redundancy is present.

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 tool's complexity, the optional parameters, and the existence of an output schema, the description is remarkably complete. It explains return values, units, fallback behavior, data sources, limitations, and interpretation hazards. An agent has enough context to call the tool correctly, interpret results sensibly, and avoid common misreadings without needing to inspect the output schema.

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 baseline is 3 and the schema already documents every parameter clearly. The description adds some useful semantic context by tying remoteIncome to arbitrageGap and explaining the conceptual meaning of the ratios, but it does not substantially improve on the existing parameter descriptions. It reinforces, rather than extends, what the schema provides.

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 and verb: comparing housing cost and affordability across countries for remote workers. It clearly distinguishes this from broader sibling tools like compare_total_cost or compare_countries by focusing on rent, affordability ratios, and the remote-income lens. It also specifies concrete outputs (monthly rent, two ratios, arbitrageGap), so an agent knows exactly what this tool is for.

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 description gives clear context: it is for remote workers evaluating housing affordability, and it explains when remoteIncome should be passed to get the arbitrageGap. It does not explicitly name alternatives or state 'use this instead of compare_total_cost,' but the housing-specific framing makes the intended use evident. There are no exclusions beyond the ECB/Eurostat coverage note, which is more data-availability guidance than usage routing.

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?

Even with readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral nuance: weekend holidays are excluded, regional holidays are counted separately from national ones, and five named countries return NO_DATA instead of an empty calendar to avoid conflating no data with no holidays. This is exactly the kind of non-obvious result behavior an agent needs.

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 front-loaded with the core two-mode behavior and each sentence contributes either a usage rule, an output interpretation, or a coverage caveat. It is a bit long with the London/Tokyo example, but the extra detail is substantive rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering safety, the description still covers the critical contextual gaps: conditional parameter behavior, holiday counting methodology, and geographic coverage exceptions. An agent can call this tool confidently without hidden surprises about modes or missing-data semantics.

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 adds real value by explaining the dual-mode semantics of countries and explicitly noting that sort is ignored when countries is supplied. It also clarifies how weekend and regional holidays affect the calculation, which is not evident from the schema alone.

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 opens with 'Two questions in one' and clearly defines both modes: given two or more countries it returns shared working days, otherwise it ranks countries by public holidays. This is a specific verb-plus-resource statement that distinguishes the tool from the many compare_* 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?

The description explicitly ties usage to the presence of the countries parameter: provide it for overlap, omit it for ranking. It also contrasts the tool with timezone-overlap tools, explaining the gap it fills. It does not name a sibling alternative directly, but the conditional guidance is clear and actionable.

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 annotations, the description discloses significant behavioral details: four cost lines are deliberately kept non-overlapping, rent is excluded from the everyday basket to prevent ~60% overstatement, VAT is already included and never added, and tax assumptions are spelled out (tax-resident, single filer, no deductions, IFICI handled separately). This gives an agent an accurate model of how results are computed.

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-loaded: it leads with the core result, then explains methodology and caveats in a logical order. Every section earns its place given the complexity of the calculation, though it is somewhat long for a tool with a simple required parameter.

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 tool with no output schema, the description covers the essential return concept (monthly cost and leftover), data sources, exclusions, tax assumptions, and scope limits across 41 countries. It stops short of describing the exact response shape or sorting mechanics, but the input schema covers sort behavior and the overall picture is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds context for income ('the tool is a subtraction') and clarifies what cost components the total comprises, but it does not add much detail about sort values, country format, or maxPctOfIncome 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 opens with a specific outcome: what a month actually costs in each of 41 countries on a stated income and what is left over. It then names the four cost components (rent, everyday basket excluding rent, healthcare, income tax) and the subtraction logic, making the tool's scope distinct from broader siblings like compare_countries or compare_housing.

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 description gives clear usage context: it is for comparing monthly total living costs against a stated income across 41 countries, with explicit caveats that it is an estimate and not a quote or tax advice. It does not explicitly name when to prefer an alternative sibling, but the domain and boundary conditions are clear enough for an agent to route correctly.

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 signal read-only/idempotent behavior, and the description adds meaningful transparency: the derivation formula, the distinction between tradable and non-tradable goods, the output structure (per-item prices, subtotals, monthly budget rollup), and the explicit limitation that these are estimates, not quotes.

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 dense paragraph with no filler; every sentence contributes methodology, scope, or output details. It could be slightly tighter, but it is well-structured and front-loaded with the primary purpose.

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?

Combined with the very detailed schema and presence of an output schema, the description covers the model, scope, outputs, and caveats. Minor gaps remain, such as explicitly explaining optional city sub-adjustments in the description itself, but the schema already handles those.

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% and each parameter already has a clear explanation. The tool description does not add parameter-specific meaning beyond generally referencing 'two countries' and the basket contents, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Estimates') with a concrete resource ('local prices for a 32-item everyday basket in two countries') and clearly differentiates this from siblings via the Balassa-Samuelson-style model and the 'Model estimates, not price quotes' caveat.

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 intended use case is implied clearly—estimate everyday consumer prices across two countries—but the description does not explicitly state when to choose this over alternatives like compare_total_cost or calculate_ppp, nor does it frame exclusions beyond the 'not price quotes' 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral context beyond those: 'Estimates only — not financial advice,' the statePension overlay is 'not subtracted from the FIRE numbers,' and optional savings/coast parameters change the output to include years until each country unlocks. This helps avoid misinterpretation 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 one long, dense sentence, but it is front-loaded with the core purpose and then enumerates outputs. There is no filler, though splitting into a few sentences would improve 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?

Given the output schema exists, the description thoroughly covers the key input relationship and enumerates the important output categories: tiers, FIRE numbers, nomad-visa eligibility, local currency, SWR sensitivity, savings/coast effects, and statePension caveats. The only lightly documented parameter is 'source,' but the enum values are fairly self-explanatory and the required portfolio parameter is well covered.

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%, and the schema already explains most parameters including accepted fraction/percent forms for swr and return. The description adds only aggregate mentions of portfolio/SWR and savings/coast mode, without detailing each parameter, so it neither substantially improves nor hurts parameter understanding.

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 clearly states a specific verb-plus-resource purpose: given a portfolio and SWR, return all countries where passive income supports specified FIRE lifestyle tiers. It is distinct from sibling tools by its geo-arbitrage FIRE focus, though it does not explicitly name or differentiate itself from a sibling such as find_nomad_visas.

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 description provides clear context for when to use the tool: when a user wants country-level FIRE feasibility based on a portfolio and withdrawal rate. It does not state exclusions or name alternative tools, but the FIRE-specific framing makes the intended use case fairly unambiguous.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description goes well beyond those by disclosing DST-accuracy, the fallback behavior of returning 'null with the best partial coverage', and the detailed shape of the `friction` block including the `loneWolf` concept. This gives an agent a strong behavioral model of what the tool will compute and return.

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 front-loaded with the core purpose, then moves to the return contract, then to use cases. It is somewhat detailed, especially around return values even though an output schema exists, but the structure makes it easy to scan and every sentence contributes meaningful selection 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?

For a tool with this complexity—5 parameters, 1 required, and an output schema—the description covers input scenario, algorithm behavior, return semantics, and practical use cases. The presence of an output schema reduces the burden for return-value detail, but the description is still complete enough for an agent to correctly select and invoke the 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%, so the schema itself already documents all five parameters. The description adds general context ('each participant's local working hours') but does not provide new parameter-level meaning beyond the 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 names a specific verb ('find'), a specific resource ('the longest UTC window where everyone is simultaneously within their working day'), and a second distinct deliverable ('score the team's overall timezone friction'). It clearly distinguishes this tool from the sibling tools, none of which target meeting-window discovery or timezone friction scoring.

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 description explicitly states the intended contexts: 'Useful for scheduling and for hiring/team-composition decisions.' It does not name alternatives or exclusion conditions, but no sibling tool appears to compete with this capability, so the absence of exclusions is acceptable.

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?

It discloses the computation method (base threshold plus per-dependent uplift), the deliberate inclusion of near-misses, and the output payload (duration, renewability, tax notes, official source URLs). The caveat to verify with the official source, combined with readOnlyHint and idempotentHint, gives a complete picture with no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core function, and a necessary verification caveat. There is no filler, and every sentence earns its place.

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 read-only, idempotent computation tool, the description plus fully described schema and presence of an output schema cover eligibility behavior, output fields, filters, and reliability caveats. Nothing critical for selecting or invoking the tool 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%, so the baseline is 3. The description adds 'any currency' and clarifies per-dependent/partner uplifts, but it does not materially deepen each parameter beyond the schema's already clear definitions.

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 opening phrase 'Digital-nomad visa Income Matcher' immediately names the verb and resource; 'computes each program's real income threshold' and 'returns the programs you qualify for plus the near misses' spells out behavior. This clearly distinguishes it from sibling tools like compare_climate or check_residency.

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 description implies a use case: matching income and household size to digital-nomad visa eligibility. However, it never explicitly states when to prefer this tool over related siblings such as check_residency or check_tax_residency_risk, and it provides no exclusions.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds value beyond annotations by disclosing the mathematical transformation behavior, the matrix-mode expansion when target is omitted, and the critical non-obvious return trait: 'USD purchasing-power equivalents, not currency-converted amounts.' This prevents a common misuse.

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 dense sentences, each earning its place: the core operation with formula, the batch-mode variation, and the return-semantics clarification. The most decision-relevant information (what it computes and how) is front-loaded, with zero filler words.

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 output schema exists and annotations are rich, the description need not explain return structures or safety. It covers the formula, both invocation modes, and return semantics. Minor gaps remain: no guidance on choosing among the 8 source datasets and no edge-case behavior (e.g., home == target), but these are minor for a read-only calculation 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 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by relating home and target through the ratio (I_target / I_home), giving the agent a conceptual model of how the parameters interact. The omit-target behavior is somewhat redundant with the schema's target description, but the formula is a real increment.

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 ('Convert') + resource ('base salary') + purpose ('cost-of-living-fair local equivalent'), backed by the exact formula S_local = S_base × (I_target / I_home). It differentiates itself from close siblings like calculate_ppp and calculate_wage_bands by clarifying it returns salary equivalents, not indices or bands, and explicitly notes it is not a currency conversion.

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 description gives clear context for the two modes: single-target conversion versus omitting target to 'receive a localized salary matrix across every country' with the use case 'pricing one offer across many markets.' However, it does not name sibling alternatives (e.g., calculate_ppp, calculate_wage_bands) or state when-not-to-use, so routing between related tools 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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses meaningful behavioral context: the data source (open ilyankou/passport-index-dataset, public domain), the approximate scope (~199 passports), and the access-type composition (visa-free + visa-on-arrival + eTA). The practical caveat to 'confirm entry rules with the destination authority before travel' adds responsible usage context. No contradiction with 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?

Three sentences with zero waste: the first front-loads the core function and its outputs, the second gives the optional-parameter mode, and the third covers provenance and a safety caveat. Every sentence earns its place.

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-optional-parameter, read-only tool with an output schema and safety annotations, the description covers purpose, output contents, dual-mode usage, data provenance, and a travel-safety precaution. Nothing an agent needs to invoke 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% — the 'country' parameter is already documented with alpha-2 format examples and the omit-for-league-table behavior. The description restates this same omit behavior rather than adding new parameter semantics, 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 states a specific verb ('returns') and resource (a country's passport visa-free-access data), then enumerates the exact outputs: visa-free-access score, global rank, percentile among ~199 passports, and full destination breakdown by access type. It is clearly distinguishable from all 25 siblings, none of which cover passport or visa topics.

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 description gives clear invocation context with two modes: 'for a given country's passport' and 'Omit country for the ranked league table.' It provides a conditional usage rule but does not explicitly name alternatives or state when-not-to-use; however, the tool's domain is so distinct from its siblings that the intended use case is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is covered. The description adds valuable behavioral context beyond annotations: it discloses that data is curated country-level estimates replacing a discontinued API and warns the agent to verify locally.

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 compact and front-loaded, using two sentences to convey scope, metric composition, output categories, data provenance, and a trust caveat. Every clause adds information; there is no padding or 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?

For a read-only tool with an output schema and fully documented parameters, the description is complete enough: it explains the ranking methodology, the key metrics, return categories, and the reliability caveat. An agent has sufficient context to invoke it correctly without additional clarification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds useful context by noting that budget drives lifestyle labels and visa eligibility and that weights are user-selected, but it does not need to restate parameter syntax or types.

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 clearly states a specific verb and resource: it ranks 41 countries by a weighted composite of livability metrics versus cost. It distinguishes itself from sibling comparison tools by emphasizing ranked, multi-country scoring rather than pairwise or single-aspect comparisons.

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 intended use is strongly implied: use this when you want a weighted quality-of-life vs cost ranking across many countries. However, it never explicitly names sibling alternatives like compare_countries or select_region, nor does it state when not to use this tool.

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 mark the tool as read-only and idempotent, and the description adds meaningful behavioral context: it uses per-country effective-rate presets shared with compare_contract, all of which are overridable, and it explicitly labels the result as an estimate, not tax advice. This gives the agent important caveats without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences with no filler. The main computation is front-loaded, followed by the preset/override detail and a necessary disclaimer, each earning its place.

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 calculator with an output schema, the description sufficiently covers the input domain, method, and caveats. The only minor gap is that it does not explicitly spell out currency assumptions or the fact that desiredNet is required, though the schema covers those. Overall it is complete enough for correct invocation.

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 high at 88%, so the baseline is 3, but the description adds value by explaining that the country parameter uses the same overridable presets as compare_contract, which compensates for the one parameter with no schema description. It also maps the core inputs ('taxes, self-paid health insurance, weeks off, and billable utilization') to the relevant parameters, clarifying how the rate is derived.

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 clearly identifies the tool as a calculator that takes a desired annual net income and produces freelance hourly and day rates, while naming the main input factors (taxes, health insurance, weeks off, utilization). This is a specific verb+resource combination and it reads distinctly from the sibling tools, none of which compute a required rate from net income.

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 scenario is clear: use this when you need to compute a required freelance rate from a target net income. It does not explicitly list when-not-to-use or name an alternative, but the context strongly implies the intended use case, and the mention of compare_contract provides a related point of reference.

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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond those: latency is estimated from great-circle distance via a fibre-propagation model rather than measured, and the optimal multi-region split is computed alongside the single best region. This helps set expectations about result reliability.

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 compact and front-loaded: it states the core purpose first, then the multi-region split, then the critical modeling caveat. The formula is dense but earns its place by specifying the exact optimization. No redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a read-only selection tool: it explains what it computes, how latency is estimated, and that multi-region routing is also handled. With an output schema present, return values need no elaboration, and annotations cover safety/idempotence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces that 'users' represents a user-population breakdown and explains the optimization objective, but it does not add significant new parameter-level meaning beyond what the schema provides.

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 precise verb-resource pair: 'find the cloud host region that minimizes population-weighted round-t-trip latency' and also 'compute the optimal multi-region split'. It clearly distinguishes the tool from siblings like compare_connectivity by focusing on latency minimization and region selection.

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 description gives clear context: this is for selecting cloud host regions based on a user-population breakdown. It does not explicitly name alternatives or exclusion criteria, but the 'Given a user-population breakdown' framing makes the intended use case unambiguous.

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