mcp-server

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive nature. The description adds that the enquiry is delivered to Mirabello (external data sharing) and requires explicit consent, plus it returns a tracked booking URL. These are meaningful behavioral traits 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?

Three short sentences with zero redundancy. The core action is front-loaded, and the requirements and outcome are stated efficiently. No fluff.

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

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

Given the tool's complexity (20 parameters) and the presence of a detailed output schema, the description is adequate but not exhaustive. It does not guide the agent on which optional parameters matter most or provide any edge-case handling, but the schema's rich descriptions largely compensate. It could be more helpful for a tool this complex.

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 all 20 parameters are already documented in detail. The description adds that email, programme interest/message, and consent are required together, which is not explicit in the schema (only email is required). This is a useful but minor addition 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 ('Book') and resource ('free consultation with Mirabello Consultancy'), and adds key requirements and output. It clearly distinguishes itself from sibling tools like create_enquiry by focusing on booking a consultation rather than a generic enquiry.

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 lists prerequisites (email, programme interest/message, consent) but gives no guidance on when to use this tool vs alternatives such as create_enquiry or plan_path. No exclusions or alternative routing are mentioned, leaving the agent to infer the appropriate context.

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

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

Annotations already mark the tool as read-only and non-destructive; the description adds meaningful behavioral context by stating 'INFORMATION ONLY', that it never asserts compliance, and that output is grounded in FATF/Wolfsberg and programme rules. No contradiction with annotations.

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

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

The description is a single dense paragraph but front-loads the purpose and packs useful examples into the flow. Some repetition and length could be trimmed, but overall every sentence contributes.

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

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

The description covers outputs, standards grounding, no-args behavior, and info-only status, and an output schema exists. However, the unresolved conflict between the described 'wealth-origin type' and the schema's 'origin = country' leaves a critical gap for successful invocation, so it is not complete enough for an agent to call correctly.

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

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

The schema documents origin as the applicant's relocating-from country, but the description treats origin as a wealth-origin type (business_sale, inheritance, etc.) and context as destination context. This is a direct contradiction in the tool's core input semantics, so an agent cannot reliably fill the parameters from the description. High schema coverage only makes the mismatch more glaring.

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 deliverable (documentary evidence pack) and the inputs that drive it, and the output is clear: core/corroborating documents, context overlay, red flags. It does not explicitly compare against siblings like get_document_checklist or compliance_checklist, so differentiation is implicit rather than explicit.

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

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

It gives a concrete usage tip ('Call with no args to list available origins and contexts') and states the information-only caveat. It never says when to prefer this tool over sibling evidence/checklist tools, so the when-to-use-vs-alternatives guidance is missing.

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

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

Beyond the readOnlyHint and destructiveHint annotations, it discloses that only factual published policies are used and that final acceptance rests with government due diligence. This sets accurate expectations about the data source and the non-guaranteed nature of results.

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

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

Two sentences with no filler: the first front-loads the core function and criteria, and the second adds a necessary caveat. Every sentence earns its place.

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

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

With an output schema, fully described parameters, and read-only annotations, the description is sufficient for an agent to call the tool correctly. It communicates what the tool checks and its limitation without requiring additional inference.

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

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

The schema already documents all parameters (nationality, type, programme_id) with clear descriptions, so the baseline is 3. The description adds general context about eligibility factors but does not provide new per-parameter meaning beyond the schema.

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

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

The description names the verb 'Check' and the resource 'which programmes a given nationality can realistically apply to', listing concrete factors such as published nationality restrictions, EU-citizen applicability, minimum age, and core requirements. This clearly distinguishes it from sibling tools like check_visa_requirement or recommend_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?

It states the primary use case directly: determining realistic programme options for a given nationality. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide an agent toward this tool for eligibility checks rather than visa checks or programme comparison.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds that the tool returns a visa-free count and per-destination access, but discloses nothing about how the count is aggregated, data freshness, or behavior when no destination is given. This is useful context above annotations but not rich.

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 sentence with no filler; the destination list is concrete and useful. The opening phrase 'Mobility for a programme passport' is slightly abstract, but the description earns its length.

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; annotations cover the safety profile; and the two-parameter schema is fully documented. The only meaningful gap is lack of disambiguation from closely related visa siblings (check_visa_requirement, list_visa_free_destinations), which is not fatal for correct invocation given the clear schema.

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

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

Schema description coverage is 100%, including strong guidance that programme_id is a list_programmes ID, 'not a country name and not a website slug,' so the schema carries the parameter meaning. The description's destination examples (Schengen, UK, USA, China) duplicate what the schema already says, adding no new parameter semantics.

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

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

The description states a specific resource (programme passport) and outputs (visa-free count and access to key destinations, naming Schengen, UK, USA, China). The verb 'check' is only carried by the name/title, and the description does not explicitly distinguish itself from the sibling check_visa_requirement, but the resource and output are concrete enough for an agent to grasp the core function.

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, and closely related siblings like check_visa_requirement and list_visa_free_destinations are never mentioned. The 'Mobility for a programme passport' framing only weakly implies a mobility-assessment scenario, so an agent must infer when this tool is the right choice.

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

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

The annotations already mark the tool read-only and non-destructive, and openWorldHint=false aligns with the fixed dataset claim. The description adds substantial behavioral detail: exact outcome types, dataset coverage, corroboration/verification links, and an explicit caveat that rules change and the destination authority is final.

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

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

The description is two focused sentences: the first front-loads the core scope and outcome categories, the second adds source and authority caveats. Every clause is informative, with no filler or repetition of schema details.

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

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

For a two-parameter read-only lookup with an output schema present, the description is complete: it defines the query scope, enumerates possible results, states dataset coverage, names the returned supporting links, and warns about authority. Nothing essential 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 already have descriptive text, examples, and the special 'Schengen' case. The description reinforces the one-to-one pairing but adds no new parameter-level semantics, so it meets the baseline without exceeding 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 clearly states the operation: checking the visa requirement for exactly one nationality to exactly one destination, and it enumerates the possible outcome categories. It distinguishes itself from list-style siblings by emphasizing the single-pair scope, though it does not explicitly name alternatives like get_entry_requirements or check_visa_free.

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

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

The description gives clear usage context: single nationality/single destination lookups, backed by a fixed 199x199 dataset, with results returned alongside Wikipedia and IATA references. It does not explicitly state when not to use this tool or name preferred sibling tools, leaving the routing partly 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 mark the tool read-only and non-destructive, and the description adds substantial behavioral context: it returns no-useful-election when nationality opens nothing, warns that Swiss professio juris is VOID if Swiss nationality is later acquired, flags hard timing rules, and states that every election needs a properly executed declaration. It also adds input-format and data-privacy constraints plus an information-only 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?

The description is dense but information-rich, with the core question front-loaded and no filler or marketing language. It is one long paragraph and could benefit from bullet structure, but each legal detail materially helps the agent understand the analysis.

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 legal-analysis tool with an output schema, the description covers the essential behavior: instruments, elections, timing, situs overrides, no-useful-election handling, and execution requirements. The main gaps are that spouse_nationalities is not integrated into the narrative and sibling-selection guidance is only implicit.

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

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

Schema coverage is 100%, so the baseline is 3, but the description creates a real conflict: it says 'Pass ISO alpha-2 codes only,' while the spouse_nationalities schema explicitly expects country names (example 'Brazil'). It does add useful timing nuance around nationality at the time of the agreement, but the overgeneralized coding instruction could mislead an agent into passing the wrong format.

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

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

The description opens with a concrete question and then names exactly what the tool returns: default applicable law, instruments in scope, elections available, timing rules, situs overrides, and the trade-off involved. This is a specific verb-plus-resource definition with enough detail to distinguish it from sibling tools like succession_conflict_map or 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?

The domain framing ('cross-border family succession, matrimonial property and divorce') implies when the tool is relevant, and it lists the inputs used. However, it never explicitly states when to prefer this tool over alternatives like succession_conflict_map or matrimonial_regime_screen, and it gives no exclusionary guidance.

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

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

Annotations already establish read-only and non-destructive behavior. The description adds meaningful context beyond that by stating the tool provides 'comparative facts only' and is 'information, not advice', which sets expectations that it will not recommend a structure. No contradiction 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?

The description is compact and front-loaded: it immediately names the action and scope, then lists the comparison dimensions, then gives the input format, then adds an important caveat. Every sentence earns its place and there is no redundant 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-parameter, read-only tool with a rich output schema and safety annotations, the description is complete. It covers the input range and format, the fields being compared, the informational boundary, and the decision-relevant context about the owner's residence and goals.

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 describes the 'structures' parameter as '2-6 profile keys'. The description adds value by providing concrete examples of valid keys and emphasizing that input must be an array of profile keys, reinforcing the schema without repeating it verbatim.

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 ('compare'), a clear resource ('formation structures'), and enumerates the exact comparison dimensions. This distinguishes it from sibling tools like compare_programmes and compare_scenarios without needing to open any schemas.

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

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

The description provides clear context for when to use the tool by defining its scope ('formation structures') and specifying the comparison dimensions. It also frames the output as comparative facts rather than advice, though it does not explicitly name alternative tools or state when not to use it.

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, covering safety. The description adds meaningful behavioral context by detailing what the output contains (rank, composite, dimension scores, deltas, leads, URL) and clarifies that the URL is conditional ('where one exists'). It also distinguishes the two artefacts (canonical versioned vs classic) which helps set expectations. This goes beyond annotations and provides useful transparency.

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

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

The description is two sentences with zero filler. It front-loads the core purpose, then efficiently explains the two invocation modes and their outputs. Every piece of information earns its place; no redundancies. The structure is easy to scan and digest.

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

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

Given the tool has an output schema (so return details are covered elsewhere) and annotations (safety covered), the description covers all decision-relevant aspects: choosing between the two modes, what parameters to pass, and what outputs to expect. It is complete enough for an agent to invoke correctly. A minor enhancement could explicitly note that a and b should not be combined with ids, but the phrasing 'Or pass ids' makes this sufficiently clear.

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% (each parameter has a description). The description adds extra semantic value by explaining that 'a' and 'b' are used together for the two-programme canonical artefact, and that 'ids' is used for the 2-4 programme classic comparison. This clarifies the mutually exclusive usage and the relationship between parameters, 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?

The description clearly states the tool's function: compare programmes side by side. It names two distinct invocation modes (a+b for the canonical artefact, ids for the classic multi-column comparison) and enumerates the specific outputs of each (rank, composite, dimension scores, deltas, leads, URL; cost, processing, mobility, etc.). It differentiates from sibling tools like compare_formation or compare_scenarios by specifying the programme context and the Mirabello Index.

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

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

The description explicitly tells the agent when to use each parameter set: 'Pass a + b... Or pass ids (2-4)'. This is clear usage guidance for the two modes. However, it does not explicitly state when to prefer this tool over sibling comparison tools (e.g., compare_scenarios, compare_formation), though the object of comparison (programmes) is implied. It provides good guidance within the tool but not exclusions across siblings.

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

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

Annotations already mark this as read-only and non-destructive. The description adds useful behavioral context beyond those flags: it is 'informational only, not advice', limited to 2-8 jurisdictions, and positioned as a synthesis view that should be combined with other tools for a complete picture.

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

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

The description is front-loaded and information-dense, but the second sentence, 'The synthesis view over the tax, residence, structure, reporting and succession layers,' largely repeats the dimension list from the first sentence. It is useful but slightly redundant, so it does not quite achieve maximal conciseness.

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

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

Given an output schema exists and the annotations cover safety, the description provides enough operational context: jurisdictional scope, covered dimensions, input formats, limitations, and next steps. It is complete for practical use, though it leaves the semantics of 'pathway' mostly to the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that cc can be supplied as a comma-separated list (e.g. 'AE,PT,SG') and by summarizing the scenario shape as {cc,pathway}, which is not fully explicit in the schema alone.

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

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

The description opens with a specific action and resource: 'Side-by-side comparison of 2-8 jurisdictions across every wealth-protection dimension at once.' It then enumerates the exact covered layers, which clearly separates this synthesis tool from single-dimension siblings like get_country_tax or compare_formation.

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

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

The description gives clear input conventions ('Pass scenarios as an array of {cc,pathway} or cc as a comma list') and contextual guidance ('Informational only, not advice; combine with the immigration route and a specific double-tax-treaty corridor for the full picture'). It does not explicitly name alternatives or exclusions, but the intended use case is clear.

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

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

Annotations already mark the tool as read-only and non-destructive, so the bar is lower. The description adds useful behavioral context by specifying what aspects are evaluated and adding the caveat 'Indicative, not advice,' which clarifies reliability expectations. No contradiction with annotations is present.

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 concise, front-loads the core purpose, and avoids redundancy with the schema and annotations. It earns a high score for efficiency, though the conflicting parameter instructions prevent full marks.

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

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

The description covers output themes and the non-advice caveat, and the presence of an output schema reduces the need to explain return values. However, the parameter confusion is a substantial completeness gap: an agent cannot reliably call this tool without resolving whether inputs are country codes or dates.

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 introduces a serious mismatch: it says 'Use ISO alpha-2 codes' while the schema clearly defines 'from' and 'to' as ISO dates representing a date range. This conflicts with the schema's examples and descriptions, actively misleading an agent about what the parameters mean.

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

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

The description clearly identifies the tool's function: assessing double-tax-treaty position for a relocation from one jurisdiction to another, including DTA status, tie-breaker rules, withholding rates, and limitation-of-benefits tests. It is specific enough to distinguish from other tax-related siblings, though it does not explicitly name an alternative.

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 the intended use case through 'relocation corridor' and provides the operational instruction 'Use ISO alpha-2 codes.' It does not, however, state when to prefer this tool over siblings like withholding_map or get_country_tax, and no exclusion criteria are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety concern is hidden. The description adds valuable behavioral context beyond annotations: statelessness, the prohibition on passing personal data, and the non-exhaustive/informational nature of the output.

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

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

The description is dense, front-loaded with the substantive obligation list, and includes only high-value guardrails afterwards. It earns most of its length, but the parenthetical flag list partially duplicates the schema and is incomplete, so it is not perfectly economical.

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

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

Given the output schema, full schema parameter coverage, readOnlyHint=true, and zero required parameters, the description is largely sufficient: purpose, privacy behavior, and caveats are all covered. It only lacks an explicit pointer to sibling alternatives and the flag list omits two schema parameters.

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 fully documents all ten boolean flags and the description adds little semantic value beyond relisting some of them as 'boolean flags'. In fact, the parenthetical list omits rbi_applicant and eu_cross_border_arrangement, making the flag list slightly incomplete, but this is not a contradiction.

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

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

The description uses the specific verb 'Lists' with the resource 'reporting/compliance obligations a stated profile may trigger' and enumerates the regimes (FATCA, CRS, CARF/DAC8, DAC6, PEP, etc.), which clearly distinguishes it from sibling checklist and eligibility tools even though no sibling is named.

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 operational guidance on how to invoke the tool ('Pass boolean flags...') and clear boundary conditions ('STATELESS — pass only non-identifying flags, never personal data' and 'Informational only, not legal/tax advice'), so an agent knows when a first-pass compliance screening is intended. It does not explicitly name alternatives or when-not-to-use conditions, 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 indicate this is a side-effecting, non-read-only tool (readOnlyHint=false, openWorldHint=true). The description adds important context beyond that: the enquiry is delivered to an external licensed broker, requires explicit GDPR consent, and returns the next step. There is no contradiction with the annotations.

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

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

Three sentences with no wasted content: the core action is front-loaded, requirements and result are stated compactly, and the final sentence gives the strategic rationale. Every sentence earns its place.

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

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

For a tool with 11 parameters, an output schema, annotations, and many siblings, the description communicates the essential context: what is being routed, to whom, under what consent requirement, and what the caller gets back. It could have more explicitly excluded pure consultation requests, but no critical invocation detail 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 all 11 parameters. The description highlights the required trio (property_id, email, consent) and frames consent as GDPR-related, but it largely restates what the schema already conveys. It does not materially enrich individual parameter meaning.

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

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

The description clearly states the action ('Route a qualified buyer enquiry about a specific property to Mirabello Consultancy'), identifies the resource (property) and recipient, and separates this tool from read-only siblings like get_property or search_properties. It also specifies the key preconditions in the first sentence.

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

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

The description gives strong contextual guidance: it is the correct hand-off for CBI/RBI purchases and explains why Mirabello must be involved. It does not explicitly name alternatives such as book_consultation or get_property, so the when-not-to-use guidance is only implicit rather than fully exclusionary.

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

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

Annotations already carry readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a useful behavioral nuance: the stage breakdown is only included 'where available', implying possible partial output. Beyond that, no deep behavioral detail is given, but the bar is lower due to 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?

A single, front-loaded sentence with no filler. 'Step-by-step' conveys the format, 'expected timeline for a programme' conveys the scope, and 'where available' conveys a caveat. Every clause earns its place.

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

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

For a one-parameter, read-only tool with an output schema and annotations, the description is largely complete: it explains the output nature and the data availability caveat. It does not address choice relative to close siblings, but that gap is already scored under usage guidelines.

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 programme_id with an example and a clarification that it is not a country name or website slug. The description adds no parameter-level meaning, 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?

Description states a specific verb 'estimate' and resource 'timeline for a programme', and details the content: published processing time plus stage breakdown. The 'step-by-step' phrasing clarifies output format, and the content clearly distinguishes this from the close sibling get_processing_times, which likely returns only raw processing times.

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

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

No explicit guidance on when to use this tool versus alternatives such as get_processing_times or estimate_total_cost. Usage is implied through the purpose, but the description does not state exclusions, prerequisites, or conditions that would route an agent to a different tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable behavioral context: the estimate is 'indicative' and excludes certain fee categories, which sets expectations about accuracy and scope. It doesn't describe the output format, but the output schema exists and 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?

Two sentences with zero waste. The core action and scope are front-loaded, and the exclusions are stated in a compact second sentence. Every word earns its place.

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

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

For a read-only estimation tool with a full output schema and 100% parameter coverage, the description is nearly complete. The only minor gap is that it doesn't explicitly state that programme_id must come from list_programmes, but the schema already covers that. The description's exclusions and 'indicative' qualifier add the necessary context beyond structured fields.

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 four parameters. The description adds the high-level context that the estimate is for a 'family' and includes 'family add-ons', which maps to the children/adults parameters, but it doesn't add detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Estimate'), a specific resource ('total cost of a programme for a given family'), and the exact components included ('investment + government & due-diligence fees + family add-ons'). It also explicitly excludes professional/property/legal fees, which distinguishes it from other cost-related tools and clarifies its 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?

The description clearly implies when to use this tool: when an indicative total cost estimate for a family is needed. It does not explicitly name alternatives or exclusions, but the explicit exclusion of professional/property/legal fees and the 'indicative' qualifier provide clear context. It could be improved by naming a sibling like compare_programmes or estimate_timeline as an alternative for different needs.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds transparency about what results are selected or emphasized: 'donor tax relief, the entity tax status, cross-border granting and the standout vehicle.' No contradiction with annotations was found.

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

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

The description is two sentences and every part contributes: the main purpose, illustrative vehicle examples, output emphases, and the positioning relative to other advisory layers. It is somewhat dense but appropriately sized for a multi-faceted search tool.

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

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

For a read-only search tool with two optional parameters, an output schema, and strong annotation coverage, the description is complete enough. It conveys scope, selection emphasis, and how it fits into the broader tool family, leaving no critical gap for an agent deciding whether or how to invoke it.

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

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

Schema description coverage is 100%: the schema already defines vehicle with examples and donor_relief as a boolean for tax deduction/credit. The description reinforces these ideas but does not add meaningful semantics beyond the schema, so the high-coverage baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Find jurisdictions for setting up a CHARITABLE/PHILANTHROPIC structure.' It further distances itself from sibling tools by naming concrete vehicle types and positioning itself as 'the philanthropy/legacy complement' to residence, tax, and trust layers. An agent can clearly distinguish this from find_trust_jurisdictions and find_formation_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?

The phrase 'The philanthropy/legacy complement to the residence/citizenship + tax + trust layers' gives clear contextual guidance about when this tool is relevant versus the trust and formation siblings. It does not explicitly list when-not-to-use cases or name alternative tools, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds substantial context beyond those: qualifying residence excludes processing time, only fully verified statutes are covered, absence means unverified rather than no fast track, and transitional regimes are disclosed. This is exactly the kind of behavioral nuance that helps an agent trust and 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?

The description is long but front-loaded with purpose and usage, and each legal example earns its place by illustrating fast-track categories. The statutory citations add precision but make it denser than strictly necessary; still, nothing is purely 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?

Because an output schema exists, the description does not need to explain return shapes. It covers both call modes, exclusions, coverage semantics, and transitional regimes. Minor open questions remain about no-argument calls and combining nationality with cc, but the schema and output schema mitigate those gaps.

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 nationality, cc, and bloc. The description adds useful examples for nationality and cc, but it does not mention the bloc parameter at all and does not clarify behavior when multiple parameters are combined. This is an adequate but not exceptional contribution beyond the schema.

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

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

The description opens with a specific verb and resource: ranking citizenship routes by nationality-based fast tracks. It clearly distinguishes the two call modes — rank covered jurisdictions by nationality or inspect one jurisdiction via cc — and provides concrete legal examples that leave no ambiguity about what the tool computes.

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

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

The description explicitly instructs when to pass nationality versus cc, and the schema documents the optional bloc filter. It does not explicitly compare this tool to sibling tools like check_eligibility or get_processing_times, but the in-tool mode guidance is unambiguous and actionable.

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

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

With readOnlyHint=true and destructiveHint=false already in annotations, the description adds valuable context: it discloses the shape of the returned matches, notes that full profiles are not returned inline but are 'available on request', and flags a domain rule about profit tax following the owner. It also adds the 'Information, not advice' disclaimer. It does not mention auth or rate limits, but for a read-only filter tool this is reasonable.

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

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

The description is front-loaded with 'FILTER' and the main purpose, then packs the constraints, return fields, and caveats. It is dense but reasonably organized, with each sentence adding some value. It is slightly longer than necessary because it lists return fields that are likely covered by the output schema.

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

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

For a tool with 5 optional parameters and an output schema, the description covers filtering semantics, returned fields, and a domain caveat. However, it never states what happens when no constraints are provided (e.g., returns all jurisdictions or requires at least one filter), which is a notable gap given all parameters are optional.

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 parameters are already documented well. The description mostly restates the schema, with slight expansions like 'eu_clean' meaning 'exclude EU Annex I/II and FATF-listed' and 'remote_only' meaning 'fully remote formation.' This adds marginal clarity but does not materially go beyond the schema's 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?

The description clearly states a specific verb ('FILTER'), a resource ('Mirabello formation profiles'), and the purpose (find jurisdictions matching constraints). It enumerates the constraint dimensions, making the tool's function concrete. However, it does not explicitly distinguish itself from overlapping siblings like find_trust_jurisdictions or find_charity_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?

The phrase 'find company/structure jurisdictions matching constraints' implies when to use the tool, and the constraint list tells the agent what kind of selection it can perform. But there is no explicit guidance about when NOT to use this tool or which sibling tool to choose for related but different searches, so the guidance is only implied, not explicit.

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 the tool read-only and non-destructive; the description adds that it 'returns matching countries with their HNWI tax + CRS + EU-list (+ crypto) snapshot' and clarifies that non-CRS means 'no automatic financial-account exchange.' No contradictions with annotations.

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

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

Three sentences front-load the purpose and filter list, and the final sentence adds useful combination guidance without padding. Every sentence earns its place for an 8-filter tool.

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

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

Given full schema coverage, read-only annotations, and an output schema, the description covers what the tool finds and what it returns. The only notable omission is explicit AND/OR behavior across multiple filters, which is a minor gap for a boolean-filter tool.

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

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

Schema description coverage is 100%, so the baseline is 3; the description groups the boolean criteria and paraphrases a few terms, but it does not add substantial meaning beyond the schema. It also leaves combination semantics (whether multiple true booleans are ANDed) implicit.

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

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

The description opens with 'Find countries by wealth-protection tax criteria' and enumerates eight concrete filters, making the action, resource, and scope unmistakable. It is clearly distinguished from sibling search tools like find_trust_jurisdictions or find_formation_jurisdictions by centering on tax/wealth-protection criteria rather than entity type or pathway.

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

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

It gives clear context: this tool is for tax-criteria screening and returns a tax-plus-CRS/EU snapshot, and it explicitly recommends combining with a residence or citizenship route for a full tax-plus-pathway view. It does not, however, spell out when-not-to-use it or directly name sibling alternatives, so exclusions are left implicit.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds meaningful behavioral detail: it returns screened countries with key requirements, income thresholds, cost, and path to PR. This tells the agent what kind of output content to expect without relying on schema alone.

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 with no filler: the main action is front-loaded, the return contents are summarized, and the important eu-free-movement caveat is placed at the end. Every sentence earns its place.

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

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

With a complete input schema and an output schema present, the description does not need to explain return formats. It covers the purpose, the scope of results, and the key special case, making it sufficiently complete for an agent to call the tool correctly.

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

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

Schema description coverage is 100% for both parameters, so the baseline is 3. The description repeats some pathway examples already present in the enum and adds the eu-free-movement definition, but does not add substantial new parameter 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 uses a specific verb and resource: it finds countries offering a given immigration pathway. It names example pathway types and clarifies the special eu-free-movement case, which helps distinguish this pathway-query tool from sibling tools like check_visa_requirement or list_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 gives clear context for when to use the tool: when the agent needs to find countries for a particular pathway. It also provides a concrete usage rule about EU/EEA/Swiss citizens using eu-free-movement rather than a visa, though it does not explicitly name or exclude sibling tools.

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

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

Annotations already convey readOnlyHint=true and destructiveHint=false; the description adds valuable behavioral context beyond that: results are ranked by asset-protection strength and include statute, CRS status, and EU-list status. It also discloses filtering by vehicle or strong_protection, so an agent understands what the tool returns and how it behaves.

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

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

Three dense sentences with no filler: purpose and examples are front-loaded, the ranking and output fields follow, then filter behavior and positioning relative to other tools. Every clause earns its place.

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

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

With only two optional parameters, a full schema, an output schema, and safe read-only annotations, the description covers all an agent needs to invoke and interpret results. It even adds helpful domain positioning among a large sibling set.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces that filtering is by vehicle or strong_protection, but adds no new format, constraints, or edge-case 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?

States a specific verb ('find') and resource ('trust & foundation jurisdictions'), with clear domain purpose (asset protection and succession planning). Concrete examples and the ranked-by-strength behavior make its scope unmistakable, and the closing complement clause distinguishes it from residence/citizenship tools.

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

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

Provides clear context for when this is relevant: trust/foundation wealth structuring, asset protection, succession planning, with a positional hint that it complements residence/citizenship pathways. It does not explicitly name sibling alternatives or when not to use it, but the scenario context is strong enough to guide 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 already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds meaningful behavioral context: it states the output is 'indicative, not advice' (disclaiming reliability), and it scopes the content to jurisdictional tax-risk flags. This goes beyond the structured annotations by clarifying the tool's advisory nature.

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 tightly packed: three short sentences plus a caveat. It front-loads the core purpose ('Anti-avoidance & relocation-tax flags'), then enumerates key included items, contrasts with headline rates, and closes with a format reminder and disclaimer. No wasted words; every segment earns its place.

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

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

For a single-parameter, read-only tool with an output schema present, the description is complete: it defines the resource, gives the input format, scopes the content, and warns about applicability. An agent has everything needed to invoke it correctly without reading 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?

The schema already provides full coverage of the single parameter 'cc' with examples and explicit format ('uppercase'). The description repeats the ISO alpha-2 requirement, which adds marginal value but does not introduce new semantics. Baseline 3 is appropriate given full schema coverage.

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-resource combination: it flags anti-avoidance and relocation-tax risks for a jurisdiction, listing concrete components (CFC, GAAR, POEM, economic substance, exit tax, step-up). It explicitly contrasts with 'headline rates', which distinguishes it from siblings like get_country_tax. An agent can immediately tell what this tool does and why it exists.

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

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

The description provides clear context for when to use the tool: when depth beyond headline rates is needed. The phrase 'depth behind headline rates' implies a contrast with rate-only tools, and the caveat 'Indicative, not advice' sets expectations. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for an agent to route correctly.

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

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

Annotations already supply readOnlyHint=true and destructiveHint=false, so the description's burden is lighter. It adds value by disclosing that the output states default legal rules rather than predicting actual estate devolution, and by listing the specific questions the tool addresses. This is honest, useful behavioral context beyond the structured 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 dense, front-loaded passage with no filler; the jurisdiction-level concept comes first, followed by concrete legal aspects and a crucial caveat. The illustrative country examples earn their place, though the long list makes it slightly harder to parse at a glance.

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

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

For a one-parameter tool with an output schema and read-only annotations, the description covers purpose, scope, key legal dimensions, and a critical exclusion. Nothing an agent needs to select and invoke the tool correctly appears to be missing.

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

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

Schema description coverage is 100%, so baseline 3 applies. The description only reiterates 'Use ISO alpha-2', which the schema already states with examples and uppercase guidance. It adds no new meaning beyond the parameter 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 specifies a jurisdiction-level forced-heirship and testamentary-freedom position and enumerates the exact legal aspects covered: reserved shares, freely-disposable portion, disinheritance, and trust/foundation interaction. It also scope-limits itself to default legal rules, which distinguishes it from estate-devolution and conflict-of-laws siblings.

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

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

The 'for a jurisdiction' and 'NOT how any estate will devolve' language provides a clear context and one exclusion, but the description never names an alternative sibling or explicit when-not condition. An agent must infer when to choose this over succession_conflict_map or matrimonial_regime_screen from sibling names alone.

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=false and openWorldHint=true, and the description adds complementary behavioral context: the generated URL expires after 90 days, and the tool can register the client for specialist follow-up contingent on email and consent (GDPR). These are genuine side-effect disclosures beyond the annotation flags. Minor gaps remain (e.g., what data is stored on registration, whether an email is dispatched), but nothing contradicts 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?

Two sentences and roughly 50 words with the core function and inputs front-loaded in the first sentence and the optional side effect in the second. Every clause carries information and nothing repeats schema or annotation content.

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

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

Given an output schema, safety annotations, and 100% parameter coverage, the description only needs to carry behavioral and selection essentials, which it does: inputs, outputs, URL validity, and optional registration. The notable gap is that all 14 parameters are optional and the description never states which combination yields a valid briefing. The absence of sibling-differentiation guidance also keeps this 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%, so the baseline is 3 even without parameter detail in the description. The description adds modest value by grouping parameters into a 'client profile' and hinting that family composition drives the cost math (children under/over 16 are priced separately in the schema). It does not, however, explain any parameter beyond what the schema already documents.

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

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

The description opens with a specific verb+resource ('Generate a personalised Mirabello briefing') and enumerates distinct outputs — a ranked shortlist, full family cost math, and a branded shareable URL valid 90 days — that clearly separate it from siblings like recommend_programmes or estimate_total_cost. Inputs (nationality, budget, family, goals) are named, so an agent understands both function and scope 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?

Usage context is implied by the listed inputs (a client profile with nationality, budget, family, goals), and the prerequisite for the optional registration (email + consent) is stated. However, in a sibling set of 60+ tools, no exclusions or alternatives are named — an agent is not told to prefer estimate_total_cost or recommend_programmes for narrower requests. This leaves the when-not-to-use 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 and destructiveHint=false, and the description does not contradict them. The description adds a useful content inventory but no additional behavioral context such as data freshness, response shape, or closed-world limitations; for a no-side-effect About tool, that is acceptable but not a distinctive disclosure.

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

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

The description is one dense, well-structured sentence that front-loads the subject and then packs content categories and example use cases into a compact list. Every clause adds distinct value and there is no filler.

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

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

For a zero-parameter, read-only informational tool with an output schema present, the description sufficiently covers what the tool is about, what content it returns, and when to call it. Nothing needed to select or invoke 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?

The tool accepts zero parameters and the schema coverage is 100%, so there are no parameter details for the description to clarify. The baseline of 4 applies because no parameter confusion is possible.

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 as 'Mirabello Consultancy' and enumerates concrete content facets: track record, credentials, offices, languages, and services. The 'Use for' clause states the exact questions the tool answers, distinguishing it from sibling tools about countries, programmes, and structuring.

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

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

The description provides explicit trigger examples: 'who is Mirabello / why use them / are they reputable' questions. It does not name sibling alternatives or say when not to use it, so it falls just short of a 5, but the intended context is unmistakable.

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, covering the safety profile. The description adds that the listings are 're-verified,' which gives a hint about data freshness but doesn't go beyond that. It doesn't mention pagination, ordering, or what happens when no updates exist, but with annotations covering safety and a simple read operation, this is adequate.

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, efficient sentence that front-loads the core function ('Recently re-verified listings') and then states the optional filter. There is no fluff or redundant information; every word contributes to the meaning. This is a model of concise tool descriptions.

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

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

For a read-only tool with one optional parameter and an output schema, the description covers the essential points: what is returned (listings with price/availability/sale status) and how to filter (since date). Since the output schema exists, the return format is not required in the description. The only minor gap is not mentioning that the result is a list, but that's implied. Overall, it is complete for the tool's simplicity.

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% since the only parameter 'since' is described as 'ISO date, e.g. 2026-06-01'. The description also mentions 'optionally since an ISO date,' reinforcing the parameter but adding no new semantics. Given high schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool returns recently re-verified listings with price/availability/sale status, optionally filtered by a date. It uses a specific verb ('get') and resource ('availability updates'), making the purpose unambiguous. However, it does not explicitly differentiate from the sibling tool get_recent_changes, which could overlap in function, so it misses a point for sibling distinction.

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 'For agents keeping an inventory view fresh' gives a general usage context, implying this tool is useful when maintaining up-to-date inventory data. However, it provides no explicit guidance on when not to use it or how it compares to alternatives like get_recent_changes or subscribe_changes. The guidance is implied rather than direct.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds valuable behavioral context beyond that: the 'Honest doctrine' about no guarantee and the 'Information, not advice' disclaimer, which inform the agent about the nature and limitations of the response. This goes beyond the annotation basics.

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 dense single paragraph but front-loads the core purpose ('NON-RESIDENT banking-access landscape per jurisdiction') before listing specifics. Every sentence contributes substantive content, though it is lengthy and could be broken into more digestible bullets. It is appropriately sized for the complexity of the tool.

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

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

For a tool with an output schema and read-only annotations, the description is highly complete. It covers the jurisdictions, the type distinction, the fintech vs traditional comparison, timelines, rejection causes, CBI synergy facts, and the honest caveat. The agent has enough information to decide when to call it and what to expect, without needing to open the schema.

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

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

Schema coverage is 100%, so both parameters are documented in the schema. The description adds meaning beyond the schema by explaining that cc can be a jurisdiction code or 'EMI', that type filters to corporate/personal, and that omitting cc returns the coverage list. This clarifies the intended usage and edge cases beyond the schema's simple string 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?

The description explicitly states the resource (non-resident banking-access landscape) and the verb (get), and enumerates the specific coverage: jurisdictions, corporate/personal lanes, fintech vs traditional institutions, timelines, minimums, rejection causes, and CBI/Golden-Visa synergy facts. This clearly distinguishes it from generic banking tools and even mentions the EMI layer, making its scope unambiguous.

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

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

The description gives clear parameter-usage instructions (pass cc, type, omit cc for coverage list) but does not explicitly compare against sibling tools like get_nonresident_banking or state when to choose this over others. It implies usage by detailing what it covers, but lacks explicit when-to-use/when-not-to-use guidance or alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns regulatory data, includes a disclaimer ('Information, not legal/tax/financial advice'), and warns that exchange-control rules change frequently, advising verification. This goes beyond the annotations without contradicting them, enriching the agent's understanding of the tool's operational context.

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

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

The description is informative but somewhat verbose. It opens with a rhetorical question and includes marketing-like phrasing ('uniquely', 'missed by every mobility-only analysis') that adds length without essential operational detail. While the key usage and output information is present and front-loaded, the extra flourishes could be trimmed for conciseness. It remains structured and readable, but not maximally efficient.

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

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

Given the tool's moderate complexity (2 optional params, no required fields) and the presence of an output schema, the description is complete. It specifies the exact data returned (regime, allowance, threshold, regulator, funding implications), explains invocation patterns, and adds a disclaimer about regulatory changes. The output schema covers return structure, so nothing critical is missing for an agent to call this tool correctly.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds the usage semantics that both parameters are optional and explains the effect of omitting cc ('omit for all') and using the regime filter, which the schema does not convey. It also clarifies that cc is an ISO alpha-2 code, though the schema already states that. This extra guidance justifies a score above the baseline of 3.

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

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

The description clearly states the tool's function: returning exchange-control regime, outbound allowance, cash-declaration threshold, regulator, and implications for funding investment-migration. It uses specific verbs and resource references, and distinguishes itself from siblings by noting it is 'missed by every mobility-only analysis.' The purpose is unambiguous and differentiates this tool from get_mobility_optionality and other related tools.

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

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

The description provides explicit usage patterns: 'Pass cc for one jurisdiction; omit for all, or filter by regime.' It explains optional parameter usage and offers context for when to apply (deciding whether a client can pay for a CBI/RBI programme). However, it does not name specific alternative tools or explicitly state when not to use it, so it falls short of 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 the tool read-only and non-destructive. The description adds meaningful context: the output is general information, not advice, and execution happens via licensed local partners. It also discloses the caveated tax-position content, which sets expectations beyond the 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?

Dense but purposeful, with the core function front-loaded before the profile contents and usage instruction. The long roster list is verbose but useful as a de facto enum; nothing in the description is filler, though the single-paragraph structure could be more scannable.

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

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

For a one-optional-parameter, read-only tool with an output schema, the description provides the full accepted key set, the omit-for-catalogue fallback, and a liability caveat. An agent has everything needed to invoke it correctly, and the return shape is already covered by 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% and already documents the optional structure key with examples. The description adds value by enumerating all 30 valid profile keys, materially reducing the risk of an agent passing an invalid or hallucinated structure identifier.

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 that it returns the full formation profile for one structure from a named 30-profile roster and enumerates exactly which structures are covered. This clearly distinguishes it from catalogue-style or comparison siblings by framing it as a single-structure deep dive.

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?

Explains the input contract clearly: pass a structure key for a profile, or omit it for the catalogue of available keys. It gives an agent a concrete selection rule, though it does not explicitly name alternatives like compare_formation or get_structuring_roster.

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. The description adds meaningful behavioral context by specifying what the returned profile includes: requirements, cost, processing, rights, path to PR/citizenship, and the official source, and by emphasizing exhaustiveness ('ALL screened pathways'). No contradiction with annotations.

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

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

Two sentences with no filler: the core resource and scope are front-loaded, the parameter format is given with concrete examples, and every clause adds information.

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

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

For a read-only lookup with one required parameter, a rich output schema, and full schema parameter descriptions, the description provides everything an agent needs to select and invoke the tool. 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 the schema already documents the cc, pathway, and nationality parameters, including the free-movement special case. The description only reinforces the ISO alpha-2 format, adding no meaning beyond the schema.

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

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

The description identifies the resource ('Country immigration profile') and scope ('ALL screened pathways'), enumerating pathway types and explicitly noting 'beyond investment migration'. This distinguishes it from investment-migration siblings, though it lacks an explicit verb like 'get' or 'retrieve' and does not name alternative tools.

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

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

It defines when the tool applies: all screened immigration pathways beyond investment migration, and it instructs the caller to use an ISO-3166 alpha-2 code. However, it does not explicitly state when to prefer this over sibling tools such as get_programme, list_programmes, or find_pathways, leaving routing largely 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 set readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the description doesn't need to repeat safety. The description adds context beyond annotations: it specifies scope ('wealth-protection view'), sources ('official/Tier-A'), and caution ('not tax advice'). It also lists the specific covered tax areas. This enriches behavioral understanding without contradiction.

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

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

The description is a single, dense paragraph that front-loads the key scope, lists all major tax categories, and ends with actionable usage instructions. Every sentence earns its place; there is no filler or redundancy.

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

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

Given the tool has an output schema (has_output_schema=true) and high schema coverage, the description need not detail every return field. It covers purpose, scope, source, usage, and a safety caveat. The only minor gap is lack of explicit sibling differentiation, but the detailed scope already implies its unique role. Thus, it is near 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% (the 'cc' parameter is described as ISO alpha-2 country code), so baseline is 3. However, the description's instruction to 'Use the ISO alpha-2 code' directly reinforces and operationalizes the parameter meaning, ensuring the agent knows the exact format. This added clarification justifies above baseline.

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

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

The description clearly states 'get_country_tax' returns 'HNWI tax profile for a country', enumerating specific tax components (income, capital gains, inheritance, wealth, exit tax, CRS/AEOI status, special regimes). This verb+resource+scope is specific and distinguishes it from siblings like get_capital_controls or withholding_map. It also notes the source (official/Tier-A) and informational nature.

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

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

The description explicitly indicates 'Use the ISO alpha-2 code', providing essential usage guidance for the parameter. It also states 'not tax advice' which qualifies use. However, it doesn't explicitly mention when to prefer this over siblings like get_country, get_capital_controls, or withholding_map, though the detailed scope implicitly differentiates. Without exclusions, it falls 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 only declare readOnlyHint and destructiveHint, so the description carries the burden of explaining behavior. It goes beyond that by disclosing provenance fields, the CHECK-OFFICIAL-SOURCE withholding behavior for low-confidence details, and the advisory nature with 'INFORMATION, NOT ADVICE.' This is exactly the kind of behavioral context an agent needs.

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

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

The description is longer than average, but it earns its length by packing three distinct content categories into a clear numbered structure. The lead sentence front-loads the purpose before diving into details, and the caveats at the end are concise.

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

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

For a read-only data tool with a single optional parameter and an output schema, the description covers everything needed to select and invoke it: scope, parameter behavior, provenance, confidence handling, and verification expectations. Nothing critical is missing.

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

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

With 100% schema description coverage, the schema already fully documents the optional cc parameter, including format, examples, and case sensitivity. The description adds one useful nuance—omitting cc returns all jurisdictions—but it does not add substantial new semantic 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?

The description names a specific verb and resource: 'Per-country digital-money & identity progress relevant to wealth planning.' It then enumerates three concrete content areas (CBDC status, stablecoin status, digital ID status), which clearly distinguishes it from sibling getters like get_country or get_recent_changes.

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 states the scope and the cardinality rule: 'Pass cc for one jurisdiction, omit for all.' It also warns that statuses change and to verify sources, giving the agent a clear sense of when the tool is appropriate. It does not explicitly compare against alternatives, but the purpose is specific enough to make the intended use obvious.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is already known. The description adds context about the checklist varying by family composition and nationality, and that the final list is always confirmed by a specialist—this is useful behavioral information beyond the annotations. No contradiction; the added variability and confirmation details justify a 4.

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

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

The description is two sentences with zero filler. It front-loads the core purpose in the first sentence and adds necessary variability context in the second. Every sentence earns its place, and it is highly scannable.

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

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

This is a simple tool with one parameter, an output schema exists, and no nested objects. The description covers the tool's role, the specialist confirmation, and variability factors. Nothing critical is missing for an agent to call it correctly given the surrounding schema and 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 description coverage is 100%, and the schema fully describes programme_id with an example and explicit instruction that it is not a country name or slug. The description does not add any additional parameter semantics beyond what the schema already provides, so the baseline 3 applies.

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

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

The description clearly states the tool retrieves a 'standard document checklist for a programme application' with details about per-programme type and programme-specific items. It is specific about the resource and scope, but it does not explicitly differentiate from sibling tools like compliance_checklist or residence_evidence_checklist, which might also relate to checklists. This prevents a 5.

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

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

The description implies usage when a programme application's document checklist is needed, but it provides no explicit guidance on when not to use this tool or how it differs from alternatives such as compliance_checklist. No alternatives are named, and there is no when-not guidance, so it does not meet the bar for a 4.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description goes well beyond annotations by disclosing the caveats field, that 48% of departures state no destination, that totals are a floor, and that a 2015/2016 definitional break exists. This is exactly the kind of behavioral nuance an agent needs.

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

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

The description is dense but well-structured: it front-loads the data source, then the return fields, then critical caveats, then usage instructions. It could be slightly trimmed, but the statistical context and caveats are valuable enough to justify the length.

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

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

The description is complete for an agent to call this tool correctly: it identifies the data source, year range, return dimensions, critical caveats, and licensing requirements. With a full input schema, output schema, and read-only annotations, no essential operational context 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 all three parameters. The description's 'Pass year, destination or top' adds minimal extra meaning beyond what the schema provides, but it confirms the expected call pattern without conflicting with 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 clearly states the tool's function: returning departures, arrivals, net migration, and destination share from official German emigration statistics. It identifies the specific data source (Destatis statistic 12711-0008) and scopes it by destination and year, making it unambiguously distinct from the broad set of migration-related siblings.

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

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

The description gives concrete usage context: pass year, destination, or top, and explicitly warns not to trend across 2015/2016 due to a definitional break. It also frames the tool as revealing preference rather than suitability. However, it does not name alternative tools or explicitly state when to prefer one sibling over another.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the Schengen 10-year issuance cap invalidates passports whose printed expiry is still in the future, and rules vary by nationality and change without notice. It also discloses the 'Information, not advice' limitation. This goes beyond the annotations without contradicting them.

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

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

The description is dense but well-organized: it front-loads the core purpose, then details the specific rules, then gives the operational warning and usage instruction. Every sentence earns its place. It's slightly long but the density of useful information justifies the length.

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

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

For a read-only lookup tool with one optional parameter and an output schema, the description is nearly complete. It covers what the tool returns (entry requirements), how to invoke it (cc optional), and important caveats (enforcement varies, changes without notice). The only minor gap is not describing the output schema's structure, but the output schema exists and the description needn't explain return values per the rubric.

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% for the single 'cc' parameter, so the schema already documents it. The description adds meaning by explaining the parameter's role ('Pass cc for one destination; omit for all') and its semantics (ISO alpha-2 destination country code is in the schema, but the description clarifies the omission behavior). This is a meaningful addition 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 ('get') and resource ('entry requirements') with a clear scope: passport-validity rules and health/vaccination entry rules for a destination. It distinguishes itself from siblings like check_visa_requirement and get_document_checklist by naming the specific rule types (6-month rule, Schengen 10-year cap, blank pages, yellow-fever certificate).

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

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

The description explicitly says 'Pass cc for one destination; omit for all' — a clear usage instruction. It also provides operational context ('a valid-looking passport is refused BOARDING if it fails these') that tells the agent when this tool matters. While it doesn't name sibling alternatives, the specificity of the rule types makes the use case unambiguous.

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

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

Annotations already declare readOnlyHint and destructiveHint, but the description adds meaningful behavioral context beyond those: establishment is decided by the registry/regulator and executed via licensed local partners, tax outcomes follow residence, and the output is explicitly information, not legal or tax advice. No contradiction with annotations.

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

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

The description is dense and front-loaded with the core topic, and every clause adds substantive coverage detail. However, it is a single very long sentence with a heavy enumeration, which would be easier to parse if structured into bullets; the content is earned but the format taxes readability.

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

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

For a read-only reference tool with one optional parameter and an output schema, the description covers scope, invocation mode, jurisdictional coverage, establishment caveats, and tax-residence nuance. Nothing an agent needs to decide whether to call it, and how 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 schema describes cc as an ISO alpha-2 code, and the description adds the essential behavioral semantics: passing cc targets one jurisdiction, while omitting it returns the covered list. This goes beyond the schema's field description and resolves the key ambiguity of an optional parameter.

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

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

The description identifies a specific resource—foundation and trust rules—and enumerates the exact topics covered, from legal form existence to UBO visibility. It also distinguishes itself from shortlist siblings by framing this as the deep-dive layer ('Deepens the charity and trust jurisdiction shortlists...'), so an agent can tell it apart from find_trust_jurisdictions or find_charity_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?

The description gives clear invocation guidance: 'Pass cc for one jurisdiction; omit for the covered list.' It also positions the tool contextually as the deep-dive successor to shortlist tools. However, it does not explicitly name alternative tools or state when not to use it, so the guidance is strong but not fully exclusionary.

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

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

The description goes beyond the readOnlyHint annotation by disclosing the default TOP 25 behavior, the effect of limit:0, and that provisional programmes are excluded from the headline ranking. This gives the agent useful behavioral context without contradicting 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 three sentences with no fluff. Key behavioral facts are front-loaded, and each sentence adds a distinct piece of information: what the index is, how to filter, and how provisional entries are handled.

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

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

For a tool with two optional parametersebschemas covering both and an output schema present, the description covers everything an agent needs: the default return size, how to get more or all results, and how data quality is flagged. No critical information 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 already 100%, but the description adds meaning on top: it explains the default limit of 25, the special limit:0 semantics, and the type filtering purpose. This is genuinely helpful 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 clear verb and resource: it returns a composite 0–100 ranking of CBI/RBI programmes, and covers the major dimensions assessed. It is specific enough to be understood, though it does not explicitly differentiate itself from sibling tools like get_wealth_index 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 explains how to filter and limit results, including the default TOP 25 behavior and the special limit:0 option. However, it does not provide explicit guidance on when to use this tool versus alternative ranking/comparison tools among the many siblings.

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

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

Annotations already cover readOnlyHint and destructiveHint, so the safety profile is established. The description adds value by disclosing the planning-only perspective, that passport reach is contextual, and that the content is information rather than advice.

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

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

Every sentence earns its place: the first defines scope and content, the second clarifies the passport-context caveat, and the third gives invocation and advisory boundaries. The core definition is front-loaded and no filler appears.

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

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

Given the single optional parameter, the presence of an output schema, and read-only annotations, the description is complete. The agent knows what the tool returns, how to scope it, when to omit the parameter, and how to use the result within a broader workflow.

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

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

The input schema already documents cc as an ISO 3166-1 alpha-2 code with examples at 100% coverage. The description adds the important semantic that omitting cc scopes the result to all jurisdictions, which is not stated in the schema.

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

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

The description clearly defines the resource: strategic mobility optionality for a jurisdiction, listing the exact attributes returned (minimum physical presence, family inclusion, path to permanence, processing time, regulator). It explicitly differentiates from passport-strength tools by saying 'not passport strength' and treating visa-free count as context only.

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?

Direct invocation guidance is present: 'Pass cc for one jurisdiction, omit for all.' It also gives a clear 'not passport strength' boundary and advises combining with the immigration profile and consultation. It does not name alternative sibling tools explicitly, but the exclusions are still usable.

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 readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond that: 'Mirabello informs and orchestrates but does not file applications', 'Decided solely by the competent registry or court', and 'Information, not legal advice'. These caveats set correct expectations for an agent and the user.

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

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

The description is dense but every sentence earns its place: scope, coverage areas, typical use cases, parameter behavior, and limitation/disclaimer. It is front-loaded with the core purpose and avoids redundant restatements of the schema or annotations.

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

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

Given the single optional parameter, rich output schema, and annotations, the description fully equips an agent to invoke the tool correctly. It explains what will be returned, when to use it, how to pass the parameter, and what the tool does not do, leaving no critical operational 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?

The schema already documents cc as an ISO alpha-2 country code with examples, so baseline is 3. The description adds meaning by clarifying that cc is optional ('Pass cc for one jurisdiction; omit for the covered list'), which is not explicit in the schema and helps an agent decide how to invoke 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?

The description opens with the specific resource 'LEGAL NAME CHANGE rules for a jurisdiction' and enumerates exactly what aspects it covers: permission grounds, deciding authority, applicants, process, cost, timeline, passport effects, transliteration, and foreign record persistence. This makes the tool's purpose unmistakable and distinguishes it from sibling get_* tools.

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

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

The description gives clear usage triggers ('needed after marriage, after naturalisation, and when a non-Latin name must be rendered consistently') and precise input instructions ('Pass cc for one jurisdiction; omit for the covered list'). It does not explicitly reference an alternative sibling for exclusion, but the usage context is strong enough to guide 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 already signal read-only and non-destructive behavior, but the description adds significant interpretive context: statutory and practical bank appetite are kept separate, minimums are bank policy not law, no account opening is ever guaranteed, and CRS/FATCA transparency is always present. These caveats materially shape how an agent should interpret the tool's output.

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

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

The description is longer and uses heavy capitalization, but it is front-loaded and information-dense. Most clauses carry operational meaning, and the length is justified by the tool's complexity, though it could be more formally structured.

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

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

Given the simple optional parameter and the presence of an output schema, the description covers scope, profiles, parameter behavior, the distinction between law and policy, and critical limitations. Nothing essential is missing for correct invocation.

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

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

The schema already documents cc as an ISO alpha-2 country code with examples at 100% coverage. The description additionally explains the optionality behavior—pass cc for one jurisdiction, omit for the covered list—which is not present in the schema and controls the returned scope.

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

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

The description clearly states the tool provides bank-account access for foreign non-residents in a jurisdiction, and enumerates two specific profiles: non-resident individual and foreign entity. It names its scope and key distinction—statutory position versus practical bank appetite—which separates it from related banking tools.

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

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

The description gives clear invocation guidance: pass cc for one jurisdiction, or omit it for the covered list. It clearly frames when the tool is relevant, though it does not explicitly name alternatives or state when not to use it relative to the sibling get_banking_access tool.

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

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

With readOnlyHint and destructiveHint already covering the safety profile, the description adds non-obvious context: citizenship is permanent even if a passport lapses, results are information rather than advice, and figures include official sources and last_verified dates. It also scopes approximations and exceptions like Vanuatu in-person biometrics. No contradiction with annotations.

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

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

The description is dense but efficient: every clause covers a fact category, an exception, or a caveat, and the target resource is front-loaded. It is a single long run-on paragraph, which slightly hurts scanability, so it does not receive a 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?

Given an output schema exists and annotations characterize safety, the description covers country selection, six-country scope, current rule changes, processing and biometric details, ECCIRA deadlines, source URLs, last_verified, and the information-not-advice disclaimer. Nothing essential for selecting or calling the tool is missing.

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

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

The input schema already fully documents the country parameter as 'programme id or country alias; omit for all six', and the description essentially restates this with examples. Since schema coverage is 100%, the description adds no new parameter-level 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?

The first clause names a specific resource—CBI passport-renewal facts—and immediately delimits the six covered countries and the fact categories included. This goes beyond the tool name and title, and clearly separates it from sibling get_* tools.

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

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

The description makes the call context clear: use this tool when passport-renewal facts for these CBI countries are needed, and 'omit for all six' to get broad results. It does not explicitly name alternatives or exclusions, but the resource is specific enough that an agent can route to it safely.

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 readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds the distinction of 'estimate' (not exact) and the scope option (one or all), which adds behavioral context. It doesn't explicitly state that it's read-only, but the annotation covers that. The description doesn't mention potential rate limits or data freshness, but for a simple read tool, this is adequate. No contradiction with annotations.

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

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

The description is one sentence, front-loaded with the core purpose, and efficiently conveys the two usage modes. Every word earns its place. It is concise without being under-specified.

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 is simple (one optional parameter), has an output schema (so return format is covered), and annotations handle safety. The description clarifies the scope (one or all) which is important for optionality. It doesn't mention error cases or what happens if the id is invalid, but given the simplicity, this is acceptable. A 4 is appropriate; it could be a 5 if it mentioned that omitting id returns all programmes, but the description already implies that with 'or all'.

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

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

The schema covers 100% of the parameter, including examples and a clear note that it's a programme id, not a country name or website slug. The description reinforces the parameter by saying 'by id or all', which clarifies that id is optional. Since schema coverage is high, the description adds value by explaining the 'all' behavior, but the schema already has examples. Baseline is 3, and the description's clarification of the optionality and the 'or all' case earns a 4.

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

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

The description clearly states the tool returns processing-time estimates, for either a single programme (by id) or all programmes. The verb 'get' and the resource 'processing times' are specific, and it differentiates from siblings like estimate_timeline and get_programme which likely cover different aspects. The phrase 'or all' clarifies the optional id parameter.

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 implicitly indicates when to use it: when processing-time estimates are needed, for one programme or all. It doesn't explicitly name alternatives or when not to use, but given the sibling list includes estimate_timeline and get_programme, the description could be clearer. However, the context of a single id from list_programmes provides enough guidance for most cases. I would have liked an explicit note about using estimate_timeline for broader timeline estimation.

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

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

Annotations already mark this as read-only and non-destructive, so the description does not need to restate safety. It adds useful behavioral context by specifying the exact substance of the lookup and the identifier format. No error behavior is discussed, but with an output schema and read-only annotation, the disclosure is adequate.

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

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

The description is one dense, front-loaded sentence that immediately identifies the tool's purpose before listing the contained data. Every phrase adds information, and the examples are useful without being verbose.

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

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

With one well-documented parameter, a read-only annotation, and an output schema present, the description covers everything an agent needs to select and invoke the tool correctly. It explains what will be retrieved and how to supply the id.

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

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

Schema description coverage is 100%: the schema already documents the id parameter with examples and an explanatory note that it is not a country name or website slug. The main description repeats the examples but adds little meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Full detail for one programme by id', immediately distinguishing it from list_programmes and compare_programmes. It also enumerates what 'full detail' includes (routes, fees, processing, mobility, tax, path to citizenship, Mirabello score), so the agent knows exactly what this tool returns.

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

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

The description clearly implies when to use it: when a known programme id exists and full detail for that single programme is needed. The input schema reinforces this by saying the id is 'as returned by list_programmes', which gives a helpful prerequisite. It does not explicitly name alternatives or exclusions, but the single-programme-by-id framing provides clear context.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the read-only safety profile is covered. The description adds valuable context beyond annotations: data is 'indicative' and must be verified with Mirabello, and documents such as brochure and due-diligence pack are not returned by the tool but must be requested separately.

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 with no filler: the first front-loads the core purpose and content fields, and the second adds the broker-of-record and verification caveat. Every clause contributes meaningful information for invoking the tool correctly.

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

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

For a read-only single-parameter lookup with a full output schema, this description is complete. It covers what data is included, acknowledges missing-data cases ('where disclosed'), and warns that values are indicative and require verification with the broker.

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 required parameter slug is already well documented in the schema. The description only repeats that lookup is by slug and adds no new meaning or constraints 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 and resource: 'Full detail for one investment property by slug', and enumerates the exact data domains returned (price, specs, location, programme, developer, availability, freshness). This clearly distinguishes it from sibling get_* tools like get_property_law or get_programme, and from search_properties which returns listings rather than one property.

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 slug parameter is defined as 'exactly as returned by search_properties', which strongly implies the tool is meant to be used after a search to retrieve full detail for a chosen listing. There is no explicit mention of alternatives or exclusions, but the 'one investment property by slug' scoping gives clear usage context.

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

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

Beyond the readOnlyHint annotation, the description discloses useful behavioral nuances: federal states are flagged subnational, no country-wide answer is inferred, rules change without notice, conveyancing runs through licensed local professionals, and the output is information rather than legal/tax/investment advice. This significantly enriches what the annotations alone convey.

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

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

The description is dense and long, but nearly every clause adds a distinct legal dimension, usage caveat, or scope clarification. Scope is front-loaded in the first line, and the final disclaimers earn their place given the legal nature of the tool.

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