mcp-server

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

With annotations already declaring readOnly=false, destructive=true and openWorld=false, the description usefully adds the side-effect profile: it delivers an enquiry to Mirabello, returns a tracked booking URL, and sends a separate enquiry per call (idempotency warning). It does not explain why the operation is flagged destructive, but the added behavioral context is substantial.

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 short sentences, front-loaded with purpose then usage, with requirements and side effects following. No filler; every sentence carries actionable information for the agent.

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 19-parameter mutation tool with an output schema and annotation coverage, the description covers purpose, usage conditions, key requirements, side effects and idempotency adequately. The main remaining gap is explicit disambiguation from the sibling create_enquiry, which would help an agent choose correctly.

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

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

Schema description coverage is 100%, so the baseline is 3 regardless. The description mentions that email, programme interest/message and explicit consent are needed, which lightly highlights key inputs, but it adds no syntax, format, or selection guidance beyond the already-detailed 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 ('Request a consultation with a Mirabello Consultancy specialist') that is clearly distinct from the analytical/research siblings. It does not, however, differentiate itself from the closely named sibling create_enquiry, which an agent might reasonably confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit when-to-use condition ('Use only when the user asks to be contacted or to book') and a when-not-to-repeat rule ('do not repeat a call that succeeded'). It stops short of naming an alternative tool such as create_enquiry, so the routing guidance is good but not exhaustive.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely useful traits beyond them: the grounding in FATF/Wolfsberg standards and the 'INFORMATION ONLY — never asserts a case is compliant' disclaimer. It doesn't discuss output format, but the output schema covers that.

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

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

Single front-loaded paragraph that leads with the tool's purpose and stays dense with useful detail. It is long, but for a multi-part evidence-pack tool most sentences earn their place; only the example lists feel slightly 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?

For a complex advisory tool with an output schema, the description covers purpose, scope, grounding, and the informational disclaimer well. The main gap is the origin/context parameter mismatch with the schema, which leaves the agent's input semantics ambiguous.

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%, but the description actively misdescribes both parameters: it frames 'origin' as a wealth-origin type (business_sale, inheritance, ipo_liquidity_event) while the schema defines it as 'Country the applicant is relocating FROM', and it describes 'context' as a destination/programme while the schema calls it free-text background. This conflicting framing risks the agent passing the wrong kind of value.

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 (build a Source-of-Wealth/Source-of-Funds evidence pack) and enumerates exactly what it returns — core + corroborating documents, context overlay, and red flags. It is clearly distinguishable from generic checklist siblings like get_document_checklist and compliance_checklist.

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 clear context ('given a wealth-origin type and an optional destination context') and an invocation hint ('call with no args to list available origins and contexts'). However, it never names an alternative sibling or an explicit when-not-to-use condition.

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, so safety is covered. The description adds genuinely non-obvious behavioral context: results are limited to factual published policies and final acceptance rests with government due diligence, telling the agent the output is advisory and potentially stale. It does not cover freshness/rate-limit behavior, which keeps it from 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?

Two sentences, front-loaded with the screening scope and followed by the disclaimer. The second sentence earns its place as an epistemic caveat rather than filler. Minor density in the colon-list, but no wasted prose.

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

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

With an output schema present, return values need no explanation, and annotations carry the safety profile. The description supplies what structured fields cannot: the policy domains screened and the advisory nature of the result. An agent has enough to invoke it correctly without opening another 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% and the CBI/RBI enum is self-explanatory, so baseline is 3. The description reinforces that nationality drives the screening, but adds nothing about the optional type filter or about what programme_id detail mode returns versus the default list mode.

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 and resource (check which programmes a nationality can apply to) and enumerates the screening dimensions: nationality restrictions/suspensions, EU-citizen applicability, minimum age, core requirements. It is clearly distinct from cost/timeline/compare siblings, but it never addresses the near-identical sibling check_maltese_citizenship_eligibility, which an agent could easily confuse with it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: this is a pre-application screening step over published policy. There is no explicit when-to-use vs. find_pathways, recommend_programmes, or check_maltese_citizenship_eligibility, and no statement of prerequisites beyond the required nationality input. The 'factual published policies only' caveat hints at scope but does not route the 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, non-destructive safety profile, but the description adds rich behavioral context: it enumerates the returned outcome values, mentions reasons, form, next steps and sources, and discloses key decision rules (1 August 1989 rule, father-only rule, 5-year marriage rule). It also states the decision authority, going 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?

The description is long but front-loads the core purpose and routes before returns and disclaimers. Every sentence carries substantive information, though the heavy parenthetical style makes it slightly dense and less scannable than it could be.

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 10-parameter screening tool with an output schema and annotations, the description covers purpose, route-specific rules, output outcomes, and legal caveats. An agent has everything needed to select and invoke it correctly; return values are additionally summarized but the output schema already handles that burden.

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 still adds legal-rule context that maps to parameters (e.g., how marriage_date drives the 5-year rule, how parent_citizenship_basis interacts with the father-only and registration rules), giving the agent more semantic grounding than 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?

States a specific verb (screen) and resource (Maltese citizenship eligibility) and immediately scopes it to two family routes (birth, marriage). The level of detail distinguishes it from generic siblings like check_eligibility or matrimonial_regime_screen without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly frames the tool as a 'rules-based first screen' and explicitly warns it is 'not a legal determination', which sets expectations for when to use it. However, it does not name any alternative sibling or state when not to use it (e.g., for non-Maltese citizenship checks).

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, openWorldHint=false, and destructiveHint=false, so safety is well covered. The description adds only that the result includes a count and access to a few named destinations, which is thin given an output schema exists that already defines the return shape.

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

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

A single, front-loaded sentence with no filler. It is efficient, though the phrasing 'Mobility for a programme passport' is slightly compressed and could more directly lead with the action and its result.

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 read-only lookup, most needs are covered: annotations give the safety profile, the output schema explains the return values, and the schema fully documents parameters. The missing piece is sibling disambiguation, but the core operational information is present.

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

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

Schema description coverage is 100%, so both parameters (including the programme_id-is-not-a-country-name warning and the destination examples) are already documented in the schema. The description's mention of Schengen/UK/USA/China merely echoes the destination examples, adding no new meaning. 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 clearly identifies the resource and the payload: visa-free count plus access to key destinations for a given programme passport. It is understandable on its own, but it never distinguishes this tool from close siblings like check_visa_requirement, list_visa_free_destinations, or get_mobility_optionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance. With several overlapping siblings (check_visa_requirement, list_visa_free_destinations, get_mobility_optionality), the absence of routing guidance forces the agent to guess which mobility tool to call.

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 (readOnly, non-destructive, closed-world), so the description earns credit for adding provenance and caveats the annotations cannot convey: the Passport Index dataset as source, corroboration and IATA verification links returned with the answer, and that entry rules change without notice with the destination authority final. It does not mention caching, rate limits, or how stale the data can be.

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 first sentence front-loads the core concept and enumerates outcomes compactly; the second sentence carries data coverage and provenance; the third is a short disclaimer. It is slightly dense with parenthetical asides, but every clause serves a purpose and there is no padding.

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

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

For a two-parameter lookup with a full output schema, the description supplies what the schema cannot: outcome taxonomy, dataset breadth, provenance, and a legal-accuracy caveat. It even notes the corroboration and IATA links returned, so the agent knows extra verification data comes back. The only gap is alternative-tool routing, which is marginal for such a simple point lookup.

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 both parameters well, including the tricky 'Schengen (checked via Germany)' case. The description adds only the one-per-call scoping ('ONE nationality', 'ONE destination') and no additional format or syntax meaning, 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?

States a specific verb+resource with exact scope: 'VISA REQUIREMENT for ONE nationality travelling to ONE destination', then enumerates every outcome class it can return (visa-free, visa on arrival, e-visa, ETA, visa required, no admission). This implicitly separates it from siblings like check_visa_free (visa-free only) and list_visa_free_destinations (many destinations for one passport), so an agent can route without opening any 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?

The 'ONE nationality / ONE destination' framing and the '199 passports x 199 destinations' coverage tell the agent clearly when this lookup is the right call, and the disclaimer sets expectations about authority. However, it never names an alternative or an exclusion (e.g. when to prefer get_entry_requirements or check_visa_free), leaving that routing 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?

Far exceeds the annotations' safety profile: it discloses hard timing rules (2016/1103 and Rome III require nationality at agreement time), a voiding condition (Swiss professio juris void if Swiss nationality later acquired), situs overrides, the fixed-share vs discretionary-claim trade-off, the no-useful-election outcome, the declaration requirement, and an explicit information-only disclaimer. No contradiction with readOnlyHint/destructiveHint/openWorldHint.

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?

Purpose and inputs are front-loaded in the opening clauses, and the later clauses carry genuine behavioral detail (timing, voiding, trade-offs, disclaimer). The single dense sentence-chain is information-rich but heavy to parse; a small amount of structural separation would improve scanning.

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, return-value explanation is unnecessary, and the description covers the domain scope, timing rules, failure mode, and legal caveats. For a zero-required-parameter analytical tool with 5 well-documented inputs, nothing essential is missing beyond sibling routing.

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 is documented in the schema, so the baseline is 3. The description adds one constraint ('Pass ISO alpha-2 codes only, never personal data'), but that conflicts with the schema's own note that spouse_nationalities is 'as country names' with example ['Brazil'], leaving format ambiguity the description does not resolve.

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 analytical task (determine which law governs cross-border succession, matrimonial property and divorce) with named legal instruments and the exact inputs it consumes and outputs it produces. An agent can distinguish it from siblings like succession_conflict_map or matrimonial_regime_screen from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the stated inputs (nationalities, residence, situs, marital status) and the note that it returns 'no-useful-election' when nationality opens nothing. However, it never says when to prefer this over the adjacent siblings (succession_conflict_map, forced_heirship_risk, matrimonial_regime_screen), so routing remains inferential.

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, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds the advisory framing ('comparative facts only — information, not advice'), which is useful expectation-setting, but discloses nothing about limits, key resolution failures, or partial-match behavior.

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 what is compared, then the input format, then the disclaimer — a logical order. The dimension list is long but each entry carries distinct selection value; no filler 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?

An output schema exists, so return values need no description, and the description covers input shape, cardinality bounds, comparable dimensions, and the advisory caveat. What is missing is guidance on where valid profile keys come from (e.g. find_formation_jurisdictions), a genuine gap for a key-array input.

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 there is a single required parameter, so the baseline would be 3. The description earns an extra point by supplying concrete example keys ("us-llc-wy", "ae-freezone", "ee-ou") that convey the key naming convention, which the schema does not.

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 (side-by-side comparison), resource (formation structures), and bounded scope (2-6), then enumerates the exact dimensions compared (tax position, costs, timeline, substance, banking tier, EU/FATF, ideal client). This clearly distinguishes it from siblings like compare_programmes and compare_treaty_position.

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 explains how to invoke the tool (pass an array of profile keys, with an example), but never states when to reach for this over compare_programmes or compare_scenarios, nor any prerequisite for obtaining valid profile keys. Usage is implied rather than specified.

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, so the safety profile is covered. The description goes beyond them by disclosing the returned artefacts (rank, composite, dimension scores, per-dimension deltas, per-metric leads, compare page URL) and qualifying the URL with 'where one exists', which signals the field can be absent.

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 purpose, and the alternative mode is presented as an explicit 'Or'. The comma-separated output lists are somewhat dense but each item earns its place by describing a distinct result field.

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 not be fully re-explained, and the safety annotations cover the rest. Both invocation modes and their differing artefacts are described, leaving only minor gaps such as which mode takes precedence if both are supplied.

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 would be 3, but the description adds genuine semantics: it maps the parameter choice to the type of result (a+b yields the versioned artefact; ids yields the classic column set). It does not explain the a-vs-b ordering or ID format, but the mode-mapping is real 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?

States a specific verb+resource ('Compare programmes side by side') and then distinguishes two distinct operating modes: the pair (a+b) canonical versioned artefact versus the ids multi-column classic comparison. An agent can tell exactly what output shape each invocation produces.

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 conditional guidance: 'Pass a + b ... for the canonical versioned comparison artefact' and 'Or pass ids (2-4) for the classic multi-column comparison'. It does not, however, differentiate itself from siblings with similar names (compare_formation, compare_scenarios, compare_treaty_position), leaving the agent to infer that this tool is the programme-specific one.

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

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint false). The description adds real behavioral context beyond them: the 2-8 jurisdiction bound, the 'informational only, not advice' caveat, and the recommendation to pair with other tools.

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 core action and scope, then the synthesis positioning, then input formats and disclaimers. The dimension enumeration is long but each item earns its place by defining comparison coverage.

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, return values needn't be explained, and annotations cover safety. The description fully supplies scope, input formats, limits, the informational disclaimer, and complementary tools, leaving nothing an agent needs 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 schema already documents both cc and scenarios. The description adds the accepted input shape ('array of {cc,pathway} or cc as a comma list'), which slightly extends the schema's single-string cc, but otherwise largely restates what is structured.

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 (compare) and resource (2-8 jurisdictions/scenarios) and enumerates the exact dimensions covered. The phrase 'synthesis view over the tax, residence, structure, reporting and succession layers' cleanly distinguishes it from single-layer siblings like compare_programmes, compare_formation and compare_treaty_position.

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?

Positions the tool as the multi-layer synthesis over the other compare tools and advises combining with 'the immigration route and a specific double-tax-treaty corridor for the full picture'. That is clear contextual guidance, but it never states an explicit when-not or names a competing sibling to route away from.

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/destructive/openWorld, so the bar is lower; the description still adds real value by scoping the analytical dimensions returned and flagging that results are indicative rather than advice. This exceeds mere restatement of the annotation set.

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?

Dense but front-loaded: the corridor purpose leads, the computed dimensions follow, and the format/caveat notes close. Every clause carries information, though the parenthetical (from→to) becomes ambiguous once the parameter conflict is considered.

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 not be explained, and the description sketches the analytical scope adequately for a fairly complex treaty tool. However, the unresolved conflict over what from/to represent leaves the agent without reliable invocation knowledge.

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%, which would normally give a baseline of 3, but the description's instruction 'Use ISO alpha-2 codes' directly conflicts with the schema, which defines from/to as ISO dates ('Start of the date range', example 2026-01-01). Rather than clarifying parameters, it misleads the agent about whether to pass country codes or dates.

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 analytical output and enumerates its components (DTA in force, residence tie-breaker, dividend/interest/royalty withholding rates, LOB/principal-purpose test), so an agent knows exactly what 'compare' produces. It is clear but does not explicitly differentiate itself from the nearby withholding_map sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no statement of prerequisites, and no routing to alternatives such as withholding_map or check_eligibility, which overlap on tax-treaty content. 'Indicative, not advice' is a disclaimer, not usage direction.

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, so safety is covered. The description adds real operational context beyond that: STATELESS execution, a hard constraint against passing personal data, and an 'informational only / not exhaustive' scope limit. It stops short of describing return behavior, but an output schema exists.

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?

Purpose is front-loaded, followed by the flag list and caveats in a logical order with no filler sentences. The flag enumeration is somewhat redundant with the 100%-documented schema, which is the only minor inefficiency.

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, return values need no explanation, and the description covers purpose, inputs, statelessness and scope disclaimers. The one gap is when to prefer this over neighboring checklist/eligibility tools.

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 flag has a precise boolean definition in the schema, so the baseline is 3. The description names 8 of the 10 flags but adds no semantics beyond the schema and omits rbi_applicant and eu_cross_border_arrangement.

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 ('Lists') and resource ('reporting/compliance obligations a stated profile may trigger') and enumerates the exact regimes covered (FATCA, CRS, CARF/DAC8, DAC6, PEP EDD, etc.). An agent can distinguish this from siblings like get_document_checklist or residence_evidence_checklist 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?

The description implies usage by describing the input profile (boolean flags) and adding a disclaimer, but it never names an alternative tool or states when-not to use it. With many adjacent siblings (check_eligibility, get_document_checklist, residence_evidence_checklist), the lack of routing guidance leaves the agent to infer selection.

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 this is a non-read-only, destructive write, and the description adds real context beyond them: the side effect of delivering the enquiry to Mirabello, the returned next step, the GDPR consent gate, and the no-duplicate-call warning. It does not explain how an enquiry could later be retracted, so a full 5 is unwarranted.

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 purpose and side effect, then preconditions, then the repeat-call rule. Dense but every sentence carries a constraint; borderline between tight and slightly overloaded.

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 mutation with an output schema, the description covers the essentials: recipient, consent gate, side effect, CBI/RBI constraints, and idempotency guidance. Minor gaps remain around what qualifies an enquiry as 'qualified' and how nationality drives eligibility, but the core invocation path is complete.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters, and the baseline is 3. The description reinforces the key required fields (property_id slug format, email, consent:true) but adds no syntax or semantics 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 and resource — routing a buyer enquiry about a specific property to Mirabello — and grounds property_id in search_properties/get_property. It clearly differentiates this write/routing action from the read-oriented property siblings, though it does not name a specific alternative tool for related actions.

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 preconditions (property_id slug, valid email, explicit consent:true for GDPR) and an important operational rule ('do not repeat a call that succeeded'). It also scopes CBI/RBI purchases to approved projects and authorised agents, but stops short of explicitly stating when to prefer book_consultation or other siblings instead.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds real behavioral context: it is deterministic, derived from an official fee table with sources, flags unverified mission/courier figures, and is information-only.

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 core purpose in the first clause, followed by the fee components and then two short qualifier sentences. Dense but each clause carries fee-structure information; the single long sentence is slightly heavy 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description enumerates every fee component and its conditions, leaving only minor gaps such as how missing optional inputs (month, location) are handled by default.

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 goes beyond the schema by attaching concrete fee semantics to the parameters (seasonal €70/€80 adult rates, €160 urgent service with 4-hour window, €15 lost-but-valid supplement), which enriches parameter interpretation.

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

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

States a specific verb+resource: an itemised government fee estimate for a Maltese passport, with the authority (Identità) named. It is easy to distinguish from get_passport_renewal or estimate_total_cost by scope, but it never explicitly routes against those sibling estimators.

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 what the estimate contains but gives no when-to-use guidance or alternatives. The only directive, 'confirm with the Passport Office or mission before paying,' is a reliability caveat rather than a rule for choosing this tool over estimate_total_cost or get_passport_renewal.

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 safety is covered. The description adds the useful detail that output is 'published processing time plus the stage breakdown where available,' disclosing both content and a coverage limitation, but says nothing about data freshness, rate limits, or behavior when stages are missing.

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

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

A single efficient sentence with no filler, and the core deliverable is front-loaded. It is short to the point of possibly under-specifying, but nothing is wasted.

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

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

An output schema exists, so return-value explanation is not required, and the description adequately conveys what the tool produces. Given the low complexity (one required param, read-only), it is nearly complete; only the missing sibling routing keeps it from a 5.

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 single programme_id parameter is fully documented in the schema (including the 'not a country name' warning). The description adds no parameter-level information beyond that, so the 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 specific verb ('estimate') and resource ('timeline for a programme') and clarifies the scope as published processing time plus stage breakdown. However, it never differentiates itself from the sibling get_processing_times, which an agent could easily confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusions, and no named alternative. The phrase 'where available' hints at a coverage caveat but doesn't tell the agent when to prefer this tool over get_processing_times or estimate_total_cost.

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, non-destructive, closed-world read. The description adds genuinely useful disclosure beyond that: the result is indicative only and excludes professional, property, and legal fees, which tells the agent the number is not a full quote.

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

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

A single front-loaded sentence that leads with the verb and resource, then layers the inclusions and the exclusion caveat. No wasted 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?

With an output schema present, return values need not be explained, and the annotations carry the safety profile. The description covers scope and the indicativeness caveat, leaving only sibling disambiguation unaddressed.

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 programme_id, adults, children_16plus, and children_under16 are already documented with defaults and examples. The description only implies family composition via 'for a given family' and adds no syntax or unit detail 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?

Names a specific verb (estimate) and resource (total cost of a programme) and enumerates the cost components included: investment, government & due-diligence fees, family add-ons. It does not, however, differentiate itself from the sibling estimate_malta_passport_fee, which an agent would need to disambiguate between.

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 statement of when to use this tool versus list_programmes, compare_programmes, or estimate_malta_passport_fee. The only framing is a caveat about what the figure excludes, which is accuracy guidance rather than usage 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the characteristics the search surfaces (donor tax relief, entity tax status, cross-border granting, standout vehicle), which is useful, but discloses no pagination, ranking, or result-shaping behavior beyond that.

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

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

Purpose is front-loaded in the first clause, with the vehicle enumeration and positioning following. It is a single dense sentence plus a positioning clause, slightly burdened by the long example list but with no genuinely wasted 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?

With an output schema present, the description need not explain return values, and it correctly focuses on scope, vehicle coverage, and domain positioning. For a low-complexity read-only tool with two optional parameters, this is nearly complete; only explicit sibling routing 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 both parameters are already documented (including the 'vehicle' examples and the donor_relief filter meaning) in the schema. The description echoes the same vehicle examples without adding format or semantics beyond what the schema provides, making the 3 baseline 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 pairs a specific verb ('Find') with a tightly scoped resource ('jurisdictions for setting up a CHARITABLE/PHILANTHROPIC structure') and enumerates the vehicle types it searches over. By framing itself as 'the philanthropy/legacy complement to the residence/citizenship + tax + trust layers,' it distinguishes itself from siblings like find_trust_jurisdictions and find_formation_jurisdictions without the agent 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?

The positioning sentence ('complement to the residence/citizenship + tax + trust layers') implies the domain in which this tool is relevant, but there is no explicit when-to-use/when-not guidance or named alternative to route to. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds substantial context beyond that: periods are qualifying residence excluding processing time, coverage is narrow by design with absence meaning 'unverified, never that no fast track exists', and entries are verified against enacted statutes. These are meaningful behavioral and provenance disclosures.

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 core purpose, then parameter behavior, then coverage caveats. Dense and largely waste-free, though the parenthetical legal citations make the sentence long; still, each clause carries informational value.

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

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

For a zero-required-param, three-parameter read tool with an output schema present, the description covers everything an agent needs: what each parameter produces, the meaning of the returned periods, and the coverage caveat. Return-value explanation is rightly left to 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 coverage is 100%, so the baseline is 3. The description nonetheless adds real meaning: it explains the distinct behavior of each parameter (nationality ranks, cc returns one jurisdiction in full including who gets no reduction, bloc ranks a bloc with presence and requirements plus uncovered members). This goes beyond the schema's format hints.

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 (rank jurisdictions by how soon a given nationality may apply for citizenship) and scopes it with concrete examples (Ibero-American → 2 years in Spain, CPLP → 7 in Portugal, Samoan → immediate in NZ). It is clearly distinguishable from siblings like find_pathways and check_eligibility, which concern eligibility rather than nationality-based fast-track ranking.

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 parameter-selection guidance: pass nationality to rank, pass cc for one jurisdiction in full including baselines and transitional regimes, pass bloc for a bloc ranking. It also clarifies the coverage policy (absence means unverified). It stops short of naming sibling alternatives or when-not-to-use conditions, so not a full 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 declare readOnlyHint=true and openWorldHint=false, covering the safety profile, so the bar is lower. The description adds useful non-schema context: results are 'honest' summary profiles with the full profile 'on request', and an explicit 'Information, not advice' disclaimer, plus the 'Rule zero' PoEM/CFC caveat.

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 action is front-loaded ('FILTER...'), and the output enumeration stays tight. The trailing 'Rule zero' and advice-disclaimer sentences are somewhat tangential but short and add domain value, so nothing is egregiously wasteful.

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 details are not strictly required, yet the description still outlines the match fields. With annotations, full schema coverage, and an output schema present, the definition is complete enough, though it lacks explicit sibling routing.

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 baseline is 3, but the description adds meaning beyond the schema: banking_tier is explicitly a 'minimum', and eu_clean is spelled out as 'exclude EU Annex I/II and FATF-listed'. It also ties each parameter name to its effect in the filter.

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 (FILTER) plus resource (Mirabello formation profiles for company/structure jurisdictions) and enumerates what a match returns. An agent can distinguish it from find_trust_jurisdictions, find_low_tax, and compare_formation 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?

The filter semantics (remote_only, eu_clean, banking_tier, lane) imply when the tool is useful, but there is no explicit when-to-use/when-not guidance and no named alternatives despite overlap with siblings like find_trust_jurisdictions and find_low_tax. Usage must be inferred.

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 (readOnly, non-destructive, non-openWorld), so the bar is lower. The description adds meaningful detail beyond that by specifying what is returned (HNWI tax + CRS + EU-list (+ crypto) snapshot) and clarifying non-CRS semantics in prose.

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 criteria enumeration followed by the return shape and the combination hint. Efficient overall, though the long parenthetical clauses make the first sentence dense.

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, return-format explanation is not strictly required, and all 8 params are documented in the schema. The description covers purpose, filters, and a next-step combination, leaving little an agent would need in order to invoke it correctly.

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

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

Schema description coverage is 100% and every parameter is individually documented with its own clarifying text (including a compliance note on non_crs), so the schema does the heavy lifting. The description's criteria list essentially restates the same filters, adding framing rather than new syntax or edge-case meaning — baseline 3.

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

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

States a specific verb (Find) and resource (countries) plus the exact filter dimensions, and the criterion list differentiates it from single-country tools like get_country_tax and from sibling finders such as find_formation_jurisdictions or find_charity_jurisdictions. An agent can tell what domain this covers 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?

The closing line gives clear forward guidance — 'Combine with a residence or citizenship route for a full tax-plus-pathway view' — which tells the agent how this fits into a workflow. It stops short of naming an explicit alternative tool or a when-not condition, so it is clear context without 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 cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds meaningful behavioral context beyond that: results are 'screened' countries, each returned with key requirements, income thresholds, cost and path to PR, which tells the agent what a successful call yields and that the dataset is curated.

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, front-loaded with the primary action and scope, and the EU/EEA caveat placed last where it belongs. Some waste in restating enum values that the schema already carries, but the density is otherwise high.

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 needn't enumerate return fields, yet it summarizes the shape usefully and resolves the one genuinely ambiguous enum value. It omits any mention of the region filter or how screening is performed, leaving a small gap for a two-parameter discovery 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% and the schema already enumerates all pathway ids plus a description of eu-free-movement, so the description's example list (digital-nomad, skilled-work, ancestry-descent, retirement-passive) largely duplicates structured data. The region parameter is never addressed, and no format or matching semantics are added beyond what the schema 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?

States a specific verb and resource ('Find which countries offer a given immigration pathway') and immediately constrains the domain by listing the pathway types it operates on. An agent can distinguish it from siblings such as find_retirement_routes (route discovery) or check_eligibility (per-user assessment) 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?

Provides a concrete routing rule: EU/EEA/Swiss citizens moving within the EU/EEA or Switzerland should use eu-free-movement rather than a visa pathway. It does not, however, say when to use this tool instead of close siblings like find_retirement_routes or check_eligibility, so the guidance is clear but incomplete.

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?

With readOnlyHint and destructiveHint=false already covering safety, the description adds substantial behavioral context: what each route returns (official requirement in legal currency, stay rule, tax label, Golden score with reasons, permanent-residence path, source), the key caveat that unverified figures are withheld rather than estimated, and the FX-based indicative qualification. It also names the specific jurisdictions that tax foreign pensions, which an agent cannot infer from schema or 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 purpose and scope are front-loaded in the first sentence, followed by filter summary and then return/behavior detail. It is dense and long, but nearly every clause carries decision-relevant information; only the long parenthetical listing of return fields edges toward over-stuffing.

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 9-parameter, all-optional, read-only discovery tool with an output schema, the description is complete: it explains the filters' intent, the meaning of Golden/min_score, the data-quality policy, and the returned fields. An agent has everything needed to invoke it correctly and interpret results, and the safety profile is fully covered by annotations.

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 already 100%, setting a baseline of 3, but the description goes further: it defines the 'Golden' rating criterion (score 70+/100, no investment, low foreign-income tax, little presence/renewal) that the schema merely references, and clarifies behavioral nuances like routes with unstated stay rules being kept and flagged, and dependant income add-ons raising requirements.

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 gives a specific verb and resource ('Find RETIREMENT and PASSIVE-INCOME residence routes') and enumerates the real-world programs (pensionado, rentista, retiree visas). It cleanly scopes itself away from investment-based routes ('qualify on income or savings, not an investment'), which implicitly distinguishes it from the many citizenship/programme siblings, though it never names a specific sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is strongly implied by the scope and the enumerated filters, making it obvious this is for income/savings-based retirement residence. However, it never states when NOT to use it or points to an alternative (e.g. recommend_programmes or find_pathways) for users who can invest or want citizenship, so routing advice 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 the safety profile (readOnly, non-destructive, closed-world), so the description earns credit for going beyond them: it discloses the ranking by asset-protection strength and the per-result fields (statute, CRS status, EU-list status). It does not discuss result volume or pagination, which keeps it short of 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?

Three tight sentences, front-loaded with the purpose, then the filters, then the positioning. The parenthetical jurisdiction examples are the only slightly expendable element, but they aid agent matching rather than padding.

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

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

Only two optional params, 100% schema coverage, an output schema for return shape, and annotations covering safety. The description supplies the domain framing, ranking rationale, and result contents needed to select and call it correctly – 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% and both parameters (vehicle, strong_protection) are already documented in the schema. The description's 'Filter by vehicle (trust/foundation) or strong_protection' merely restates that, adding no syntax, defaults, or interaction 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?

States a specific verb (find) and resource (trust & foundation jurisdictions), names the domain use case (asset protection, succession planning), gives concrete examples, and describes the ranking criterion. It is clearly distinguishable from siblings like find_charity_jurisdictions, find_formation_jurisdictions, and find_low_tax.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says how to narrow results ('Filter by vehicle (trust/foundation) or strong_protection') and positions the tool against a family of alternatives ('the wealth-structuring complement to the residence/citizenship pathways'). It stops short of stating when NOT to use it or naming the sibling to prefer in a borderline case, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, covering the safety profile. The description adds a meaningful caveat — 'Indicative, not advice' — warning the agent not to present output as professional advice, which is valuable behavioral context beyond 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 a single front-loaded paragraph that lists scope efficiently, then adds two short sentences for usage context and disclaimer. The only slight waste is 'Use ISO alpha-2', which duplicates the 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?

With an output schema present, return values need no explanation. The description covers scope, disclaimer, and parameter format; the only minor gap is that it doesn't state whether coverage is global or limited, but this is not critical for a one-parameter read-only flag 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% and the cc parameter is fully documented in the schema with examples. The description's 'Use ISO alpha-2' is redundant with the schema, adding no new semantic detail, 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 ('flag') and resource (anti-avoidance & relocation-tax risks for a jurisdiction) and enumerates the covered flags (CFC, GAAR, POEM, economic substance, exit-tax, step-up-in-basis). The clause 'The depth behind headline rates' distinguishes it from the sibling get_country_tax, so an agent can tell them apart 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?

The phrase 'The depth behind headline rates' implies when to use it (when headline rates are insufficient), but no alternative tool is named and no explicit when-not-to-use guidance is given. Usage context is inferable but not spelled out.

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, openWorldHint=false, destructiveHint=false, so safety is covered structurally. The description adds genuine context beyond that: the result is a static statement of default legal rules rather than a case-specific outcome, which is the key behavioral caveat for interpreting the response.

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?

Scope and the crucial default-rules caveat are front-loaded, and the parenthetical jurisdiction examples (France, Germany, Switzerland) are illustrative rather than filler. The single sentence is dense but every clause carries meaning; only the long enumeration risks mild bloat.

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 tool takes one parameter and has an output schema, so return-shape explanation is unnecessary. The description fully covers scope, the legal sub-topics returned, and the important limitation that these are default rules — nothing an agent needs to invoke or interpret it 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 a single parameter at 100% schema description coverage, the schema already fully documents 'cc'. The description's 'Use ISO alpha-2' restates the schema's ISO 3166-1 alpha-2 guidance without adding format, normalization, or failure behavior. 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 specific resource (forced-heirship / testamentary-freedom position for a jurisdiction) and enumerates the exact sub-facts returned: reserved shares, freely-disposable portion, disinheritance of spouse/children, and trust/foundation interaction. This clearly separates it from adjacent siblings such as succession_conflict_map and matrimonial_regime_screen.

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 bounds the tool's scope: 'States the default legal rules — NOT how any estate will devolve,' which tells the agent when this is and isn't the right call. It does not, however, name an alternative tool for the excluded case (e.g. a fact-specific succession analysis), so routing is only half-complete.

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 set destructiveHint=true and readOnlyHint=false, and the description adds real behavioral value beyond them: it discloses that every call creates a new briefing link, that the URL is valid 90 days, and that repeating the call with email + consent fires another follow-up request (duplicate side effects). It does not explain what the 'destructive' annotation refers to, which keeps it short of 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-loads the core action and outputs in the first sentence, then uses a second for the optional follow-up and a third for repetition semantics. Dense but efficient; the parenthetical asides are justified rather than filler, though the third sentence is packed.

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, return values need not be spelled out, yet the description still names the key outputs. For a 14-parameter, 0-required tool with full schema coverage and annotations, the main missing piece is guidance on tool selection versus sibling recommenders, everything else an agent needs to call it correctly is present.

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 still adds relational meaning the schema does not: it groups nationality/budget/family/goals as the client profile and explicitly ties 'email + consent' together as the follow-up registration trigger, clarifying the GDPR coupling beyond the per-field 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 verb and resource ('Generate a personalised Mirabello briefing') and immediately enumerates the distinctive outputs: a ranked shortlist with family cost math plus a shareable branded briefing page URL. This is clearly separable from sibling list/compare tools like recommend_programmes or compare_programmes.

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 frames the input context ('given a client profile') and notes the optional follow-up registration path, so usage is implied. However, it never names an alternative tool or states when NOT to use this one (e.g. versus recommend_programmes or compare_programmes), leaving the agent to infer 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, destructiveHint=false, and openWorldHint=false, so safety and scope are covered structurally; an output schema also exists. The description's content inventory is mildly useful orientation but adds no behavioral detail beyond the structured fields — no note on whether this is static marketing copy versus live data, nor freshness/caching behavior.

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, zero filler: the first front-loads the content inventory, the second front-loads the usage trigger. Nothing is repeated from the title or schema, and no sentence is disposable.

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?

A parameterless, read-only profile tool with an output schema needs only to say what content it yields and when to reach for it — both are present. Return-value detail is legitimately delegated to the output schema, so 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a parameterless profile fetch by describing only content, with no confusing hints about optional filters that do not exist.

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

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

Names a specific resource (Mirabello Consultancy) and enumerates exactly what it returns: track record (cases, approval rate), credentials (IMC, ACAMS), offices, languages, services. This clearly separates it from the topical siblings (get_programme, get_country, estimate_total_cost), though the verb is implicit in the trade name rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the triggering queries: '"who is Mirabello / why use them / are they reputable" questions' — an agent can recognize the intent immediately. It stops short of naming alternatives or exclusions (e.g., 'use get_provenance for source data about specific facts'), so it is clear context without 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by defining what an "update" is (re-verification of price/availability/sale status), but says nothing about volume, pagination, or ordering of the returned updates.

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 short sentences, front-loaded with what the tool returns before the optional filter and audience note. The closing audience clause is slightly soft but earns its place as usage context.

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 not be described, and the single parameter is fully covered by the schema. However, the tool lives among several change/property siblings and the description does not resolve that overlap, leaving a real routing gap for an agent.

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 single `since` parameter is already documented with an ISO example, so the baseline is 3. The description's "optionally since an ISO date" adds only the optionality framing, no new syntax or semantics 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 verb-adjacent resource ("Recently re-verified listings") and enumerates the changed fields (price / availability / sale status), so an agent knows exactly what it returns. It does not distinguish itself from close siblings like get_recent_changes or subscribe_changes, which is the only gap.

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?

"For agents keeping an inventory view fresh" implies a polling/refresh use case, and "optionally since an ISO date" hints at incremental sync. However, there is no explicit when-not guidance and no named alternative (e.g. subscribe_changes for push, get_recent_changes for the other change surface), leaving the agent to infer 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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description usefully adds that output is 'Information, not advice' and that 'no account is ever guaranteed', setting expectations about the tool's limits and non-actionable nature. It does not cover rate limits or output format, but with annotations carrying the safety profile this is clear added 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?

Front-loaded with the core resource and scope, but the long parenthetical enumerations and 'Honest doctrine' framing add bulk. Most content is informative, yet it could be tightened without losing the key routing and usage facts.

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 not be explained. Still, for a tool with a near-duplicate sibling (get_nonresident_banking), the description omits any differentiation, leaving an agent uncertain when to choose this one. Otherwise coverage of content and caveats is adequate.

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 schema already documents cc and type. The description still adds value beyond the schema: it specifies 'omit cc for the coverage list' and clarifies type is passed 'to focus', details absent from the schema descriptions.

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 the specific resource (non-resident banking-access landscape per jurisdiction) and scope (corporate/personal lanes, timelines, rejection causes, CBI synergy), making the tool's function clear. However, it does not distinguish itself from sibling get_nonresident_banking, which appears to cover similar ground, so it falls short of full sibling differentiation.

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?

Provides calling instructions ('Pass cc... omit cc for coverage list') and notes 'Information, not advice', but offers no explicit when-to-use vs alternatives and never names the sibling get_nonresident_banking. Usage is implied rather than guided, matching a 3.

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 (a closed dataset), so the safety profile is covered. The description goes further by disclosing volatility ('rules change frequently'), the verification obligation (central bank/local counsel), and an explicit 'information, not legal/tax/financial advice' disclaimer — meaningful context beyond 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-loads the core question, then the returned fields, then the parameter modes, then the disclaimer — a logical order with no filler. The concrete examples (India LRS, China SAFE) are illustrative rather than padding, though the sentence is dense and long.

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 2-parameter read tool with an output schema, the description covers purpose, returned fields, parameter behavior, and the important caveat that exchange-control rules are volatile and not advice. Nothing an agent needs to invoke or interpret this 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 both parameters are already documented, and the description largely restates them: 'pass cc for one jurisdiction; omit for all, or filter by regime.' It confirms the omit-for-all default but adds no syntax or edge-case detail beyond the schema, 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?

Opens with a specific framing question ('can money legally LEAVE this country, and how much?') and enumerates exactly what is returned: exchange-control regime, annual outbound allowance, cash-declaration threshold, regulator, and implications for funding investment-migration. The verb+resource ('capital controls') is unambiguous and no sibling (get_banking_access, get_emigration_flows, withholding_map) overlaps this scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the framing ('what it means for FUNDING an investment-migration programme'), which tells the agent the context in which to reach for it, and it explains the cc/regime parameter modes. However, it never names an alternative tool or states when NOT to use it (e.g., vs get_banking_access or flag_cfc_poe_risk), so selection guidance is only partial.

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 a safe, closed-world read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine context beyond that: the profile's contents (honest tax caveats, cost ranges, substance requirements), that it states who it does NOT fit, and the 'general information, not advice; execution via licensed local partners' 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?

Purpose is front-loaded in the opening clause before the dense key list and the attribute inventory. The 30-key parenthetical is heavy but functionally necessary given the missing enum; a few phrases ('required licensed executor', 'and provenance') could be trimmed without loss.

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, return values need no explanation, and the description covers what the profile contains, the catalogue fallback, and an advisory disclaimer. It stops short of noting provenance/freshness behaviour that siblings like get_provenance and get_recent_changes imply, a minor 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% and the param is documented, so baseline would be 3. The description earns above baseline by enumerating the 30 actual valid key values — the schema has no enum, so this list is the only place an agent can learn admissible values, plus it restates the omit-for-catalogue behaviour.

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 ('FULL formation profile for one structure from the Mirabello Global Structuring roster'), enumerates all 30 valid keys, and distinguishes the single-profile retrieval from the catalogue fallback. An agent can tell exactly what comes back and which structure keys are legal.

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 says 'Pass structure (the profile key); omit for the catalogue of available keys', which gives usage context for the one parameter. But it never names or excludes the obvious siblings (compare_formation, get_structuring_roster, get_structuring_playbook), so an agent still has to guess this tool's position among 60+ neighbours.

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, so the safety profile is covered and the bar is lower. The description adds useful scope context — this is a registry-style lookup returning screened pathways with official sources rather than advice — but discloses no rate limits, coverage caveats, or behaviour when a country has no pathways. Adds some value, not rich behavioural detail.

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 resource and scope, then the calling convention. The mid-sentence em-dash catalogue of pathways is dense but it is the substantive payload; nothing reads as 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, so return values need no further explanation, and the description already characterises the shape of the payload (per-pathway requirements, cost, processing, rights, official source). For a 3-parameter read-only lookup this is complete enough to invoke correctly.

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

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

Schema description coverage is 100%, so the schema already documents cc, pathway and nationality, including the detailed EU/EEA free-movement behaviour for nationality. The description only reinforces cc format with examples (CA, GB, DE, PT). With the schema doing the heavy lifting, 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 concrete resource ('country immigration profile') and enumerates exactly what it returns: every screened pathway — skilled-work, digital-nomad, retirement, citizenship-by-descent, naturalisation, study, family — each with requirements, cost, processing, rights, and PR/citizenship path. The parenthetical '(beyond investment migration)' and 'ALL screened pathways' implicitly separate it from get_programme and find_pathways, so the agent can discriminate without opening 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?

Usage is only implied: the tool is framed as broader than investment migration, and the ISO alpha-2 calling convention is given, but no sibling is named as the alternative and there is no explicit when-not-to-use guidance (e.g. use get_programme for a single investment programme, or find_pathways to search across countries). Adequate but leaves the routing decision 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond the annotations: provenance ('From official/Tier-A sources') and a scope disclaimer ('Informational only - not tax advice'). It does not discuss freshness or pagination, so it stops short of 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?

The purpose and scope are front-loaded, followed by a dense but purposeful enumeration of covered tax domains; each listed item is informative rather than filler. The stacked parentheticals (worldwide vs territorial, non-dom, lump-sum, NHR/IFICI, flat-tax) make it slightly heavy to scan, keeping it just below 5.

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 dedicated output schema present, return-value details need not be in the description. For a read-only, single-required-parameter lookup tool, the description supplies purpose, content scope, source provenance, and a liability disclaimer - 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% and the single parameter is fully documented in the schema. The description's 'Use the ISO alpha-2 code' merely restates the schema's 'ISO alpha-2 country code' without adding format examples or edge-case handling, 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 precise resource ('HNWI tax profile for a country') and enumerates the exact content domains covered (personal income tax worldwide vs territorial, capital gains, inheritance/estate, wealth tax, exit tax, CRS/AEOI, special regimes). The 'wealth-protection view' framing distinguishes it conceptually from pure-rate tools, but no sibling is named explicitly, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the content list — an agent can infer you call this to get a per-country tax profile — but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternatives such as find_low_tax, withholding_map, or compare_treaty_position, which overlap in scope. 'Use the ISO alpha-2 code' is a parameter instruction, not usage 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 declare a safe read-only, closed-world profile, so the bar is lower. The description still adds real behavioral context beyond them: each block carries provenance (confidence, verified_date, official sources) and low-confidence detail is deliberately withheld as CHECK-OFFICIAL-SOURCE, which tells the agent to expect gaps rather than treat absence as 'no programme'.

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?

Dense but front-loaded: the three data blocks come first, then the cc-scoping rule, then the provenance/disclaimer. Every clause carries information, though the enumerated field lists are long and the closing disclaimer slightly restates the provenance point.

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 not be explained, and the description still covers what each block contains, the confidence/withholding behavior, and the volatile-data caveat. Nothing an agent needs 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% and the schema itself documents the ISO 3166-1 alpha-2 format with examples, so the baseline would be 3. The description adds the omission semantics ('omit for all'), which the schema does not convey since cc is optional, and ties the parameter to the scoping behavior.

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

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

States a specific resource (per-country digital-money & identity progress) and enumerates exactly what it returns: CBDC status/type/issuer, stablecoin status and regulatory framework, and national digital ID status. This is clearly distinct from siblings like get_country, get_banking_access, or get_capital_controls, so an agent can route 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?

The description says 'Pass cc for one jurisdiction, omit for all', which is invocation guidance, and adds a 'verify the cited source' caution. However, it never states when to prefer this tool over adjacent siblings (get_country, get_regulator_registry, get_recent_changes) or when it is not the right source, so usage 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 cover the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false). The description adds genuinely useful behavioral context beyond that: the list is 'standard' and incomplete, varies by family composition and nationality, and is always subject to specialist confirmation. This sets accurate expectations about data 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?

A single tight sentence with the core purpose front-loaded and qualifications in parentheses. It is efficient, though the parenthetical and trailing caveat are dense rather than cleanly separated.

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 100%-covered single-param schema and an output schema present, the description need not explain returns. It supplies the key caveats an agent needs (variability, specialist confirmation) to interpret the output correctly, leaving little 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% and the single programme_id parameter is well documented in the schema itself (including a format warning and example), so baseline 3 applies. The description adds no additional meaning about the parameter 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?

States a specific verb+resource ('document checklist for a programme application') and clarifies its scope as per-programme-type with programme-specific additions. It differentiates itself from the sibling residence_evidence_checklist only implicitly via 'programme application', so it is clear but not fully sibling-routing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied — call this when you need the documents required for a programme application — but there is no explicit when-to-use/when-not or named alternative versus residence_evidence_checklist or compliance_checklist. The note that the final list is confirmed by a specialist hints at its advisory-only role without stating it as 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 only declare readOnly/openWorld/destructive hints, but the description adds substantive behaviour: a caveats field, the fact that ~48% of departures name no destination so rankings describe a partial base, that totals are a floor, a definitional break, and licence/attribution obligations. This is exactly the beyond-annotations disclosure the dimension rewards.

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

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

It is front-loaded with the data's identity and scope, and labelled cues (OFFICIAL, CRITICAL) aid scanning. The illustrative 2025 figures are useful colour but make the block longer than strictly necessary, keeping it out of the top band.

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?

Coverage is exhaustive for an agent's needs: source, time span, returned measures, base-population caveat, definitional break and licensing are all present, and an output schema already handles the exact return shape. 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 description coverage is 100%, so the schema already documents year, destination and top; the description only restates them ('Pass year, destination or top'). Baseline 3 is appropriate since the schema does the heavy lifting and the description adds no format or fallback detail beyond 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?

The description names a specific verb+resource (emigration flows by destination country and year), pins the exact source (Destatis statistic 12711-0008, 2016 onwards) and states the returned measures (departures, arrivals, net migration, destination share). It is unmistakably distinct from the surrounding citizenship/visa/programme 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?

It gives clear usage context ('Pass year, destination or top'), flags the analyst caution 'Popularity is not suitability', and warns against trending across 2015/2016. It never names an alternative sibling or states explicitly when not to use it, so it stops short of the explicit routing that earns 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 declare readOnlyHint/openWorldHint=false/destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: airline enforcement, nationality-dependent variance, volatility ('change without notice'), and an 'information, not advice' disclaimer. Not a full 5 since it doesn't describe output shape or data freshness guarantees.

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 core purpose, then the operational stakes, then parameter behavior, then caveats. Dense but each sentence carries information; only the parenthetical examples risk slight bloat.

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 rightly focuses on scope, usage, and caveats rather than return values. It is essentially complete for a single optional-parameter lookup tool; the only gap is not positioning itself explicitly against sibling eligibility/visa tools.

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 semantics the schema does not: passing cc scopes to one destination and omitting it returns all destinations. That optionality behavior 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?

States a specific verb+resource ('entry requirements for a destination') and enumerates the two rule families it returns: passport-validity rules (6-month rule, Schengen 10-year issuance cap, blank pages) and health/vaccination rules. This clearly separates it from siblings like check_visa_requirement, check_visa_free, and get_passport_renewal.

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 clear operational context ('a valid-looking passport is refused BOARDING if it fails these') and parameter usage ('Pass cc for one destination; omit for all'), so the agent knows when the tool matters. It stops short of explicitly naming which sibling to use instead (e.g., check_visa_requirement), so it is clear context without 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 only state the read-only/no-side-effect profile; the description adds genuinely non-obvious behavior: every figure carries legal basis, source tier and date, absence means UNVERIFIED rather than no route existing, and it frames output as information not legal advice. That provenance and absence-semantics disclosure materially changes how an agent should interpret 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-loaded with the resource and scope, then the three modes in a predictable order; the long parenthetical enumerations of relatives and costs are dense but informative rather than padding. Slightly over-packed for a single paragraph, but every clause carries routing or scope 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 values need no explanation; the description instead covers the things structured fields cannot -- the three invocation modes, per-category cost coverage, and interpretation caveats for missing data. Nothing needed to call a zero-required-parameter 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 description coverage is 100%, so the parameter baseline is 3; the description exceeds it by grouping the nine parameters into three coherent modes and clarifying intent (e.g. together_required = no later add-on, partner = unmarried partner, not spouse). It adds orientation but no syntax beyond the schema's own examples.

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?

Starts with a specific verb+resource ('FAMILY PATHWAYS: who can come with, or join, the main applicant') and enumerates the exact dependent classes covered (spouse, partner, children, adult dependent children, parents, siblings). A reader can distinguish it from siblings like find_pathways or compare_programmes 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 decomposes usage into three modes and names the parameter that selects each (programme_id, cc, screen), with worked examples (antigua-cbi, PT, children_ages [7,15,24]). It lacks any explicit exclusion or pointer to a sibling tool for the adjacent question (e.g. general pathway discovery vs. family-specific pathways), so it stops 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 declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful context: establishment is decided by the competent registry/regulator via licensed local partners, tax outcomes follow founder/beneficiary residence, and the output is information not legal/tax advice. Return format is left to the output schema.

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

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

Front-loads the resource and then a dense but purposeful inventory of covered content, followed by usage and a disclaimer. The opening is a long noun phrase rather than a verb-first sentence, and the field list is verbose, but each element supports semantic retrieval.

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 full annotation coverage, the description is complete: it defines scope, the optional-param behavior, and the advisory limitation. An agent has everything needed to decide whether to call it and with what argument.

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 goes beyond the schema by telling the agent what omitting cc does ('omit for the covered list'), which the bare 'ISO alpha-2 country code' description does not convey.

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

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

States a specific resource (charitable/private foundation and trust rules) and enumerates the exact content returned — legal form existence, regulator, endowment, governance, tax treatment, UBO visibility, trust recognition. The closing line that it 'deepens the charity and trust jurisdiction shortlists to 194-country coverage' distinguishes it from the sibling shortlist tools (find_charity_jurisdictions, find_trust_jurisdictions).

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 'Pass cc for one jurisdiction; omit for the covered list,' giving clear context for both invocation modes. It implies a follow-on to the shortlist tools rather than naming an alternative or stating exclusions, so it stops short of a full when/when-not 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the default return is truncated to the top 25, the full table is large, and insufficient-data programmes are flagged provisional and excluded from the headline ranking.

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 resource identity, then dimensions and the default/limit behavior. Nearly every clause earns its place, though the parenthetical dimension list is dense and could be trimmed slightly without loss.

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, return values needn't be explained, and the description still covers default truncation, the limit:0 escape hatch, and provisional-data handling. Only the sibling-routing piece is absent, which is a minor gap for a two-parameter read 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, but the description adds semantics the schema does not: the default limit is 25 and limit:0 is a documented sentinel meaning 'every ranked programme.' That sentinel behavior is nowhere in the schema and materially changes how an agent calls the tool.

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

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

States a specific resource (the Mirabello Investment Migration Index) and precisely what it is: a composite 0–100 ranking of CBI/RBI programmes across named dimensions. This distinguishes it from siblings like list_programmes (enumeration), compare_programmes (pairwise), and get_wealth_index (a different index). An agent can tell what it gets 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?

Gives clear operational context: filter by type, and the default of TOP 25 with limit to enlarge or limit:0 for the full table. What's missing is explicit routing against siblings such as list_programmes or compare_programmes, so an agent must infer when this index beats a plain programme list.

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, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape (steps, documents, itemised fees with source and verified flag, timelines, authority, missions), states the 'information, not legal advice' limitation, and pre-empts a misreading of the 1 August 2028 dates.

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

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

Purpose and scope are front-loaded in the first clause, and each parenthetical enumerates a distinct branch rather than padding. It is dense and long, but nearly every clause carries procedural specifics an agent would otherwise have to guess.

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 annotations present, the description need not explain returns, and it goes further than required by naming scope, exclusions and verification provenance. The only gap is that the relationship to the sibling get_passport_renewal is never resolved, which matters for a three-parameter lookup tool with an overlapping neighbour.

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 the enum values and the age/residence semantics already documented in the schema, so this is the baseline case. The description reinforces the residence split ('in Malta and abroad') and the fee-band-by-age logic, but adds no syntax or edge-case detail the schema lacks.

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 (Maltese citizen service procedures) and enumerates exactly four covered scenarios with the concrete artifacts each yields (fees, forms, art. references, timelines). It explicitly excludes investment citizenship, which clears it from find_fastest_citizenship/get_programme. It does not, however, explain how it relates to the nearby sibling get_passport_renewal, leaving one overlap unresolved.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the scenario list and the instruction 'Omit service for an overview', which tells the agent how to invoke it for a general answer. There is no explicit when-to-use-vs-alternatives routing against check_maltese_citizenship_eligibility, get_passport_renewal or estimate_malta_passport_fee, so an agent must infer the 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?

Annotations already declare readOnlyHint/non-destructive/closed-world, so safety is covered. The description adds value beyond them: it flags the output is informational not advice, scopes passport reach as context-only, and instructs combining with a consultation — useful framing not present in structured fields. It says nothing about rate limits or caching, but that is minor 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?

Front-loaded with the core purpose, then supporting attributes and caveats. The main sentence is dense with em-dashes and parentheticals, but each clause carries signal (attributes, disambiguation, parameter behavior, disclaimer) 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?

For a single-optional-param, read-only tool with an output schema and full annotations, the description supplies the missing conceptual context: what counts as 'mobility optionality,' how it differs from passport strength, and the informational-not-advice framing. Nothing essential for a correct call is absent.

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

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

Schema coverage is 100% with a well-documented cc parameter, so the baseline of 3 applies. The description adds genuine semantics beyond the schema by explaining the optionality — 'pass cc for one jurisdiction, omit for all' — clarifying the no-argument behavior, which the schema alone does not convey.

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: it returns the lawful residence/citizenship routes a jurisdiction offers (investment programmes) along with defined attributes (physical presence, family inclusion, path to permanence, processing time, regulator). It explicitly distinguishes itself from passport-strength tools by contrasting the 'planning view' with 'passport strength' and noting visa-free count is context only, so an agent can separate it from check_visa_free/list_visa_free_destinations without opening 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 clear context for use (jurisdiction-level planning of mobility optionality) and states 'Pass cc for one jurisdiction, omit for all,' plus the caveat to combine with the full immigration profile and a consultation. It does not explicitly name a competing sibling (e.g. check_visa_free or compare_programmes) as the alternative, so routing is inferred rather than spelled out.

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