mcp-server

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

The description clarifies that the tool delivers the enquiry to Mirabello and returns a tracked booking URL, adding behavioral context beyond the annotations (readOnlyHint=false implies write, confirmed here). It does not detail error states, rate limits, or side effects, but the core behavior is transparent.

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 concise sentences: purpose, requirements, outcome. No unnecessary words, and the most important information (purpose and required fields) appears first.

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 20 parameters and no output schema, the description covers the essential input (email, programme interest, consent) and output (tracked URL). It lacks details on error handling or asynchronous behavior, but it is fairly complete for a booking 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 95%, high, so the baseline is 3. The description does not add new parameter meaning beyond what the schema already provides, merely restating requirements. No improvement over schema.

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

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

The description clearly states the action (book a consultation), target (Mirabello Consultancy), and key outcomes (deliver enquiry, return tracked URL). It distinguishes itself from sibling tools, which focus on eligibility, comparisons, and estimates.

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), providing clear context for when to use the tool. However, it does not explicitly state when not to use it or suggest alternative tools, though the sibling list makes the intended use 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 set readOnlyHint=true, and the description reinforces this with 'never asserts a case is compliant'. It adds behavioral details: grounded in FATF/Wolfsberg standards, returns core+collateral documents, context overlay, and red flags.

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 focused paragraph with the main purpose upfront, examples, and a clear informational note. It is efficient and contains no redundancy, though bullet points could marginally improve readability.

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

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

Given no output schema and low parameter coverage, the description effectively covers the tool's purpose, input suggestions, output components, standards basis, and limitation. It is sufficiently complete for an agent to use correctly.

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

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

Schema coverage is 0% (no descriptions for parameters), but the description provides concrete examples for 'origin' and 'context', and instructs calling with no args for full list. This adds meaning beyond the bare schema types, though lacks complete enumeration.

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 documentary evidence for Source-of-Wealth/ Source-of-Funds based on origin type and optional context. It distinguishes itself from siblings by being specific about SoW/SoF compliance documentation.

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 the informational nature ('INFORMATION ONLY') and advises calling with no args to list options. It implicitly guides usage for selecting origin and context, but doesn't explicitly exclude alternative tools or conditions.

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. Description adds that it only reflects published policies and that final acceptance rests with government due diligence, providing important limitations about the tool's scope and non-definitive 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?

Two sentences with no wasted words. The key action and scope are in the first sentence, with an important caveat in the second. Highly 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 no output schema, the description explains the tool's purpose and limitations well. It could be improved by hinting at the output format (e.g., list of programmes), but the core context for decision-making is present.

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

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

Schema covers all 3 parameters with descriptions (100% coverage). The description mentions nationality and programmes but does not add significant detail beyond the schema. Baseline 3 is appropriate.

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

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

Description explicitly states the tool 'checks which programmes a given nationality can realistically apply to', listing specific aspects like nationality restrictions, EU-citizen applicability, and age requirements. It clearly distinguishes from sibling tools like check_visa_free or recommend_programmes by focusing on eligibility filtering.

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

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

The description implies when to use (for eligibility based on nationality) but does not explicitly state alternatives or when not to use. The context about factual policies and final government due diligence sets expectations, but no direct comparison to siblings.

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

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

Annotations already declare readOnlyHint=true. The description adds context on specific outputs (visa-free count, Henley rank, key destinations) without contradicting annotations. It sufficiently discloses behavioral traits beyond annotations.

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

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

The description is a single, efficient sentence that front-loads the main purpose with zero waste. 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 simple query tool with 2 parameters, no output schema, and read-only annotations, the description covers purpose and key outputs. It does not detail return format but is reasonably complete.

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

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

Schema coverage is 50% (only destination has description). The description mentions key destinations (Schengen, UK, USA, China), adding meaning to the destination parameter, but does not explain programme_id. It partially compensates for missing schema descriptions.

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

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

The description clearly states the tool provides visa-free count, Henley rank, and access to key destinations for a programme passport. It uses a specific verb ('check') and resource, effectively distinguishing it from siblings like check_eligibility or get_programme.

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. The description implies its use for checking visa-free access details but lacks when-not or direct comparisons to siblings.

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

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

Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds the specific comparison attributes but does not disclose any other behavioral traits (e.g., data source, performance, error handling). With annotations covering safety, a 3 is appropriate.

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 sentence, front-loaded with the key action and resource, and lists specific comparison dimensions. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description covers the essential functionality and scope. It does not mention return format or error handling, but given the simplicity, it is sufficiently 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?

The only parameter 'ids' is described implicitly as '2–4 programmes'. Schema description coverage is 0%, so the description must compensate. It adds meaning (what the array represents) but lacks details on format (e.g., programme IDs vs names). This is adequate but not thorough.

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 purpose: compare 2–4 programmes side by side, listing specific attributes (cost, processing, mobility, family inclusion, tax, path to citizenship). This differentiates it from siblings like list_programmes (listing only) or recommend_programmes (recommendation).

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

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

The description implies when to use this tool: when a side-by-side comparison of multiple programmes is needed. It does not explicitly state when not to use or mention alternatives, but the listed attributes and sibling names provide enough 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 set readOnlyHint=true, and description reinforces it as 'Informational only, not advice.' Adds context about the synthesis view across layers (tax, residence, structure, reporting, succession) and the scope of the comparison.

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 well-structured and front-loaded with the core purpose, but slightly verbose with detailed enumeration of dimensions. Every sentence adds value, but could be trimmed slightly.

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

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

Given the complexity of the tool and no output schema, the description covers purpose, parameters, usage tips, and relationships to siblings. Lacks details on output format, but the synthesis nature is implied.

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 has 0% description coverage, but the description fully explains both parameters: cc as a comma list and scenarios as an array with cc and pathway. Provides examples of acceptable formats and clarifies that no parameters are required.

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 it performs a side-by-side comparison of jurisdictions across multiple wealth-protection dimensions. It differentiates from sibling tools like compare_treaty_position and 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?

Explicitly tells when to use (comparing up to 8 jurisdictions) and what not to use (informational only, not advice). Prescribes pairing with get_country/find_pathways and compare_treaty_position for specific 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?

The description complements the readOnlyHint annotation by disclosing that the tool is 'indicative, not advice' and lists the specific checks performed. 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, well-structured sentence that front-loads the main purpose, followed by a brief usage note. No redundant information.

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

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

With no output schema, the description fully explains what the tool returns: DTA status, tie-breaker, withholding rates, and limitation-of-benefits tests. The input requirements are 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?

Despite 0% schema description coverage, the description explicitly states that 'from' and 'to' are ISO alpha-2 codes for the relocation corridor, adding crucial meaning beyond the raw schema.

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

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

The description clearly states the tool's purpose: providing double-tax-treaty position for a relocation corridor, including DTA in force, residence tie-breaker, withholding rates, and limitation-on-benefits tests. It specifies ISO alpha-2 codes, distinguishing it from siblings like 'withholding_map' or 'get_country_tax'.

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

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

The description instructs to use ISO alpha-2 codes and notes the output is indicative, not advice. While it does not explicitly mention when to use this tool over siblings, the detailed output description implies its use case for treaty analysis between two countries.

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 adds valuable context: the tool is stateless, accepts only non-identifying flags, and is informational with a disclaimer. This fully discloses behavior and limitations.

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: two sentences cover purpose, flags, statelessness, and legal disclaimer. No redundant information; 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?

Given the tool's complexity (10 boolean flags, no output schema), the description adequately covers purpose, parameter usage, and limitations. It could mention the output format (list of obligations) but is otherwise complete for an informational 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?

The input schema has 10 boolean parameters with 0% description coverage. The description lists 8 of them by name, grouping them as relevant flags. Although it doesn't define each individually, the names are self-explanatory and the listing provides context. Some parameters (rbi_applicant, eu_cross_border_arrangement) are missing, but overall adds 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 tool's purpose: 'Lists the reporting/compliance obligations a stated profile may trigger' and enumerates specific regulations (FATCA, CRS, etc.). It distinguishes from siblings like check_eligibility by focusing on compliance obligations triggered by boolean flags.

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: it is informational, not legal/tax advice, and not exhaustive. It also instructs to pass only non-identifying flags and never personal data. However, it does not explicitly mention when to use this tool over alternatives like check_eligibility.

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 indicate a non-read-only operation, and the description confirms it delivers the enquiry and returns a next step. It adds GDPR context and consent requirement, providing behavioral clarity 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 sentences, front-loaded with purpose, followed by key requirements and context. No wasteful words, each sentence contributes essential 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?

The description covers core functionality and required parameters but omits details on return values ('next step' is vague) and does not explain optional parameters. For a tool with 11 parameters, more context is needed.

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 only 18%; the description adds meaning to property_id (slug) and consent (GDPR) but fails to clarify the other 8 optional parameters (e.g., name, phone, budget). With low coverage, the description should supply more parameter guidance.

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 action (route a qualified buyer enquiry), the resource (a specific property), and the recipient (Mirabello Consultancy). It distinguishes itself from sibling tools like book_consultation by explicitly stating this is the correct hand-off for CBI/RBI purchases.

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 required inputs (property_id, email, consent) and when to use (qualified buyer enquiry for property purchase). It does not explicitly list when not to use, but implies this is the specific tool for hand-off to a licensed advisor.

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 confirm read-only behavior. The description adds context about stage breakdown availability, but does not disclose potential error states or data source limitations.

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?

Concise single sentence that front-loads key information. However, the colon usage makes the second part slightly ambiguous.

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 tool with no output schema, the description fails to describe return format, error handling, or the nature of the timeline. Agents lack sufficient context to interpret results.

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

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

With 0% schema coverage, the description does not explain the required programme_id parameter beyond implicit context. No format, examples, or source guidance provided.

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 a step-by-step timeline including processing time and stage breakdown. It effectively communicates the primary 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?

No guidance on when to use this tool versus siblings like get_processing_times. The description lacks differentiation and context for 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. The description adds value by specifying what is included and excluded in the estimate, which is beyond what annotations provide. No contradictions.

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, no wasted words. The first sentence states the core purpose, the second adds essential caveats. Front-loaded and 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?

The tool has 4 parameters and no output schema. The description covers purpose and exclusions but omits return format or behavior when optional parameters are omitted. Adequate but incomplete.

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 only 25% (only adults documented). The description hints at family composition but does not explicitly explain each parameter's meaning or relationship to the cost calculation. More detail needed to compensate for low 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 clearly states the tool estimates total cost of a programme for a family, listing components (investment, fees, add-ons) and exclusions. It distinguishes from siblings like get_programme 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 implies usage for cost estimation by family composition but does not explicitly state when to use this tool versus alternatives. The caveat 'Indicative; excludes professional/property/legal fees' provides context but no direct comparison to siblings.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate that. The description adds context about the tool's focus on philanthropic structures, but does not disclose any additional behavioral traits beyond what annotations provide.

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

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

The description is two sentences long, with the first sentence front-loading the key action and providing rich context. It could be slightly more concise, but it effectively packs information without unnecessary verbosity.

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 two parameters, no output schema, and annotations present, the description adequately explains the tool's purpose and results. It provides enough context for an agent to understand what kind of jurisdictions will be returned and the scope of the tool.

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

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

The input schema has 100% coverage with clear descriptions for both parameters. The description adds some contextual value by mentioning 'donor tax relief' and 'standout vehicle', but does not provide additional semantic meaning beyond what the schema already offers.

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 purpose: to find jurisdictions for setting up charitable/philanthropic structures, with specific examples (foundations, donor-advised funds, etc.). It distinguishes itself from sibling tool 'find_trust_jurisdictions' by focusing on charity/philanthropy rather than general trusts.

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 tool is for philanthropic planning, calling it a 'philanthropy/legacy complement' but does not explicitly state when to use it vs alternatives like 'find_trust_jurisdictions' or other tools. No exclusion or cross-reference is provided.

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

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

Annotations already declare read-only. The description confirms that the tool returns a 'snapshot' of tax/CRS/EU-list/crypto data, adding behavioral context beyond the annotation 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?

A single, front-loaded paragraph that packs all necessary information (criteria, output, pairing advice) without filler or repetition.

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

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

For a boolean-filter list tool with 8 optional params and no output schema, the description covers what the tool returns, usage context, and integration with siblings, leaving little ambiguity.

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 0%, but the description fully explains each boolean parameter's meaning (e.g., 'no personal income tax', 'non-CRS') in plain English, compensating for the schema gap.

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 begins with a specific verb-resource pair ('Find countries by wealth-protection tax criteria') and enumerates distinct tax filters. It also suggests pairing with sibling tools (get_country/find_pathways), differentiating its role.

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 explicit pairing advice for combining tax criteria with residence/citizenship routes, but does not state when to avoid this tool versus alternatives like get_country_tax or compare_programmes.

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 is consistent with the readOnlyHint annotation. It adds 'screened' to describe the output, but does not elaborate on data freshness, authentication needs, or other behavioral traits. With annotations already indicating read-only, the description provides marginal additional 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, front-loading the core purpose and using a parenthetical list for examples. Every word contributes value, and there is no redundancy or unnecessary detail.

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 2 parameters (one required) and no output schema, the description is somewhat incomplete. It does not explain the return format or what 'screened' entails. It also lacks context about supported pathway values or the tool's placement among 18 siblings.

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 has 0% description coverage. The description explains the 'pathway' parameter with examples, but the optional 'region' parameter is not mentioned at all. This leaves a significant gap for agents to understand the full parameter set.

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 action ('Find which countries offer a given immigration pathway') and specifies the resource (countries, pathway). Examples of pathway types (digital-nomad, skilled-work) provide concrete context. It distinguishes itself from siblings like check_eligibility or list_programmes by focusing on country-pathway association.

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 one wants to know which countries have a specific immigration pathway, but lacks explicit guidance on when not to use it or how it relates to alternatives like check_eligibility or get_country. No prerequisites or exclusions are mentioned.

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

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

The description discloses the tool's read-only nature (consistent with readOnlyHint: true) and details what the output includes: ranked jurisdictions with statute, CRS status, and EU-list status. 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?

The description is three sentences, front-loaded with the main purpose, examples, and filter options. Every sentence is meaningful, with no redundancy or wasted words.

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

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

For a simple tool with two optional parameters and no output schema, the description covers the purpose, filters, return content, and contextual positioning among siblings. It is sufficiently 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?

With only 50% schema description coverage, the description compensates by explaining the 'vehicle' and 'strong_protection' filters. It clarifies that 'vehicle' accepts 'trust or foundation' and that 'strong_protection' is a boolean filter, adding value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Find trust & foundation jurisdictions for asset protection and succession planning', with examples of jurisdictions and filters. It distinguishes from siblings like find_charity_jurisdictions and find_low_tax by focusing on asset protection and wealth 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?

It provides guidance on when to use the tool (asset protection and succession planning) and mentions filtering options. It contrasts with residence/citizenship pathways, but does not explicitly exclude alternative tools like find_charity_jurisdictions or find_low_tax.

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, consistent with a non-destructive query. The description adds context about the output being 'indicative, not advice' and explains the depth of information provided. No contradictions.

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 concise sentences: first lists the flags, second explains the depth, third provides usage and disclaimer. No wasted words, front-loaded with key information.

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

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

With a simple string input and no output schema, the description sufficiently covers what the tool does, the input format, and the nature of the output. Some details about return structure are missing but acceptable.

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

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

The single parameter 'cc' lacks schema description, but the description clarifies it expects an ISO alpha-2 country code, providing essential semantic 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 clearly states it provides anti-avoidance and relocation-tax flags for a jurisdiction, listing specific items (CFC, GAAR, POEM, etc.) and indicating it goes beyond headline rates. This distinguishes it from sibling tools like get_country_tax or find_low_tax.

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

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

The description instructs to use ISO alpha-2 country codes and warns that output is indicative, not advice. However, it does not explicitly state when to use this tool versus alternatives, leaving some ambiguity.

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

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

The description adds behavioral context beyond the readOnlyHint annotation by clarifying that the tool states default legal rules and does not predict estate outcomes. It also mentions interactions with trusts/foundations, providing useful transparency about the tool's scope.

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, well-structured sentence that front-loads the key information and lists specifics without unnecessary words. It is concise and 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 simplicity of the tool (one parameter, no output schema), the description provides a comprehensive overview of what the tool returns, including forced heirship existence, reserved shares, free portion, disinheritance, and trust interaction. It is complete for the agent to understand the tool's output.

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 has 0% description coverage, but the description fills this gap by specifying that the parameter 'cc' should be an ISO alpha-2 country code, giving the agent essential semantic information beyond the schema.

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

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

The description clearly states the tool provides the forced heirship and testamentary freedom position for a jurisdiction, listing specific elements like reserved shares, free portion, disinheritance, and trust interaction. It also distinguishes itself by emphasizing it gives default rules, not how an estate will devolve, differentiating it from siblings like succession_conflict_map.

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 on what the tool does and what it does not (default rules, not estate devolution). It also instructs to use ISO alpha-2 for the country code. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, though the differentiation is 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?

Annotations indicate readOnlyHint=false and openWorldHint=true, and the description adds valuable transparency by disclosing optional registration (email + consent) and the 90-day URL validity. This provides behavioral details beyond the annotations, though it could further explain what registration entails (e.g., data storage or email sending).

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 sentence that efficiently conveys the main purpose, key outputs, and optional registration. It is front-loaded and contains no fluff, though it could be slightly restructured for readability.

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

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

Given 14 parameters, no output schema, and annotations indicating side effects, the description provides a reasonable overview but lacks detail on the exact structure of the returned briefing (e.g., fields in the shortlist, cost math format). The URL expiry and registration are covered, but the output shape is left to 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?

Schema coverage is 64%, so the description partially compensates by mentioning key parameters like nationality, budget, family, and goals. However, it does not cover all 14 parameters, leaving out tax_goal, mobility_priority, timeline_max_months, programme_ids, and the honeypot website field. The description adds some meaning but not enough to fully compensate for the missing schema descriptions.

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

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

The description clearly states the tool generates a personalised Mirabello briefing with specific outputs: ranked shortlist, full family cost math, and a shareable branded URL valid 90 days. The verb 'generate' and resource 'briefing' are specific, and the inclusion of optional registration distinguishes it from siblings like recommend_programmes or compare_programmes.

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

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

The description implies the tool is for generating a briefing when a client profile is available, but it does not explicitly state when to use it versus alternatives like check_eligibility or book_consultation. No when-not or alternative guidance is provided, leaving the agent to infer from context.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds no behavioral traits beyond listing content, but since annotations cover the safety profile, no further disclosure is needed.

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 sentence that front-loads key information and ends with usage examples. Every word earns its place with no 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?

For a tool with no parameters and a simple information retrieval function, the description is complete. It covers content and usage context sufficiently.

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

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

There are no parameters, so schema coverage is 100% trivially. The description does not need to add param semantics, as none exist.

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

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

The description clearly states the tool returns information about Mirabello Consultancy, including track record, credentials, offices, languages, and services. It distinguishes from sibling tools like list_programmes by focusing on company reputation rather than specific 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 explicitly specifies when to use the tool: for questions like 'who is Mirabello / why use them / are they reputable'. This provides clear guidance and implies alternatives for other queries.

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. The description adds valuable behavioral context: the tool returns listings that have been re-verified (price/availability/sale status) and optionally filters by ISO date, clarifying the nature of the data beyond a simple read operation.

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 efficient: two sentences, no fluff. The first sentence states what the tool returns and the parameter, the second provides a usage context. 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 simple tool with one optional parameter and no output schema, the description adequately covers what it returns and when to use it. Minor gaps: it does not specify the return format or any limits, but these are not critical for a refresh 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?

The schema already describes the 'since' parameter as an ISO date with high coverage. The description adds the word 'optionally' and repeats the purpose, which adds marginal value but does not significantly enhance understanding beyond the schema.

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

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

The description clearly indicates the tool returns recently re-verified listings with optional date filtering. It distinguishes from siblings like 'get_recent_changes' by focusing on availability updates, but lacks a specific verb like 'Retrieve' or 'Get'.

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 a clear use case: 'for agents keeping an inventory view fresh.' However, it does not specify when not to use this tool or mention alternative tools for similar purposes, leaving some guidance gap.

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 indicate readOnlyHint=true, and the description adds valuable behavioral context by detailing the return content (requirements, cost, processing, rights, path to PR/citizenship, source). 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?

The description is two concise sentences. The first sentence front-loads the tool's purpose and content, and the second provides a usage hint. No wasted words.

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

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

Given no output schema, the description adequately details the types of information returned. With 2 well-documented parameters and clear usage instruction, the description is sufficiently complete for an AI agent to understand the tool's behavior.

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 is 3. The description reinforces the 'cc' parameter with examples and clarifies the scope ('beyond investment migration'), but does not significantly add meaning beyond the schema for the 'pathway' 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 clearly states the tool retrieves a country's immigration profile with all screened pathways, listing specific types (skilled-work, digital-nomad, etc.). It distinguishes itself from sibling tools like get_programme or list_programmes which focus on individual 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 provides explicit guidance on how to specify the country using ISO-3166 alpha-2 code with examples. It implies when to use this tool (full profile) vs siblings (specific programmes), but does not explicitly list alternatives or when not to use.

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, and the description adds 'Informational only' and 'From official/Tier-A sources,' which aligns and provides additional context about data reliability. No contradictions or missing behavioral info.

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 (three sentences) and front-loaded with the main purpose. Every sentence adds value: purpose, specific taxes, source, usage instruction, and disclaimer. No wasted words.

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

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

For a simple read-only tool with one parameter and no output schema, the description covers its purpose, data sources, usage, and limitations. It could mention that it's a summary view, but completeness is high.

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 has one parameter 'cc' with description 'ISO alpha-2 country code.' Schema coverage is 100%, so the description adds no extra semantics beyond reiterating the code usage. Baseline score 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 it provides an HNWI tax profile for a country, listing specific tax types and data sources. It uses a specific verb ('get') and resource ('country_tax'), and the context of 'wealth-protection view' differentiates it from sibling tools like get_country or get_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 instructs to 'Use the ISO alpha-2 code,' which is a clear usage hint. It also notes 'Informational only — not tax advice.' However, it does not explicitly provide when-not-to-use or alternatives. Given the lack of closely related sibling tools, this omission is minor.

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 discloses the read-only nature (consistent with readOnlyHint annotation), cautions that information is not advice and timeliness changes, and explains provenance and low-confidence handling. It adds behavioral context beyond annotations, though could mention rate limits or refresh policies.

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 structured with numbered blocks and front-loaded purpose. It is detailed but not overly verbose; every sentence adds value. Minor redundancy in repeating 'government' in stablecoin item, but overall 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?

The description covers the tool's output comprehensively, including data categories, statuses, regulatory frameworks, provenance, and caveats about low-confidence details. Without an output schema, it provides enough context for an agent to understand what to expect, though pagination or error handling are absent.

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

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

The schema coverage is 0%, but the description explains the 'cc' parameter: pass for a specific jurisdiction, omit for all. This adds meaning to the otherwise undocumented string parameter, but lacks format details (e.g., ISO alpha-2).

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 per-country digital money and identity progress for wealth planning, listing specific data categories (CBDC, stablecoin, digital ID) with statuses and details. It is distinct from sibling tools like get_country or get_country_tax, which cover different domains.

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 indicates usage by passing a country code ('cc') or omitting for all, but does not explicitly state when to use this tool over alternatives or provide exclusions. It gives basic usage context but lacks clear when-not or alternative 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?

Beyond the readOnlyHint annotation, the description adds that the final list is confirmed by a specialist and varies by family composition and nationality, providing useful behavioral context.

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

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

Two concise sentences fully convey the tool's purpose and key nuances without redundancy or unnecessary detail.

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 explains what the tool returns (checklist, programme-specific items, variation factors) but lacks output structure details. Since no output schema exists, more specificity about the return format would improve completeness.

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 has one parameter (programme_id) with 0% description coverage. The description hints at programme type dependency but does not explain the parameter meaning or expected format, failing to compensate for missing schema descriptions.

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

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

The description clearly states it provides a 'Standard document checklist for a programme application', specifies it varies by programme type, family composition, and nationality, and distinctly differs from sibling tools like check_eligibility or estimate_timeline.

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

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

Usage is implied by describing what the tool does ('document checklist for a programme application') but lacks explicit when-to-use, when-not-to-use, or alternative tool references despite 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?

The description adds value beyond the annotations by detailing the ranking methodology, provisional flagging, and exclusion from headline ranking. No contradictions with readOnlyHint=true.

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, with two sentences that front-load the purpose and then provide additional details. Every sentence is informative and efficiently written.

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 no output schema, the description covers key aspects like the ranking nature, filtering options, and handling of provisional programmes. It is sufficiently complete for understanding the tool's function.

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 description mentions filtering by type (CBI/RBI) and limit, adding some semantic context to the input schema. However, it does not specify defaults or whether parameters are required, and with 0% schema coverage, more detail would be beneficial.

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 tool as a composite ranking index for CBI/RBI programmes, specifying the criteria and filtering options. This effectively distinguishes it from sibling tools like list_programmes and 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 does not explicitly state when to use this tool versus alternatives. While it mentions filtering by type and limit, it lacks guidance on scenarios where get_index is preferred over other similar 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 declare readOnlyHint=true, so no safety concerns. The description adds context about the nature of the information (routes, passport reach) and includes disclaimers ('INFORMATION, NOT ADVICE'), going beyond annotations 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 moderately lengthy but every sentence contributes valuable information. It front-loads the core purpose and structures details logically, though some redundancy could be trimmed.

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 no output schema, the description thoroughly explains what is returned (routes with attributes, passport context) and how to use it alongside sibling tools. It covers all necessary aspects for effective tool 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 single parameter 'cc' has no description in the schema (0% coverage), but the description fully explains its meaning: 'Pass cc for one jurisdiction, omit for all.' This adds essential semantic value.

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

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

The description clearly states it provides 'strategic mobility optionality' for a jurisdiction, detailing investment programmes with specific attributes like minimum physical presence, family inclusion, and processing time. It distinguishes itself from passport strength and mentions sibling tools like get_country and find_pathways.

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

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

Explicitly instructs when to use: 'the planning view of mobility, not passport strength' and how: 'Pass cc for one jurisdiction, omit for all.' Also advises pairing with other tools and a consultation, providing 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?

Annotations provide readOnlyHint: true, which the description does not contradict. The description adds that it can return estimates for one or all, but lacks details on behavior (e.g., caching, accuracy, response format).

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

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

Single sentence with no redundancy. Slightly more could be added about the 'all' case, but it is sufficiently 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 simple tool with one optional parameter and no output schema, the description covers the main usage. However, it lacks details on the response structure, which would be helpful given the lack of 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?

With 0% schema description coverage, the description adds meaning by indicating that 'id' selects a specific programme, and omitting it returns estimates for all. However, no format or constraints are given.

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 it returns processing-time estimates for one programme (by id) or all programmes. This distinguishes from siblings like get_programme (programme details) and list_programmes (listing all programmes), but does not explicitly differentiate.

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 guidance on when to use this tool vs alternatives like get_programme or list_programmes. No exclusions or prerequisites mentioned.

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

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

Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds behavioral context by listing the data returned (routes, fees, etc.) but does not mention error handling, id format sensitivity, or rate limits. Adequate but not beyond annotations.

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

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

A single sentence that front-loads the purpose and lists specific content items. Every phrase earns its place; no redundancy or trivial 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?

With one parameter, no output schema, and readOnly annotation, the description sufficiently covers what the tool returns. It lists major output components. Could be slightly improved by noting the output structure, but overall complete for a retrieval 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 has 0% description coverage, but the description fully compensates by providing examples ('dominica-cbi','greece-gv') and explaining the parameter is a programme id. This adds significant meaning beyond the schema's type string.

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 'Full detail for one programme by id', which is a specific verb+resource. It distinguishes from sibling tools like list_programmes and compare_programmes by emphasizing it's for a single programme with comprehensive information.

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 guides use when full detail of a specific programme is needed, but it does not explicitly state when not to use or mention alternatives like check_eligibility or get_processing_times. The purpose is clear enough to infer appropriate usage.

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

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

Annotations declare readOnlyHint=true, and the description adds context: 'Indicative; verify with Mirabello' and notes the broker of record. This provides behavioral nuance beyond the annotation, though no mention of caching or staleness.

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

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

Two sentences, front-loaded with the core purpose and return fields. Every sentence adds value; no fluff. Perfectly 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?

The description covers the tool's return content, the indicative nature, and the alias for further enquiry. Without an output schema, it provides sufficient context for an agent to understand what to expect, though it could mention pagination or error states.

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

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

The single parameter 'slug' has no schema description (0% coverage). The description mentions it's the identifier for the property but adds no further detail on format, source, or how to obtain it. The tool is simple, so baseline 3 is adequate.

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 full details for one investment property by slug, listing specific attributes (price, specs, location, etc.). This distinguishes it from sibling tools like search_properties which likely return multiple properties.

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 requires a slug and mentions that brochures and packs are available via create_enquiry, but does not explicitly state when to use this vs siblings (e.g., search_properties). However, the contrast is clear enough for an agent.

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

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

The description details the return structure comprehensively, including source info, derivation, confidence, temporal fields, and freshness block. This goes well beyond the readOnlyHint annotation, providing full behavioral 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 a single paragraph that is front-loaded with the core purpose. While dense, it efficiently conveys all necessary information without 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 only 2 parameters and no output schema, the description compensates by fully explaining the return fields and their semantics, making the tool's behavior completely predictable.

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

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

Schema coverage is 100% with clear descriptions for both parameters (cc and pathway). The description adds only minimal context ('country's pathway facts') and does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the tool retrieves provenance data for a country's pathway facts, specifying it uses W3C PROV-O and Schema.org standards. It distinguishes itself from siblings by focusing on citation-first source verification, which none of the sibling tool names imply.

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 advises to use this tool for citing Mirabello data with a source and as-of date, and to know when to re-verify. It does not mention when not to use it or provide alternatives, but the purpose is clear and contextually sufficient.

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 (safe read) and openWorldHint=false (complete data). The description adds value by specifying the types of changes included and claiming 'primary-source-verified', which augments the safety profile 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?

Description is moderately concise; two sentences. The first sentence front-loads the main purpose and types, followed by usage guidance. Could be slightly tighter by combining clauses, but 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 no output schema, the description should clarify the return format (e.g., list of objects with fields, counts). It mentions 'current status counts' and change types but not the structure. Adequate but incomplete for a complex query 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 has 2 parameters with 0% description coverage. Description explains 'cc' as a country filter but does not mention 'limit', leaving its purpose (likely pagination) unexplained. Partial compensation for low 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?

Description clearly states the tool retrieves recent material changes across investment-migration programmes, listing three specific types (launches/closures, pathway_field_changes, official_legislation_changes). It distinguishes from sibling tools by emphasizing 'freshest, primary-source-verified record' and targeting 'what changed recently / latest' questions.

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

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

Explicitly says 'use for "what changed recently / latest" questions' and notes the optional cc filter for a single country. Lacks explicit when-not-to-use or alternatives, but the purpose is narrow enough that usage context 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?

The description adds significant behavioral context beyond the readOnlyHint annotation: it emphasizes that the output is 'INFORMATION, NOT ADVICE', includes methodology and a de-risk note, and clarifies there is no composite ranking (weightings depend on client facts). 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 front-loaded with the core purpose and key differentiators. While it is relatively long, every sentence adds value. Minor redundancy ('international compliance alignment — NOT a secrecy score') but overall 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 no output schema, the description thoroughly covers return value content (sub-indices, methodology, de-risk note). Parameter usage is fully explained. The tool's role among siblings (distinct from get_wealth_index) is clear. No gaps for agent decision-making.

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 0% schema description coverage, the description compensates well by explaining the single parameter cc: 'Pass cc for one jurisdiction, omit for all.' This adds meaning beyond the raw schema (which only shows type: string). It could optionally mention the format of cc (e.g., ISO country code), but the usage is clear.

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 per-pillar sub-indices (0-100) for jurisdictions, enumerates the pillars (tax efficiency, structure strength, etc.), and explicitly distinguishes it from the client-weighted composite provided by get_wealth_index. The verb 'get' plus the specific resource 'Wealth-Protection Atlas' makes the purpose 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 provides explicit guidance: when to use this tool (for objective sub-indices) versus get_wealth_index (for client-weighted composite). It also specifies parameter usage: 'Pass cc for one jurisdiction, omit for all.' This clearly tells the agent how and when to invoke the 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 indicate readOnlyHint=true, and the description adds value by stating that the projection is 'pure' over verified data and that the score is 'illustrative' and 'not advice.' This goes beyond the annotation and provides important caveats about the output's 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 well-structured with key information upfront, but it is slightly lengthy. Each sentence adds value, though a minor reduction could improve conciseness without loss.

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

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

Given the tool's complexity (3 params, no output schema), the description adequately covers purpose, parameters, and output nature. However, the lack of explicit return format details leaves a small gap, though the description implies a comparative score.

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 has 0% description coverage, but the description compensates by explaining the meaning of all three parameters: 'cc' for one jurisdiction, 'limit' for top N, and 'weights' as a customizable object with listed keys. It also clarifies behavior when parameters are omitted.

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 purpose: computing a client-weighted wealth-protection composite over Atlas pillars through custom weights. It distinguishes the tool from siblings like get_index by emphasizing that there is no single 'best' ranking, and it specifies the verb 'score 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 provides clear guidance on when to use the tool: to score jurisdictions for a specific client profile with custom weights, or omit weights for a default composite. It covers the usage of each parameter but does not explicitly state when not to use it or name alternatives, though the context and sibling list imply differentiation.

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 indicate read-only, which description supports. Description adds filtering context but not details like pagination or data freshness. No contradictions.

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

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

Single sentence, front-loaded with action, then filter options. No unnecessary words.

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

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

Covers essential usage with optional filters. Does not mention pagination, sorting, or response format, but for a list tool with no required params and no output schema, it is adequate.

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

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

Schema has 0% parameter descriptions; the description maps filter criteria to properties (type, budget to budget_max, etc.), adding meaning. However, it omits specifics like allowed region values.

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 lists programmes with specific filtering options (type, budget, region, max processing time). It uses a specific verb 'List' and identifies the resource as 'programmes', distinguishing it from siblings like get_programme.

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 hints at when to use filters but does not explicitly compare to alternatives or state when not to use this tool. It implies listing use case but lacks explicit 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?

The description adds context that the tool is informational and covers default regimes, but does not expand beyond the readOnlyHint annotation. No contradictions 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 with no fluff. It front-loads the key purpose and includes critical usage guidance (ISO alpha-2) and a disclaimer.

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

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

For a simple informational tool with one parameter and no output schema, the description covers the essential aspects. It could mention what is returned, but the context is adequate.

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

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

The schema has no parameter descriptions (0% coverage), but the description explains that the 'cc' parameter should be an ISO alpha-2 country code, adding essential 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 clearly states it covers default matrimonial-property regimes, including types, variation by agreements, and splits on divorce or death. It distinguishes itself from sibling tools by being informational and jurisdiction-specific.

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 advises to confirm with local counsel and to use ISO alpha-2 codes, providing clear usage context. However, it does not explicitly differentiate from sibling 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 set readOnlyHint=true. The description reinforces this by stating 'Informational only, not advice.' It adds context about the types of considerations included (tax-exit, mobility delta) and that it is generic and sourced, which goes beyond the annotation.

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, including marketing language like 'Mirabello Freedom Compass'. However, it front-loads the core function and provides key details. Nearly every sentence adds value, but it could be trimmed slightly.

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

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

Given the tool's complexity (7 params, nested object, no output schema), the description explains the tool's purpose and output fields (fit_score, mobility_delta, etc.) but lacks explanation of several input parameters and the exact structure of the response. It covers the core use case but misses details needed for full automation.

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

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

Schema coverage is only 29% (2 of 7 params have descriptions). The description clarifies from_citizenship as ISO alpha-2 array and mentions goal, but does not explain family, budget_usd, timeline_months, or physical_presence_tolerance. It partially compensates for the main parameters but leaves others undefined.

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 it is an 'origin-aware migration path planner' that takes citizenship(s), tax residence, and a goal to return ranked options. It specifies the output fields and the usage pattern. This distinguishes it from sibling tools like find_pathways or recommend_programmes by emphasizing origin-awareness and mobility delta.

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 a concrete usage example: 'Use for 'I am a [nationality], I want [goal] — what should I do?''. It implies when this tool is appropriate but does not explicitly mention when not to use it or compare to alternatives among 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 declare readOnlyHint=true, and the description adds valuable context: it is a read operation over a knowledge graph, investment figures are best-effort USD, and it notes 'Information, not advice.' No contradiction.

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

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

Description is comprehensive but front-loaded with purpose. Each sentence adds value, though could be slightly more concise. No wasted words.

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

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

Given 9 parameters and no output schema, the description adequately explains modes, expected results (single entity with neighbours or programmes with country/options/authority/source), and caveats. Missing some details about output structure but sufficient for an agent.

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

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

Despite only 22% schema coverage, the description explains the two modes and defines each filter parameter (type, cc, status, leads_to, bloc, min/max investment) in context. Adds meaning beyond the minimal 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?

Description starts with 'RELATIONAL query over the investment-migration KNOWLEDGE GRAPH' and specifies two modes: by id for single entity+neighbours or by filters for programmes. Clearly distinguishes itself from 'flat tools' by stating it answers complex relational queries.

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 explicit usage context: 'Answers queries the flat tools cannot' with an example (open CBI programmes under $200k). Does not explicitly say when not to use, but the sibling tools list suggests simpler alternatives exist.

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 readOnlyHint=true, and the description adds the behavior 'respects closed/paused programmes', which is beyond annotations. This provides useful context but could mention more about response format or error handling.

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

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

Two concise sentences: first explains action and inputs, second adds a behavioral caveat. No fluff, 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 tool with 6 parameters and no output schema, the description is adequate but incomplete. It doesn't explain the return format (e.g., how reasoning is presented) or edge cases like no matching programmes.

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 0%, but the description lists most parameters (budget, family size, mobility priority, timeline, tax goal) with context, compensating well. However, the 'type' parameter is not described, and boolean meanings are implied but not explicit.

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 purpose: recommend a ranked shortlist of programmes based on client profile inputs. It distinguishes itself from siblings like list_programmes (which merely lists) and compare_programmes (which may not rank for a profile) by emphasizing personalized ranking and reasoning.

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 for personalized recommendations but does not explicitly state when to use this tool versus alternatives like check_visa_free or list_programmes. No direct exclusions or when-not instructions 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 indicate readOnlyHint=true, so no destructive actions. The description adds behavioral context by detailing the content returned (tests, factors, documentary evidence) and clarifying the scope (not a residence determination). This goes beyond the annotation.

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: first describes content thoroughly, second clarifies scope. No redundant words, information is front-loaded and every sentence is essential.

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 one parameter, no output schema, and read-only annotation, the description adequately explains what the tool returns. It could be slightly improved by indicating the output format (e.g., list or structured data), but it is sufficient for an agent to understand the tool's purpose.

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 parameter 'cc' has no description and 0% coverage. The description adds the critical detail 'Use ISO alpha-2', specifying the format and purpose of the parameter. It fully compensates for the lack of schema description.

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

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

The description clearly states the tool returns tax-residence tests and evidence factors for a jurisdiction, listing specific content like day-count thresholds and connecting factors. It distinguishes from siblings by explicitly stating it is NOT a residence determination, and specifies input as ISO alpha-2 country code.

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 on when to use the tool by stating 'Tests and factors only — NOT a residence determination', which helps exclude use for determination tasks. However, it does not explicitly name alternative tools for determination, so guidance on when not to use is implied rather than stated.

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

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

Beyond readOnlyHint, the description reveals that returns include pricing, programme, availability, and enquiry route; also notes no direct developer contact, indicative figures, and broker role. Adds significant 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?

Three information-dense sentences: purpose, filters, return content. No wasted words, good front-loading.

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?

Covers purpose, inputs, outputs, and business context (Mirabello as broker). Without output schema, description still gives clear return expectations.

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 only 13% schema coverage, the description adds meaning for many parameters: lists filters, example values (programmes, listing types, sale_status), and explains budget_max as best-effort FX. Misses limit 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 clearly states that the tool searches for Mirabello-advised investment real estate qualifying for citizenship/residency programmes, with specific filters. It distinguishes from siblings like get_property by focusing on qualifying properties and listing filters.

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 implies when to use: to find qualifying properties and mentions that after finding, route buyers via create_enquiry. It does not explicitly list alternatives or when not to use, but context 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?

The description adds significant behavioral context beyond readOnlyHint=false and openWorldHint=true: it mentions that alerts are verified, that consent is required (GDPR), that website is a spam honeypot, and that it returns a subscription id and unsubscribe URL. This is valuable for a mutation tool.

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

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

Two sentences that are information-dense and well-structured. The most important info (what it does and key parameters) comes first, and every phrase 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?

The description covers all 5 parameters, explains return values (subscription id and unsubscribe URL), and mentions consent and spam protection. No apparent gaps for a tool with no 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?

With 100% schema coverage, the description still adds crucial meaning: it explains the email vs webhook_url choice, that consent must be true when email is provided, and that website is a honeypot to leave blank. This goes beyond the schema's basic 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 'Subscribe to verified programme-change alerts' with specific change types (price changes, launches, corrections) and distinguishes it from sibling tools like get_recent_changes. The verb 'subscribe' with resource 'programme-change alerts' is specific and 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 provides explicit guidance for both agent and human users: agents should provide webhook_url, humans must provide email with explicit consent, and the optional programme_ids filter is mentioned. It clearly differentiates between two usage modes.

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, so the description adds 'Informational, not advice' to clarify no advisory output. This is relevant context beyond annotations, though no further behavioral traits (e.g., error behavior, data sources) are disclosed.

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 sentence that front-loads the purpose and lists covered topics. While informative, it is somewhat dense with multiple clauses; a slight restructuring could improve readability, but it remains 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?

For a complex tool with no output schema, the description covers key aspects of what the tool returns (governing law, regulation, professio juris, clawback, trust interaction, planning point). It is sufficiently complete for the tool's scope, though output format is not described.

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 sole parameter 'cc' has 0% schema description coverage, but the description adds critical instruction: 'Use ISO alpha-2.' This tells the agent the expected format, which is essential for correct invocation.

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 the exact purpose: mapping cross-border succession conflict-of-laws for a jurisdiction. It lists specific topics covered (governing law, EU regulation, professio juris, clawback, trust interaction, planning points), distinguishing it from sibling tools like forced_heirship_risk 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 description implies use for obtaining conflict-of-laws positions but does not explicitly state when to use or avoid this tool versus alternatives. It mentions 'Informational, not advice' but lacks guidance on prerequisites or comparisons to siblings.

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

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

Annotations declare readOnlyHint: true; the description does not contradict this. It adds context about the nature of the data (treaty rates for specific income types) but does not disclose other behavioral traits like required country code format or whether historical rates are included.

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

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

One sentence, front-loaded with key information. Efficient but could benefit from brief structure (e.g., listing income types). No wasted words.

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

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

Without output schema and with 0% parameter coverage, the description should provide more context on what the tool returns (e.g., a single rate or a map of rates, response structure). It is incomplete for a meaningful agent invocation.

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

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

Schema coverage is 0% - no parameter descriptions. The description implies 'from' and 'to' are countries/corridors, but does not specify allowed values or format. This adds minimal 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 specifies 'treaty withholding-tax rates' for dividends, interest, royalties, and mentions 'from→to corridor', clearly indicating it returns rates for a specific country pair and income type. It distinguishes from siblings like 'compare_treaty_position' but could be more explicit about the output format.

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 guidance on when to use this tool versus siblings such as 'compare_treaty_position' or 'get_country_tax'. No mention of prerequisites, limitations, or alternative tools.

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