mcp-server

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds meaningful behavioral context: it delivers the enquiry externally to Mirabello and returns a tracked booking URL. It also highlights the consent requirement, which is critical for a GDPR-related action. 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 three short sentences, front-loaded with the purpose, and every sentence adds value: purpose, prerequisites, and outcome. No fluff 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?

Given the output schema exists and the schema covers 95% of parameters, the description is complete enough for a booking tool. It covers the key behavior (deliver + return URL) and the consent gate. It does not discuss alternatives, but the tool's unique action is clear.

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

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

Schema description coverage is 95%, so the schema already documents most parameters. The description adds value by emphasizing the three essential parameters (email, programme interest/message, consent) and their role in enabling the booking, which guides the agent on what to prioritize.

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

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

The description states a specific verb ('Book') and resource ('free consultation with Mirabello Consultancy'), making the tool's purpose unambiguous. It also distinguishes from siblings like create_enquiry by specifying the free consultation nature and the tracked booking URL outcome.

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

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

The description clearly states prerequisites ('Requires email + programme interest/message and explicit consent'), which tells the agent what must be present before invoking the tool. It does not explicitly name alternative tools, but the context is sufficient for a distinct action.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false; the description reinforces this by stating 'INFORMATION ONLY — lists the evidence usually required, never asserts a case is compliant.' It also clarifies the tool's grounding in FATF/Wolfsberg standards, adding behavioral context beyond the annotations.

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

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

The description is concise though dense, with each clause serving a purpose: purpose, inputs, outputs, source of truth, information-only caveat, and no-arg discovery. No redundant sentences are present.

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

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

The description covers input parameters, output structure (core, corroborating, overlay, red flags), and usage caveats, while the presence of an output schema (unshown) reduces the need to detail all return fields. It is self-contained and should enable an agent to call the tool correctly.

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

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

With schema description coverage at 0%, the description carries the full burden for documenting both parameters. It explains 'origin' with six concrete examples and 'context' with four concrete examples, and instructs the caller to invoke with no args to see the full list, effectively compensating for the sparse schema.

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

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

The description opens with a specific action ('Source-of-Wealth / Source-of-Funds evidence pack') and explicitly lists input types (origin, context) and output (core + corroborating documents, context overlay, red flags). It distinguishes itself from generic document checklists by its focus on SoW/SoF evidence across multiple contexts.

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

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

The description gives clear usage context by enumerating supported origin types and destination contexts, and explicitly states how to discover valid values ('Call with no args to list available origins and contexts'). It also sets expectations for informational use, but does not name alternative sibling tools or explicit when-not-to-use 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 mark the tool as read-only and non-destructive. The description adds valuable context by stating it only reflects published policies and that final acceptance rests with government due diligence, giving the agent a clear limitation. It also specifies exactly what checks are performed.

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: the first front-loads the core function and factors, the second adds an important caveat. Every word contributes; no redundancy or filler.

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

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

For a read-only tool with full schema coverage and an output schema, the description sufficiently conveys purpose, data scope, and limitations. It lacks only an explicit mention of the optional type/programme_id filters, but those are well-documented in the schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific syntax or details beyond the schema, though it frames nationality as the key input. It mentions restrictions like Russia/Belarus/Iran which gives some context to the nationality 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?

Description clearly states a specific verb ('Check'), resource ('programmes'), and scope ('given nationality'), enumerating the exact eligibility factors (nationality restrictions, EU-citizen applicability, minimum age, core requirements). This distinguishes it from sibling tools like check_visa_free 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?

Provides clear context for when to use the tool (when checking programme eligibility for a specific nationality). However, it does not explicitly name alternatives or exclusion criteria, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about what is checked (visa-free count, rank, destination-specific access) and the key destination examples, which helps set expectations beyond annotations. It doesn't describe response format, but output schema exists, so the burden is lower.

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 core concept ('Mobile for a programme passport') and lists key outputs. It is concise and every part contributes meaning, though the phrasing 'Mobility for a programme passport' is slightly awkward and could be more direct. No waste, but not maximally clear.

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 is a simple read-only query with two parameters and an output schema, the description covers the essential aspects: what is queried (visa-free access), the scope (key destinations), and the nature of outputs (count, rank). It does not explain the concept of 'programme passport' or provide usage scenarios, but for a tool of this complexity with structural safeguards, it 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 description coverage is 50%, with the 'destination' parameter already described as optional and listing example values. The description reinforces the destinations (Schengen, UK, USA, China) and adds the notion of visa-free count/rank, which indirectly clarifies the return context. However, the 'programme_id' parameter is not elaborated, and the description doesn't explain relationship between parameters beyond this, so it adds only marginal value over 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 checks visa-free access for a programme passport, specifying the exact outputs: visa-free count, mobility rank, and access to key destinations. It distinguishes itself from siblings like get_entry_requirements or get_mobility_optionality by listing these data points. However, it lacks a direct verb like 'check' or 'retrieve', relying on the title for that, so it's not a perfect 5.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or refer to sibling tools. The description simply states what it does, leaving the agent to infer usage context from the tool name and title.

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

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

The description goes far beyond the readOnlyHint annotation by detailing substantive behavioral traits: it cites specific regulations (EU Succession Regulation 650/2012, Rome III, Swiss PILA), discloses hard timing rules (no retrospective cure, Swiss professio juris void if Swiss nationality later acquired), and explains the trade-off between fixed reserved shares and discretionary family-provision claims. It also includes operational caveats: statelessness, no personal data, and no legal advice. No contradiction with annotations.

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

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

The description is dense and front-loaded with the core question, using semicolons to pack extensive legal detail into a single paragraph. Each clause adds useful information, but the length is substantial due to citations and disclaimers. It is well-structured but could be considered slightly verbose for a tool description.

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 (multiple legal instruments, timing rules, situs overrides, trade-offs), the description is remarkably thorough. It explains the default rules, available elections, timing constraints, the no-useful-election outcome, and the warning that nationality alone achieves nothing. The output schema likely formalizes the return structure, but the description already provides a complete mental model with no significant omissions.

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 60%, so some parameters lack descriptions (married, spouse_nationalities). The description adds meaning by explicitly listing required inputs (nationalities, habitual residence, asset situs, marital status) and imposing the constraint 'pass ISO alpha-2 codes only, never personal data,' which clarifies the expected format. However, it does not specifically elaborate on the spouse_nationalities or married boolean, leaving a minor 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 clearly states the tool's function: determining which law may govern cross-border succession, matrimonial property, and divorce, and whether nationality opens an election. It specifies inputs (nationalities, habitual residence, asset situs, marital status) and outputs (default law, instruments, elections, timing rules, situs overrides). This distinguishes it from sibling tools like succession_conflict_map or matrimonial_regime_screen by covering multiple legal areas and the election trade-off.

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 for analyzing cross-border family situations with the given nationality, residence, asset, and marital status data. It also states that it returns a no-useful-election result when nationality opens nothing, implying the tool is appropriate when an election may be possible. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses that the tool returns comparative facts only and does not provide advice, limiting its scope. The 'information, not advice' disclaimer and the list of comparison dimensions give substantial behavioral context beyond safety hints.

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

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

Three sentences with no wasted words: the first front-loads the purpose and scope, the second gives the input format with an example, and the third sets expectations. The structure is logical and compact.

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 a single parameter, an output schema, and read-only annotations, the description covers purpose, input format, comparison scope, and a behavioral caveat. It is complete for an agent to decide when and how to invoke it, even among many sibling tools.

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

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

The input schema's 100% coverage already documents the 'structures' parameter as an array of profile keys with constraints. The description adds a concrete example (['us-llc-wy','ae-freezone','ee-ou']) and clarifies that these keys represent formation structures to be compared across the listed dimensions, enriching the schema definition.

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

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

The description clearly states a side-by-side comparison of 2-6 formation structures across specific dimensions (tax position, costs, timeline, etc.). It distinguishes from sibling compare tools by focusing on formation structures and listing concrete comparison fields.

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

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

It gives clear context for when to use: when comparing formation structures side-by-side. It provides input format guidance and a caveat that it provides information, not advice, implying it's not for final decision-making. However, it does not explicitly name alternative tools for other comparison types (e.g., programmes or treaty positions).

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by listing the exact return components (rank, composite, dimension scores, per-dimension deltas, per-metric leads, human compare page URL) and the classic mode's fields. It does not contradict annotations and adds value beyond the structured hints.

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-loaded with the core purpose, and packs a large amount of useful detail without redundancy. Each clause earns its place: it explains both modes, the output components, and the range of ids. No 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?

Given the tool's moderate complexity (two distinct usage modes, different output shapes) and the presence of an output schema, the description sufficiently covers the key decision points: which parameters to pass and what to expect in return. It could mention that the 'canonical versioned' differs from 'classic' in versioning, but it clearly enumerates the contents of each mode, making it complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so parameters are already documented. The description elevates this by explaining the semantic distinction between a/b and ids: a/b is for the 'canonical versioned comparison artefact' while ids enables a 'classic multi-column comparison'. This goes beyond the schema's generic descriptions and gives the agent deeper understanding of mode-dependent behavior.

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

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

The description opens with a specific verb and resource: 'Compare programmes side by side.' It then distinguishes two comparison modes (canonical two-programme vs. classic multi-column), which clearly differentiates this tool from sibling comparison tools like compare_formation and compare_scenarios that target other entities. The purpose is 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 explicitly tells the agent when to use each parameter set: 'Pass a + b' for the canonical artefact, or 'pass ids (2-4)' for the classic comparison. It also states what each mode returns. It does not name sibling tools as alternatives, but the mode-specific guidance makes usage conditions clear. Slight deduction for not explicitly saying when not to use 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 already mark readOnlyHint=true and destructiveHint=false, so the description's job is to add context beyond safety. It adds significant behavioral context: 'Informational only, not advice' and notes that the tool is a synthesis over multiple layers. It also implies the output is a comparison summary, and mentions the need to combine with other data for a full picture, which sets expectations on 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 dense but front-loaded with the core purpose, followed by input format and usage caveats. No filler sentences; each clause adds value. It is slightly long but appropriately so for a comprehensive comparison tool.

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

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

Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: purpose, input format, jurisdiction limits, and informational nature. It lacks an explicit definition of 'pathway' and does not list the exact dimensions in a structured form, but overall is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It does: 'Pass scenarios as an array of {cc,pathway} or cc as a comma list (e.g. AE,PT,SG)' clarifies both the `cc` and `scenarios` parameters, including type and examples. It does not define 'pathway' but provides enough context for a user to infer its role.

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 performs side-by-side comparisons of 2-8 jurisdictions across specific wealth-protection dimensions (tax, crypto, residence, structure, reporting, succession). It distinguishes from sibling tools like compare_formation or compare_treaty_position by covering multiple layers at once and being described as a 'synthesis view'.

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 usage context: input format (array of {cc,pathway} or comma list), a jurisdiction count limit (2-8), and caveats ('Informational only, not advice'). It suggests combining with an immigration route and double-tax-treaty corridor for the full picture, but does not explicitly name alternative tools or state when not to use this one.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it lists the treaty-relevant elements evaluated (DTA, tie-breaker, withholding rates, LOB/PPT) and the 'Indicative, not advice' caveat, which clarifies the tool's non-authoritative nature. This goes beyond annotations without contradicting them.

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

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

The description is compact and front-loaded: it opens with the core function, then enumerates specifics, and ends with two short imperative/caveat sentences. No fluff—every sentence adds unique value (function, input format, 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?

Given the output schema exists (so return values are specified elsewhere), the description covers the essential decision factors: what the tool evaluates, the input format, and its indicative nature. It also differentiates from siblings. For a read-only comparison tool, this is sufficiently complete for an agent to select and invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does: 'relocation corridor (from→to)' clarifies the directional meaning of both parameters, and 'Use ISO alpha-2 codes' specifies the required format. This gives agents enough to construct valid invocations, though it could be more explicit about which code goes in which 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 precisely states the tool's function: 'Double-tax-treaty position for a relocation corridor (from→to)' and enumerates the specific checks it performs (DTA in force, residence tie-breaker, withholding rates, limitation-on-benefits/PPT). This clearly distinguishes it from sibling tools like get_country_tax (single country) or withholding_map (map-only), using a specific verb-like resource framing.

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?

Clear context is provided: use for a relocation corridor between two countries, with ISO alpha-2 codes. It does not explicitly mention alternatives or when-not-to-use, but the corridor-specific framing implies the tool is for cross-border comparisons, setting it apart from single-country tools. No exclusions are stated, so a 4 is appropriate.

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 'STATELESS — pass only non-identifying flags, never personal data' and 'Informational only, not legal/tax advice, not exhaustive.' These go beyond the annotations (readOnlyHint, destructiveHint) by clarifying data handling and the tool's scope, which is valuable context. 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 long sentence but every clause contributes value: examples of obligations, flag list, stateless warning, and disclaimer. It is front-loaded with the main action. Could be split into two sentences for easier scanning, but 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 the output schema exists and annotations cover safety, the description provides sufficient context for a stateless informational tool. It fully explains the purpose, input flags (mostly), and key limitations. The only gap is the two unmentioned parameters, but overall it is complete enough for an agent to select and invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It maps 8 of 10 flags to specific obligations (e.g., us_person→FATCA, crypto_holder→CARF/DAC8), adding meaning beyond bare property names. However, it omits rbi_applicant and eu_cross_border_arrangement, leaving those parameters unexplained.

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

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

The description uses a specific verb ('Lists') and resource ('reporting/compliance obligations'), and enumerates concrete categories like FATCA, CRS, CARF/DAC8, DAC6, PEP, etc. This clearly distinguishes it from sibling tools such as get_document_checklist or residence_evidence_checklist, which focus on other aspects.

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: pass boolean flags and the tool lists triggered obligations. The 'Informational only' disclaimer sets a boundary, but there is no explicit when-to-use vs. alternatives or when-not-to-use. No exclusion criteria or sibling comparisons are 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?

It discloses that the tool 'Delivers the enquiry to Mirabello and returns the next step,' which goes beyond the annotations. It also explains the GDPR consent requirement and the broker relationship, adding meaningful behavioral context.

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

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

The description is three concise sentences: action, requirements, and rationale. Every sentence 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?

It covers the core purpose, required inputs, the external hand-off, and the regulatory reason. With an output schema present, return values are handled. The optional parameters are not described, but the essential context is complete.

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

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

Schema description coverage is only 18%, covering property_id and consent. The description repeats these and adds 'valid email', but does not explain the other 8 optional parameters. It adds value for required params but leaves the rest undocumented.

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

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

The description states a specific action ('Route a qualified buyer enquiry about a specific property to Mirabello Consultancy') with a clear resource. It distinguishes itself by explaining this is the correct hand-off for CBI/RBI purchases, setting it apart from other enquiry-related tools.

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

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

The description provides explicit context: 'This is the correct hand-off: CBI/RBI purchases must go through a licensed advisor' and lists required preconditions (property_id, email, consent). It doesn't name alternatives or when-not-to-use, but the usage scenario is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context that the timeline includes published processing time and a stage breakdown 'where available', hinting that stage data may be incomplete. However, it does not disclose data sources, freshness, or potential error conditions.

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

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

The description is a single, front-loaded sentence that clearly communicates the tool's output. No filler or 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?

For a simple one-parameter, read-only tool with an output schema, the description is sufficient to convey the core functionality. The phrase 'where available' acknowledges potential data gaps. However, the relationship to get_processing_times is not clarified, but that is more relevant to usage guidelines than 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?

The input schema has no description for programme_id, and the description only indirectly references it as 'for a programme'. This provides minimal semantic grounding, but it does not explain the identifier's format, source, or how to obtain it. With 0% schema coverage, more parameter detail is expected.

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 producing a step-by-step expected timeline for a programme, including published processing time and stage breakdown. This scope distinguishes it from sibling tools like get_processing_times, which focus only on processing times, and get_programme, which provides general programme details.

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 when a user needs a timeline estimate for a programme, but it does not explicitly state when to prefer this tool over alternatives such as get_processing_times. No exclusions or specific use-case guidance 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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context by specifying the cost breakdown and explicitly stating 'Indicative; excludes professional/property/legal fees,' which informs the agent about the estimate's nature and boundaries 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 a single, well-structured sentence that front-loads the core purpose and then provides details on inclusions and exclusions. Every word adds value; there is no redundancy or padding.

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

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

With an output schema present, return values are covered. The description adds crucial context about what the estimate includes and excludes, which is essential for setting expectations. However, the family parameters remain ambiguous, preventing a perfect score. Overall, the description, combined with annotations and output schema, is fairly complete for a cost-estimation 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 low (25%), with only 'adults' having a description. The tool description mentions 'family add-ons' but does not explain how the children parameters (children_16plus, children_under16) affect the estimate or how programme_id is used. This leaves most parameters underspecified, and the description does not compensate 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 clearly states the tool's purpose: 'Estimate the total cost of a programme for a given family' and enumerates the components (investment, fees, family add-ons). It is specific in verb, resource, and scope, but does not explicitly differentiate it from sibling tools like estimate_timeline or compare_programmes, so it falls short of a 5.

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

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

The description implies usage context (when you need a family cost estimate) but provides no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools or state any exclusionary conditions, leaving the agent without clear selection criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by enumerating the evaluation criteria (donor tax relief, entity tax status, cross-border granting, standout vehicle) and the scope of structures, going 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, front-loaded with the primary purpose. The first sentence is information-dense but not padded; the second sentence is short and situates the tool in a broader advisory workflow. 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 read-only lookup with a well-defined schema and annotations, the description adequately explains the tool's domain, the structures it covers, and the key filter criteria. It also positions the tool relative to other advisory layers, making it complete in context.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description reiterates some parameter context (e.g., vehicle types) but adds no new syntactic or semantic detail beyond what's already in the schema.

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

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

The description clearly states the tool's function: finding jurisdictions for charitable/philanthropic structures, with specific vehicle types listed (foundations, donor-advised funds, trusts, waqf). It also distinguishes itself from sibling tools like find_trust_jurisdictions by explicitly scoping to charitable/philanthropic structures.

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 context by calling itself the 'philanthropy/legacy complement' to other layers, implying use alongside residence/citizenship, tax, and trust tools. However, it does not explicitly name alternative tools or state when not to use this tool.

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

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

The annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context by stating what each match returns (key, vehicle, tier, status, etc.), and includes a key rule about profit tax following the owner. No contradictions with annotations, adding value beyond the structured data.

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: it starts with the main action and constraints, then describes outputs, and ends with an important caveat and disclaimer. Every sentence adds value, and the information is densely packed without being redundant. It is front-loaded with the key purpose.

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

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

The description is complete for a filter tool. It covers all parameters, describes the output fields, and provides a domain-specific rule ('Rule zero') that affects interpretation of results. The presence of an output schema reduces the need to detail return values, yet it still does. No missing critical information.

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 40% (2 of 5 parameters have descriptions), but the description compensates fully by explaining all five parameters: remote_only, max_setup_usd, banking_tier, eu_clean, and lane. Each parameter is given a clear meaning, such as 'eu_clean (exclude EU Annex I/II and FATF-listed)', which is more detailed than the schema.

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

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

The description opens with 'FILTER the Mirabello formation profiles to find company/structure jurisdictions matching constraints', specifying a verb (FILTER) and resource (Mirabello formation profiles). It lists the exact constraints and output fields, making the tool's purpose clear and differentiating it from siblings like find_low_tax or get_country.

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

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

The description clearly states when to use this tool: when you need to filter formation jurisdictions by constraints like remote_only, max_setup_usd, banking_tier, eu_clean, and lane. It provides the context of filtering, but does not explicitly mention alternatives or when not to use it, such as comparing to find_trust_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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it 'Returns matching countries with their HNWI tax + CRS + EU-list (+ crypto) snapshot,' which is useful behavioral context, but it does not disclose filter combination logic (AND/OR) or behavior when no criteria are specified. This is a typical score given annotation coverage.

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 enumerating criteria in a compact, scannable list and the second covering return value and usage hint. No wasted words, well-structured with em-dashes.

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 purpose, all criteria, return snapshot, and a usage hint. However, it leaves ambiguity about whether criteria are combined with AND or OR (the word 'or' could be enumerative), and it doesn't mention behavior when no filters are passed. With an output schema present, the return structure is likely covered, so this is a minor gap rather than a fatal omission.

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 explicitly maps all 8 boolean parameters with clarifying parentheticals, e.g., 'non-CRS (no automatic financial-account exchange)' and 'crypto-friendly (favourable crypto-asset tax regime).' This fully compensates for the lack of schema descriptions, going beyond mere parameter names.

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 starts with 'Find countries by wealth-protection tax criteria' and enumerates specific tax filters, making the tool's purpose explicit and distinct from sibling jurisdiction-finding tools like find_trust_jurisdictions and find_formation_jurisdictions. The verb-resource-scope structure is clear and differentiated.

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 wealth-protection tax screening and explicitly suggests 'Combine with a residence or citizenship route for a full tax-plus-pathway view.' However, it does not explicitly name sibling alternatives or state when not to use this tool, so it falls short of full exclusionary guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows the operation is safe. The description adds that it 'returns the screened countries that have it,' giving some behavioral context (a filtered result set), but does not explain what 'screened' means or any limitations. 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 two short sentences, front-loaded with the purpose and accompanied by helpful examples. Every word contributes meaning; no redundancy or 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?

The core functionality is described, but the 'region' parameter is undocumented and 'screened' is ambiguous. An output schema exists to describe return values, but the missing param explanation and vague screening behavior leave the description incomplete for a simple 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 0%, so the description must compensate. It explains the 'pathway' parameter with examples, but completely omits the optional 'region' parameter, leaving its purpose and acceptable values unknown. This is a significant gap for a filter 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 uses the specific verb 'Find' and clearly identifies the resource: 'countries that offer a given immigration pathway' with concrete examples (digital-nomad, skilled-work, ancestry-descent, retirement-passive). It distinguishes itself from sibling tools by focusing on immigration pathways rather than jurisdictions or 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 when to use the tool (when you need to know which countries support a particular pathway type) but does not explicitly state when not to use it or mention alternatives like find_formation_jurisdictions or check_eligibility. Context is clear but lacks explicit exclusion 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?

Annotations already declare read-only and non-destructive. The description adds useful behavioral context by specifying the output is ranked by asset-protection strength and includes statute, CRS status, and EU-list status. No contradiction with annotations.

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

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

Two sentences, densely packed with relevant information: purpose, examples, output attributes, filtering, and relationship to alternatives. 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?

For a find tool with optional filters and an output schema, the description is complete. It explains what the tool returns (statute, CRS, EU-list status), how results are ranked, and how to filter. The presence of an output schema further reduces the need to enumerate return fields.

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

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

Schema coverage is only 50% (strong_protection lacks a description). The description compensates by explaining both filters: vehicle (trust/foundation) and strong_protection. It adds meaning beyond the schema, though strong_protection's exact boolean semantics could be more 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 finds trust & foundation jurisdictions for asset protection and succession planning, with examples and a ranking criterion. It explicitly distinguishes from siblings like find_charity_jurisdictions or find_formation_jurisdictions by focusing on wealth-structuring vehicles and calling itself the complement to residence/citizenship 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?

The description gives clear context: it is for wealth-structuring (trusts/foundations) rather than residence/citizenship, and mentions filtering. However, it does not explicitly name alternative tools or state when not to use it, which would be helpful given the many find_* sibling tools.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a valuable caveat ('Indicative, not advice') and clarifies the depth of content, which goes beyond the structured annotations. No contradiction exists.

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

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

The description is a single dense sentence that front-loads the purpose, lists all relevant topics, and includes input format and a caveat. Every word contributes value; there is no fluff or redundancy.

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

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

For a read-only, single-parameter tool with an output schema present, the description covers what it returns (flags on several topics), how to call it (ISO alpha-2), and a reliability caveat. It does not explicitly explain when to choose this over siblings, but the scope is clear enough from the content. A 4 is appropriate.

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 provides zero description coverage for the 'cc' parameter (only type 'string'), but the description explicitly says 'Use ISO alpha-2', which is essential guidance for supplying a country code. This compensates for the schema gap, though it could have added examples or error handling.

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 flags anti-avoidance and relocation-tax matters, enumerating CFC, GAAR, POEM/corporate-residence, economic substance, exit-tax detail, and step-up-in-basis. This is specific and distinguishes it from generic tax tools like get_country_tax or forced_heirship_risk.

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

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

The description gives clear context: it provides 'the depth behind headline rates' and specifies using ISO alpha-2 codes. It does not explicitly name alternative tools or exclusions, but the scope is well implied, so it earns a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable context: it specifies the output is default legal rules, not a devolution analysis, and mentions how trusts/foundations are covered. This aligns with and enriches the read-only 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?

The description is dense and front-loads the core purpose, but the long enumeration of legal aspects could be slightly tightened. Overall, every clause adds meaningful information, so it is concise for the complexity involved.

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 comprehensively covers the key dimensions of forced heirship rules, including a clarifying limitation about estate devolution. Since an output schema exists, the lack of return-format details is not a gap. It is complete for a jurisdiction lookup 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 only describes 'cc' as a string, so the description must compensate. It explicitly instructs 'Use ISO alpha-2' and provides examples (France, Germany, Switzerland), clarifying both the format and purpose of the 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 provides the forced-heirship / testamentary-freedom position for a jurisdiction, enumerating specific legal aspects (existence, reserved shares, freely-disposable portion, disinheritance, trust interactions). It also explicitly differentiates from estate-planning tools by saying 'NOT how any estate will devolve.'

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

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

The description gives a strong when-not by clarifying it only states default legal rules, not estate devolution. It does not explicitly name alternative tools, but it provides enough scope for an agent to decide when this tool is relevant.

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 non-read-only behavior, and the description adds meaningful context: it creates a shareable URL with a 90-day validity and optionally registers the client for follow-up, requiring consent. This clarifies side effects without contradicting annotations.

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

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

The description is concise—two sentences—and front-loaded with the main action. It efficiently packs key outputs, validity, and optional side effects 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's complexity (14 params) and the presence of an output schema, the description covers the core purpose, outputs, and side effects sufficiently. It could mention that all parameters are optional or provide more on when to use it, but it is largely 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 64%, leaving some parameters undocumented (e.g., tax_goal, mobility_priority, timeline_max_months). The description references family and goals, which partially clarifies children counts, but it does not add meaning for the remaining unclear fields, so it only partially compensates for the coverage 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?

Description uses a specific verb 'Generate' with a clear resource 'personalised Mirabello briefing', and outlines specific outputs: ranked shortlist, full family cost math, and a shareable branded briefing page URL. This distinguishes it from sibling tools like recommend_programmes or estimate_total_cost, which handle narrower subtasks.

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

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

The description clearly implies when to use it: when a comprehensive briefing is needed from a client profile. However, it does not explicitly state when not to use it or name alternative tools for narrower needs, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by scoping the content (cases, approval rate, credentials, etc.), which goes beyond annotations. No behavioral surprises are introduced, and there is 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?

The description is two sentences: the first lists content coverage, the second gives use-case guidance. Every phrase earns its place with concrete examples (IMC, ACAMS) and explicit query types. No redundancy or filler.

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

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

Given the tool's simplicity (no parameters, no nested objects), the description is fully complete. It defines the topic, the content areas, and the user intent. The presence of an output schema means return values need not be described, and the description covers all contextual aspects an agent needs.

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

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

The tool has zero parameters, so the baseline is 4. The description compensates by clarifying what information the tool returns, effectively defining the semantic output. No parameter details are needed, and the schema coverage is trivially 100%.

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 information about Mirabello Consultancy, listing specific content categories (track record, credentials, offices, languages, services). It explicitly names the intended questions ('who is Mirabello / why use them / are they reputable'), making the purpose unambiguous and distinct from all sibling tools.

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

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

The description explicitly instructs when to use the tool with quoted example questions, providing clear guidance for the agent. It covers the exact scenarios it serves without needing exclusions, as no alternative tool in the sibling list competes with this purpose.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds that listings are 're-verified' and optionally filtered since an ISO date, but does not disclose default limits, ordering, or how 'recent' is defined. This is acceptable but leaves some behavioral ambiguity.

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-loaded with the core function and use case, with no unnecessary words. Every clause earns its place, making it 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?

For a simple read-only tool with a single optional parameter and no required parameters, the description fully covers the purpose and intended context. The presence of an output schema means return values do not need to be described in the description.

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 provides 100% coverage for the single 'since' parameter, including an example. The description adds 'optionally since an ISO date' which reinforces the parameter's purpose but does not introduce new 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 the tool's purpose: retrieving recently re-verified listings with price/availability/sale status. It distinguishes itself from siblings like get_recent_changes by focusing specifically on availability updates, a distinct resource scope.

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

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

Provides clear context for when to use the tool ('For agents keeping an inventory view fresh'), indicating a maintenance use case. It does not explicitly mention exclusions or alternatives, but the context is sufficient for differentiation in most cases.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds value by disclosing limitations: 'no account is ever guaranteed' and 'Information, not advice.' This sets expectations without contradicting annotations, enriching the behavioral context.

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

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

The description is dense and rich, covering many facets in a single long paragraph. While not succinct, every clause contributes substantive information (jurisdiction list, corporate/personal lanes, rejection causes, synergy facts, disclaimer). It is front-loaded with the core purpose.

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

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

Given the tool's complexity and the presence of an output schema, the description is highly complete: it enumerates jurisdictions, lanes, institution types, timelines, minimums, rejection causes, synergy facts, and limitations. It also clarifies parameter behavior, leaving no ambiguity about scope.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how to focus results (pass type) and that omitting cc returns the full coverage list, plus the EMI option for the e-money layer.

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: a non-resident banking-access landscape per jurisdiction, listing specific jurisdictions and dimensions (corporate/personal, fintech vs traditional, timelines, minimums, rejection causes, synergy facts). This distinguishes it from sibling tools like get_capital_controls or get_country_tax, which address 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 provides clear usage instructions for parameters ('Pass cc (or EMI); pass type corporate|personal to focus; omit cc for the coverage list'), but does not explicitly contrast with sibling tools or state when to choose this tool over alternatives. The unique subject matter implies appropriate use, but explicit exclusions are missing.

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

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

Annotations declare read-only behavior; description adds that rules change frequently, is for information only, and details what is returned. No contradictions and adds value 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?

Description is informative and front-loaded, but somewhat lengthy. Every sentence contributes value; minor trimming could improve brevity.

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 presence of an output schema, description does not need to explain return values. It covers purpose, usage, behavioral notes, and parameter semantics comprehensively.

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%; description adds concrete examples (e.g., India LRS) and clarifies that 'regime' is an optional filter. This adds meaningful context 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 returns exchange-control regime, outbound allowance, cash-declaration threshold, regulator, and implications for funding investment-migration. It distinguishes itself from sibling tools by noting this is missed by mobility-only analyses.

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?

Clear context on when to use: 'Pass cc for one jurisdiction; omit for all, or filter by regime.' It also explains the tool's unique value in deciding whether a client can pay for CBI/RBI. However, no explicit exclusions or alternative tool references.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the description is not required to repeat safety traits. It adds substantial behavioral context: what the profile includes (tax position, costs, timeline, substance requirements, banking tier, EU/FATF status, fit/non-fit, etc.), the 'General information, not advice' disclaimer, and the behavior when the parameter is omitted. 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 front-loaded with the purpose and uses clear sentences, but the first sentence is extremely long and includes an exhaustive list of 30 profile keys. This list is redundant and bloats the description, though it does provide useful reference. Overall, it is adequate but not 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 complex tool with 30 possible structures, the description is remarkably complete. It covers the exact scope, all key output categories, the caveat about being general information, and the execution context. An output schema exists, so return values don't need to be described. The description fully equips an agent to use the tool correctly.

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

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

The input schema already has 100% coverage, describing the 'structure' parameter with examples and noting that omission returns the catalogue. The description largely repeats this ('Pass structure (the profile key); omit for the catalogue of available keys'), adding minimal new meaning. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'FULL formation profile for one structure from the Mirabello Global Structuring roster.' It specifies the exact resource (formation profile) and action (get), and lists the 30 profile keys, distinguishing it from sibling tools like compare_formation or find_formation_jurisdictions.

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

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

The description provides explicit usage instructions: 'Pass structure (the profile key); omit for the catalogue of available keys.' It clarifies the input behavior and implies the tool is for single-structure lookups. It does not explicitly mention when not to use it or alternatives, but the context makes this clear enough.

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 and non-destructive. The description adds value by stating it returns 'ALL screened pathways' and details what each pathway includes (requirements, cost, processing, rights, source), setting expectations about comprehensiveness and data provenance beyond annotation defaults.

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: the first packs the tool's purpose and content scope into a single dense sentence; the second provides usage format. No filler, and all information is actionable.

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

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

For a read-only lookup tool with an output schema, the description fully covers what the tool returns, how to use parameters, and the scope of data. It leaves no obvious gaps given the annotations and schema.

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

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

Schema already covers both parameters with descriptions. The description adds ISO-3166 alpha-2 code examples (CA, GB, DE, PT) and clarifies the optional pathway filter by listing pathway types, enhancing understanding beyond the schema's shorthand.

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 a country's immigration profile covering all screened pathways beyond investment migration, listing specific pathway types. This distinguishes it from siblings like get_programme and get_country_tax by emphasizing scope and content.

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

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

Provides clear context for when to use: for a comprehensive country-level immigration overview with explicit pathway categories. The phrase 'beyond investment migration' implies an exclusion, but no alternative tools are named, so guidance is clear but not fully explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value beyond annotations by specifying 'Informational only — not tax advice' and 'From official/Tier-A sources', which provides context about data reliability and limitations. This is meaningful behavioral disclosure for an informative 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?

The description is concise and well-structured, front-loading the core purpose ('HNWI tax profile for a country') followed by a detailed but organized list of included tax components. The additional sentences about source quality and informational status earn their place, and there is no redundant 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?

The tool has a single parameter, an output schema (so return values need not be explained), and a simple read-only operation. The description covers purpose, parameter usage, source quality, and informational caveat, making it complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% with the 'cc' parameter already documented as 'ISO alpha-2 country code'. The description repeats this with 'Use the ISO alpha-2 code', adding no new semantic meaning beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly identifies the tool as providing an HNWI tax profile for a country with a wealth-protection view, listing specific tax components such as income tax, capital gains, inheritance, wealth tax, exit tax, CRS/AEOI, and special regimes. This specific verb+resource combination distinguishes it from sibling tools like get_country or get_wealth_index by focusing on tax-related details.

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 conveys clear context for when to use the tool: it is for HNWI tax profiles sourced from official/Tier-A sources and is informational only. It also instructs to use the ISO alpha-2 code. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

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

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

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description discloses provenance behavior ('Each block carries provenance (confidence, verified_date, official sources)'), uncertainty handling ('low-confidence detail is withheld as CHECK-OFFICIAL-SOURCE'), and a disclaimer about changing government timelines. This adds significant 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 long but dense, with numbered subsections and structured lists of statuses. Every sentence adds value, though it could be slightly more compact. Front-loaded with the core purpose and then 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?

Given the complexity (CBDC, stablecoin, digital ID, provenance) and the presence of an output schema, the description is complete: it explains the output structure in words, parameter semantics, provenance, and advice disclaimer. No critical gaps.

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

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

With schema coverage at 0%, the description fully compensates by explaining the parameter behavior: 'Pass cc for one jurisdiction, omit for all.' This clarifies that cc is an optional country-code filter and that omitting returns all jurisdictions.

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: 'Per-country digital-money & identity progress relevant to wealth planning' with explicit sub-categories (CBDC, stablecoin, digital ID). It differentiates from siblings by focusing on digital-government progress, distinct from general country or tax tools.

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

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

The description provides clear context on what the tool covers and gives parameter guidance ('Pass cc for one jurisdiction, omit for all'), but it does not explicitly mention alternatives or when-not-to-use cases. Context is clear without exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Beyond that, the description discloses that the checklist is not final, varies by family composition and nationality, and includes programme-specific items where published—useful context about output variability that annotations do not 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?

Two sentences, both front-loaded and informative. No fluff or redundant repetition of the title. The caveat about specialist confirmation is efficiently integrated.

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 one-parameter read-only tool with an output schema, the description covers the purpose, scope, and an important caveat about result variability. It lacks explicit parameter guidance and usage alternatives, but the presence of an output schema reduces the need to explain return values.

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% and the description never explicitly mentions programme_id. The phrase 'per programme type' indirectly implies the parameter's role, but it does not explain valid values or provide any concrete guidance on how to use the parameter, failing to compensate for the lack of 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' with a specific scope (per programme type plus programme-specific items). It distinguishes this from sibling tools like compliance_checklist by specifying the application context, though it does not explicitly name alternatives.

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 programme applications and adds a useful caveat that the final list is confirmed by a specialist and varies by family composition and nationality, guiding the agent not to treat the response as definitive. However, it provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools.

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

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

The annotations already mark this as read-only and non-destructive, but the description adds substantial behavioral context: a critical caveat that ~48% of departures have no stated destination, that totals are a floor, and that the caveats field is returned with every response. It also discloses the mandatory attribution requirement. 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 long but packed with necessary caveats and licensing information. It front-loads the purpose and data source, then explains limitations. Some sentences like 'Popularity is not suitability' are slightly rhetorical but still relevant. It earns its length for this complex data tool.

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

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

Given the tool has a schema, output schema, and annotations, the description covers all necessary contextual aspects: data source, period, what is returned, key caveats, parameter usage, and licensing. It is complete for the agent to decide when and how to invoke it.

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

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

The input schema already documents all three parameters with descriptions, so the baseline is 3. The description adds minimal extra parameter semantics beyond noting the year parameter is for a single year and destination filters to one country, both already implied by the schema. It does not compensate significantly 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 precisely states what the tool returns ('departures, arrivals and net migration per destination') for German emigration flows by destination and year, including the exact statistic ID (12711-0008). This clearly establishes the tool's purpose and distinguishes it from the broader set of sibling tools dealing with tax and residency.

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

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

Provides explicit usage guidance: 'Pass year for one year, destination to filter to one country, top to limit the list.' Also cautions against trending across 2015/2016 due to a definitional break. While it does not explicitly name alternative sibling tools, the context makes its scope clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral context: the tool covers rules that can deny boarding and invalidate passports with future expiry dates, which goes beyond the annotation content.

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 informative but slightly verbose. It front-loads the main purpose and organizes into operational criticality and usage notes. Could trim a few words without losing meaning.

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 entry rules, the description covers passport validity, health rules, and operational consequences. An output schema exists (not shown) but likely details return values. The description is complete for the domain.

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% (one parameter fully described). The description adds 'Pass cc for one destination; omit for all,' clarifying optionality and usage beyond the schema's 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 uses specific verbs ('get entry requirements') and clearly states the resource ('passport-validity rule' and 'health/vaccination entry rules'). It distinguishes from siblings like check_visa_free or get_passport_renewal by focusing on boarding-critical rules.

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

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

Provides clear usage: 'Pass cc for one destination; omit for all.' Also cautions that rules vary and change. However, it does not explicitly contrast with alternative tools or state when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds useful behavioral framing beyond this, such as 'Establishment is decided by the competent registry or regulator and executed via licensed local partners' and 'Information, not legal or tax advice,' clarifying the tool's informational nature and boundaries.

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

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

The description is long and dense, with a large list of covered topics, but every element contributes value. The usage and disclaimer sentences are concise. It is slightly overwhelming but not wasteful.

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

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

With an output schema present, the description sufficiently covers the tool's scope (194 countries, specific legal aspects), usage (cc optional), and caveats (not legal advice). It is complete for an information lookup 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 describes cc as an ISO alpha-2 code with examples. The description adds crucial semantics by stating that omitting cc returns the covered list, which clarifies the parameter's optionality and behavior—information not present in the schema.

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

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

The description clearly states it provides 'CHARITABLE & PRIVATE FOUNDATION and TRUST rules for a jurisdiction' and enumerates specific legal topics, making the tool's purpose unambiguous. It further distinguishes itself from siblings by explicitly identifying itself as the '194-country deepening behind find_charity_jurisdictions / find_trust_jurisdictions.'

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

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

Usage is explicitly described: 'Pass cc for one jurisdiction; omit for the covered list.' The relation to sibling tools (deepening of find_* tools) provides clear context for when to choose this tool over the find_* alternatives.

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

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

Annotations already indicate readOnly=true and non-destructive. The description adds important behavioral context: the ranking is composite, methodology is transparent, and programmes with insufficient data are flagged provisional and excluded from the headline ranking. This adds real value 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 two sentences: the first clearly defines the tool's purpose and constituents, while the second addresses filtering and data-quality nuances. It is front-loaded and every sentence provides essential information without waste.

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

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

For a read-only index tool with only two optional parameters and an output schema, the description covers all necessary aspects: what the index is, how it is ranked, how to filter, and how provisional data is handled. The output schema handles return-value details, so no further description 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 0%, so the description must compensate. It mentions 'Filter by type (CBI/RBI) and limit,' directly referencing both parameters and explaining the enum values. However, it does not elaborate on the meaning or default behavior of 'limit,' leaving some ambiguity.

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

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

The description clearly identifies the tool as providing the Mirabello Investment Migration Index, a composite 0–100 ranking across specific dimensions. It distinguishes itself from sibling tools like get_wealth_index or list_programmes by naming the index and its unique scoring criteria.

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

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

The description implies usage by stating 'Filter by type (CBI/RBI) and limit,' but it does not explicitly say when to use this tool instead of alternatives like compare_programmes or get_programme. There are no exclusions or alternative tool references, so guidance is implied rather than explicit.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: it clarifies the scope ('lawful residence/citizenship ROUTES'), notes that passport reach is 'included as context only,' and includes the caveat 'INFORMATION, NOT ADVICE.' This goes beyond the annotations and helps set expectations without contradicting them.

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

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

The description is information-dense and well-structured. It starts with the core purpose, lists the included elements in a parenthetical list, then provides the parameter instruction and a clear advisory caveat. Each sentence serves a purpose, and the length is appropriate for the tool's complexity.

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

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

Given the tool's complexity, the description covers the essential aspects: what it returns (routes, presence, family, permanence, processing, regulator), how to filter by cc, and its advisory nature. An output schema exists, so not detailing exact return fields is acceptable. It could mention what happens when 'omit for all' is used in terms of response size, but the current guidance 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 one parameter 'cc' with no description (0% coverage). The description compensates by explaining 'Pass cc for one jurisdiction, omit for all,' which conveys that cc is a country code, that it is optional, and that omitting yields all jurisdictions. This is sufficient for basic usage, though it does not specify the exact format (e.g., ISO code).

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 'strategic mobility optionality' for a jurisdiction, specifying the exact types of information included: residence/citizenship routes, investment programmes, physical presence, family inclusion, path to permanence, processing time, and regulator. It also explicitly distinguishes itself from passport strength, setting it apart from sibling tools like check_visa_free.

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

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

The description gives clear usage context: it is a planning view, not passport strength, and instructs to 'combine with the full immigration profile and a Mirabello consultation.' It also explains parameter usage with 'Pass cc for one jurisdiction, omit for all.' However, it does not explicitly name alternative tools or provide when-not-to-use conditions beyond the passport-strength exclusion.

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/non-destructive. The description adds critical behavioral context: the tool does not file applications, merely informs/orchestrates, and includes a legal disclaimer. This goes well 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?

The description is dense and comprehensive, but every element serves to define scope and usage. It is not overly verbose relative to the complexity of the topic.

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 name change rules and the presence of an output schema, the description covers all relevant dimensions: legal grounds, authority, applicants, process, costs, timeline, passport effects, transliteration, foreign records, and usage context. It is complete.

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

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

The schema describes cc as an ISO alpha-2 code. The description adds that it is optional and that omitting it returns the covered list, which is meaningful 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 precisely identifies the tool as returning legal name change rules for a jurisdiction and enumerates the specific facets (grounds, authority, applicants, process, cost, timeline, passport effect, transliteration, foreign records). This clearly differentiates it from sibling tools like get_passport_renewal or get_country.

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

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

It states typical scenarios (marriage, naturalisation, non-Latin names) and explains parameter handling (pass cc for one jurisdiction; omit for the covered list). Does not explicitly name alternative tools, but the context is 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?

Beyond the read-only annotations, the description adds essential behavioral context: the separation of statutory position from practical bank appetite ('many countries are legally open but practically closed — the two are never merged'), the indicative nature of minimums ('bank policy, never law'), and the explicit disclaimer that 'NO account opening is ever guaranteed' with full CRS/FATCA transparency. It also warns that it is information, not advice. This thoroughly discloses reliability and data caveats.

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 purpose and then uses compact punctuation (em dashes, semicolons) to compress a lot of structured content. It is longer than strictly necessary but every clause carries information (profiles, KYC, remote-opening, minimums, timelines, CRS/FATCA, EDD triggers). No wasted words, though the disclaimer could be considered necessary context.

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

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

Given the tool has one optional parameter and an output schema (which already describes return values), the description goes beyond the minimum by enumerating the content categories (statutory vs practical, KYC, minimums, etc.), clarifying the parameter's effect, and adding risk disclaimers. It also orients the user within the sibling ecosystem. For a read-only informational tool, this is complete.

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

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

The schema already describes cc as an ISO alpha-2 code, covering 100% of parameter semantics. The description adds the behavioral nuance: 'Pass cc for one jurisdiction; omit for the covered list' clarifies the optionality and the distinction between single-country vs list output. This goes beyond the schema's basic type.

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 'BANK-ACCOUNT ACCESS for FOREIGN NON-RESIDENTS in a jurisdiction' and details the two profile types (individual, entity) and the content dimensions. It explicitly positions itself as 'The 194-country deepening behind get_banking_access', distinguishing it from the sibling overview tool. The phrase 'Pass cc for one jurisdiction; omit for the covered list' confirms the action and scope.

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

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

It provides direct usage context: 'The 194-country deepening behind get_banking_access' indicates when to use this tool for deeper jurisdiction-level detail beyond the general banking access tool. It also explains the parameter-driven behavior (pass cc for a single jurisdiction, omit for the full covered list). However, it does not explicitly specify exclusions, e.g., when to use other sibling tools like check_eligibility or get_country.

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

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

Annotations already mark the tool as readOnly and non-destructive. The description adds useful behavioral context: it cites official source URLs and last_verified, notes the Vanuatu in-person biometric exception, and includes a 'Information, not advice' disclaimer. No contradiction with annotations.

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

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

The description is a single dense, run-on sentence that front-loads the purpose but becomes hard to scan due to the long list of details. It is not concise, but every clause does contribute useful information.

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

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

For a facts tool, the description covers all critical dimensions: costs, validity, processing, exceptions, deadlines, official sources, verification status, and query scope. With an output schema present, return-value documentation is unnecessary.

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

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

Schema coverage is 100% for the single optional 'country' parameter. The description reinforces its meaning with concrete examples (st-kitts-cbi) and default behavior ('omit for all six'), adding value beyond the schema's bare 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 opens with 'CBI passport-RENEWAL facts' and specifies the exact resource and content scope (fees, validity, processing, remote-renewal capability, biometric status, deadlines). This clearly distinguishes it from sibling tools like get_programme or get_entry_requirements.

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

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

It gives explicit parameter usage instructions: 'Pass country ... for one; omit for all six.' It does not name alternative tools or exclusion scenarios, but the context for when to use this tool is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which matches the read-only 'estimate' nature. The description adds the scope ('by id or all') but does not reveal additional behavioral traits like output format or edge cases; 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?

The description is a single, tight sentence that front-loads the verb ('Processing-time estimate') and specifies scope without any wasted words. It is concise and immediately understandable.

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 optional parameter and an output schema, the description covers the essential behavior (scope via id or all). It does not elaborate on return details, but the output schema and annotations supply the rest, making it 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?

Schema description coverage is 0%, so the description must compensate. It explains that 'id' selects a single programme while its absence returns all, giving meaningful context beyond the bare schema field. This adequately covers the one optional parameter.

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

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

The description clearly states the verb ('Processing-time estimate') and resource ('programme'), with an explicit scope ('by id or all'). This differentiates it from sibling tools like 'estimate_timeline' by focusing on processing times for 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 no explicit guidance on when to use this tool versus alternatives, nor any exclusions or criteria. It simply states the function without situating it among the many sibling get_* tools, leaving the agent without direction.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable context by enumerating the returned fields (routes, fees, processing, etc.) and noting the Mirabello Index composite score + rank, which goes beyond annotations without contradicting them.

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

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

The description is a single, information-dense sentence that front-loads the core purpose ('Full detail for one programme by id') and then lists the specific content covered. No wasted words; every part adds value.

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

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

The tool has an output schema (not shown but indicated), and the description provides sufficient context for a simple get-by-id operation. It covers what the tool returns and the parameter semantics, making it complete for selecting and invoking the tool correctly.

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

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

Schema description coverage is 0%, but the description provides examples of valid id values ('dominica-cbi','greece-gv') and clarifies the parameter is a programme id. This compensates for the lack of schema-level documentation, though it doesn't fully specify the slug format beyond examples.

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

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

The description clearly states 'Full detail for one programme by id' with specific verb, resource, and scope. It lists the exact content (routes, fees, processing, mobility, tax, path to citizenship, Mirabello Index score/rank) and provides examples, making it unambiguous and distinct from sibling tools like list_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 usage when full detail for a single programme is needed, and gives examples of valid ids. However, it does not explicitly mention alternatives or when not to use this tool relative to siblings like get_index or list_programmes, though the specificity makes the context clear.

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

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

Annotations already indicate read-only and non-destructive, but the description adds valuable behavioral context: data is 'indicative' and must be 'verify[ied] with Mirabello', some fields are only shown 'where disclosed', and freshness/availability are part of the output. It also discloses the external dependency on Mirabello as broker of record, going well beyond the annotation surface.

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

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

Three tight sentences: the first states the core function and data scope, the second adds broker context, the third adds a reliability caveat. Every sentence adds information without redundancy, and the description is front-loaded with the primary purpose.

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

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

Given the tool has an output schema (which handles return structure), the description sufficiently covers what data is available, the caveat about indicative data, and the external verification source. For a single-parameter read-only tool, this is complete; no missing prerequisites or behavioral information.

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 carries the burden. It explicitly states the parameter is a 'slug' used to identify one property, which gives semantic meaning to an otherwise bare string field. It does not detail where the slug comes from or its format, but for a single-parameter tool the clarification is sufficient 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 is highly specific: 'Full detail for one investment property by slug' enumerates exactly what is included (price, specs, location, programme, etc.) and clearly distinguishes this tool from siblings like search_properties and get_programme. The verb+resource pattern and the list of data fields make the purpose unmistakable.

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

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

The description clearly implies the use case: retrieve full detail for a single property when you have its slug. It does not explicitly name alternatives or exclusion criteria, but the contrast with search_properties (searching) is implicit. The mention of 'by slug' is a clear precondition yet stops short of explicit when-not guidance.

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

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

Annotations already mark readOnly/destructive, and the description adds caveats: rules change without notice, subnational variation, licensed professionals, not advice. It also mentions linking to get_capital_controls, revealing that it references related data. This adds value beyond annotations without contradicting them.

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

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

The description is dense but every clause provides necessary detail for a complex tool. It is front-loaded with the main subject and covers scope, usage, and limitations in one paragraph, though it could benefit from segmentation.

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

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

Given the tool's complexity, the description covers a wide range of topics (ownership vehicles, taxes, approvals, inheritance, etc.), usage instructions, and disclaimers. With an output schema present, return-value details are not needed. The description gives an agent sufficient context to invoke correctly.

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

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

The schema documents cc as ISO code, but the description clarifies optionality (omit for covered list) and the jurisdictional nuance (federal states flagged subnational). This goes beyond the schema's simple 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 provides real-estate law for foreign buyers, enumerating specific topics (freehold, approval regimes, taxes, vehicles, etc.) and distinguishes itself from search_properties by complementing it with the legal background. This is a specific verb+resource+scope with sibling differentiation.

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

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

It explicitly says it complements search_properties, implying use when legal context is needed. It also instructs on parameter usage (pass cc for one jurisdiction, omit for list) and notes federal-state behavior. However, it does not systematically exclude alternatives like get_property or get_country, so it's clear but not exhaustive.

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

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

Beyond the readOnlyHint and non-destructive annotations, the description discloses rich behavioral detail: it returns derivation via 'extraction model + ensemble + independent corroboration', freshness statuses including 'CHECK-OFFICIAL-SOURCE', and recheck_by timestamps. This gives AI agents insight into how data is produced and when to re-verify, which is essential for trust.

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

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

The description is dense but well-structured: it opens with 'CITATION-FIRST provenance', lists what is returned, explains the use case, and ends with parameter instruction. Every sentence carries valuable information without filler.

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

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

Despite being a complex tool with freshness logic, the description covers return fields, the purpose, and re-verification semantics. With an output schema also present, the agent has sufficient information to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents cc and pathway. The description merely restates 'Pass cc (+ optional pathway)', adding no new semantic meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool returns provenance for a country's pathway facts, enumerating specific outputs like source_url, verbatim quote, derivation method, confidence, and freshness block. It distinguishes itself from sibling tools by explicitly framing it as 'CITATION-FIRST' and for citing data with source + as-of date.

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

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

The description explicitly instructs when to use the tool: 'Use this to CITE Mirabello data with a source + as-of date and to know when to re-verify.' It does not mention alternatives or when-not-to-use, but the guidance is clear and actionable.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds meaningful behavioral context beyond this: it reveals the tool aggregates multiple change types, includes official-source diffs with citations, and claims primary-source verification ('freshest, primary-source-verified record'). This helps the agent understand data provenance and freshness without conflicting with annotations. It does not discuss rate limits or pagination, but that's acceptable given the annotation coverage.

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?