Spain Legal by Legal Fournier

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

Annotations declare readOnly/idempotent/destructive hints, so the description adds valuable behavioral context beyond safety: it specifies 'qualitative gatechecks' as the method and details the return structure (rule trace, review level, canonical resources). This helps the agent understand what kind of analysis is 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?

Single dense sentence with zero waste. Front-loaded with action (Screen), target (Beckham regime), method (qualitative gatechecks), and output (rule trace, review level, resources). Every clause earns its place.

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

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

Given the presence of an output schema (not shown but indicated), rich input schema with 100% coverage, and comprehensive annotations, the description appropriately focuses on high-level behavior rather than enumerating parameters or return fields. Sufficient for a specialized tax screening tool.

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

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

Schema description coverage is 100% with well-documented enums (move_reason, employment_type, ownership_band). The description provides no additional parameter semantics, but baseline 3 is appropriate when the schema carries full documentation burden.

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 verb 'Screen' with clear resource 'Spain's Beckham regime' and distinguishes from siblings like compare_tax_regimes by focusing specifically on Beckham eligibility rather than general tax comparison. It also clarifies the return values (rule trace, review level, MCP resources).

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?

While the specificity to 'Beckham regime' implies usage context, there is no explicit guidance on when to use this versus compare_tax_regimes or get_visa_options. The mention of 'canonical MCP resources for follow-up' hints at workflow but lacks explicit when/when-not directives.

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 idempotentHint=true, confirming safe analytical behavior. The description adds valuable context beyond these annotations by disclosing the output format (conceptual reasoning vs. data tables) and mentioning 'canonical MCP resources,' which hints at tool relationships without contradicting the safety 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, efficiently structured sentence that front-loads the core action ('Compare Beckham versus standard Spanish resident taxation conceptually') and immediately follows with output specifications. There is zero waste; every clause delivers necessary scoping 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?

Given the presence of an output schema and 100% input schema coverage, the description appropriately focuses on conceptual scope and output characterization rather than repeating structural details. It successfully conveys the analytical nature of the comparison and resource-linking behavior, though it could strengthen workflow context by mentioning the eligibility check prerequisite.

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

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

With 100% schema description coverage, all four parameters (employment_type, has_foreign_income, prefers_predictability, has_significant_foreign_assets) are already well-documented in the schema. The description does not add additional parameter-specific guidance or interaction logic, meeting the baseline expectation for high-coverage schemas.

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 provides a specific verb ('Compare'), clear resources ('Beckham versus standard Spanish resident taxation'), and scope ('conceptually'). It effectively distinguishes from sibling 'check_beckham_eligibility' by positioning this as a conceptual comparison tool rather than an eligibility validator.

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 by specifying what it returns ('reasoning, review level, and canonical MCP resources') and explicitly excluding rate tables ('instead of rate tables'), guiding the agent away from using this for numerical calculations. However, it does not explicitly state the workflow relationship with 'check_beckham_eligibility' (e.g., whether to check eligibility first).

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 writable (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds that it is a 'consequential action' requiring user consent, providing context beyond annotations, such as the need for explicit consent before invoking.

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 main action and condition. Every word is essential, with 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?

Given the high parameter count (21) and full schema coverage, the description adequately explains the tool's purpose and invocation condition. It does not detail return values, but an output schema exists, so that is acceptable.

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

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

Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional semantic meaning for parameters beyond the schema, so 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 verb 'Create', the resource 'accepted Legal Fournier lead', and the condition 'after explicit user consent'. It distinguishes this tool from siblings like route_to_legal_fournier_help by specifying the stage of the workflow.

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

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

The description explicitly states when to call: 'only when the user has asked to contact Legal Fournier and has consented to follow-up'. This gives clear usage context, though it doesn't mention alternatives among siblings.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value by specifying the content is 'stable' and 'canonical', implying reliability and official status, but does not disclose additional behavioral traits like caching policies or response freshness.

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 with no filler. Key qualifiers ('stable', 'canonical', 'for agents') each serve distinct purposes in setting expectations about content quality and intended audience.

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 zero parameters and an output schema exists, the description appropriately summarizes the output content (workflow, distinctions, resource) without needing to elaborate on return values. A brief mention that this requires no filters or prerequisites would strengthen 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 contains zero parameters, which establishes a baseline score of 4. The description appropriately implies no user input is required by using the transitive verb 'Return' without referencing any parameters.

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 ('Return') and identifies the resource clearly ('NIE and TIE workflow', 'procedural distinctions', 'canonical process resource'). However, it does not explicitly differentiate from siblings like 'get_residency_path' which might also provide process information.

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

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

The description mentions the target audience ('for agents') but provides no explicit guidance on when to use this tool versus alternatives like 'get_residency_path' or 'route_to_legal_fournier_help'. There are no stated prerequisites or exclusion 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 and idempotentHint. The description adds that it returns a public tool page and MCP workflow, providing behavioral context beyond the annotations. 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 a single, efficient sentence that covers the core action and domain. Every word is necessary and front-loaded.

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

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

Despite having 6 parameters and an output schema, the description is too terse. It does not explain the matching logic, what 'best' means, or how parameters like complexity_signals affect results. More context is needed for a tool of this complexity.

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 documents each parameter well. The tool description does not add additional meaning beyond what the schema provides, earning the baseline of 3.

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

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

The description clearly states the tool matches a case to the best tool page and workflow, specifying domains (Spain legal, tax, etc.). However, it does not differentiate from sibling tools that are more specific, missing explicit 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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for general cases but does not mention when not to use it or point to specific siblings for narrow needs.

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

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

Annotations confirm read-only/idempotent safety, while the description adds valuable behavioral context that the tool provides 'explicit caution flags for counting issues.' This discloses a key output characteristic (warning generation for residence clock problems) beyond what annotations provide, though it doesn't mention rate limits or caching behavior.

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

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

The single sentence is front-loaded with the action ('Explain'), specifies the inputs, and adds the unique value proposition ('explicit caution flags') without redundancy. Every clause earns its place in guiding tool selection.

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 and comprehensive input schema with enums, the description appropriately focuses on purpose and behavioral traits rather than enumerating parameters or return values. It successfully signals the tool's complexity-handling (multiple nationality tracks) through the 'counting issues' mention, though it could briefly acknowledge the optional nationality track variations.

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

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

With 100% schema description coverage, the parameters are well-documented in the schema itself. The description references the two required parameters ('current status and time') and alludes to the absence concern parameter ('counting issues'), but does not add syntax details or semantic clarifications beyond the schema definitions, warranting the baseline score.

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 ('Explain') and resources ('permanent-residency or nationality milestone') and scopes the function to users already in Spain ('from current status and time in Spain'). It clearly distinguishes from sibling tools like get_visa_options (entry) and explain_nie_process (identification documents) by focusing on status progression.

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 prerequisites by referencing 'current status and time in Spain,' indicating when the tool is applicable. However, it lacks explicit guidance on when NOT to use it or direct comparisons to alternatives like route_to_legal_fournier_help for complex 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 establish read-only/idempotent safety, but the description adds valuable behavioral context: it discloses the ranking methodology ('evergreen logic'), explains the three-component output structure (traces, actions, canonical resources), and clarifies that it returns MCP resource references. It does not mention rate limits or auth requirements, but these may not apply.

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

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

Single, dense sentence front-loaded with the core action ('Rank Spain residence routes'). Every clause delivers distinct value: methodology ('evergreen logic'), output artifacts ('decision traces, next actions'), and integration pattern ('canonical MCP resources'). Zero 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 presence of an output schema, the description appropriately summarizes the return value structure without duplicating it. For a complex 8-parameter decision tool, it adequately covers the ranking behavior and output composition. Could optionally mention that it evaluates against multiple Spanish visa programs, but 'residence routes' implies sufficient breadth.

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

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

With 100% schema description coverage across all 8 parameters (including enum values and types), the schema carries the semantic burden. The description does not add supplementary parameter guidance (e.g., specific nationality code formats), but this is unnecessary given the comprehensive schema documentation. Baseline score applies.

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

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

The description uses a specific verb ('Rank') + resource ('Spain residence routes') and clearly distinguishes from sibling 'get_residency_path' by emphasizing comparative ranking rather than singular retrieval. It specifies the methodology ('evergreen logic') and deliverables ('decision traces, next actions, and canonical MCP resources'), making the scope distinct from specialized tools like 'check_beckham_eligibility'.

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?

While the description implies usage scenarios through the mention of ranking logic and decision traces, it lacks explicit guidance on when to use this broad ranking tool versus siblings like 'get_residency_path' (singular path retrieval) or 'check_beckham_eligibility' (specific regime check). No 'when-not' or prerequisite 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 declare readOnly/idempotent safety, so the description appropriately focuses on adding context about what gets returned (service match, preparation checklist, handoff message). It also clarifies the decision-making nature of the tool beyond simple data retrieval, adding valuable behavioral expectations 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?

Single, efficiently structured sentence front-loaded with the core action. Every clause earns its place: the decision logic ('Decide whether... escalated'), the destination ('Legal Fournier'), and the three deliverables ('service match, preparation checklist, and ready-to-send handoff message'). Zero 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?

Given the existence of an output schema and rich input schema (100% coverage, enums), the description provides appropriate completeness by summarizing the three key deliverables and the escalation decision logic. It appropriately delegates parameter details to the schema while conveying the tool's scope in the legal 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?

With 100% schema description coverage and well-defined enums, the schema carries the full burden of parameter documentation. The description neither repeats parameter details nor adds semantic relationships between them (e.g., how blockers interact with area), earning the baseline score for high-coverage schemas.

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 (decide, escalate, return) and clearly identifies the resource (Spain legal matter → Legal Fournier). It effectively distinguishes this tool from self-serve siblings (check_beckham_eligibility, compare_tax_regimes, etc.) by emphasizing human escalation and decision-making.

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 that this tool is for assessing escalation to human legal help ('Decide whether... should be escalated'). While it doesn't explicitly name alternatives or exclusions, the 'whether' clause and focus on Legal Fournier routing implicitly contrast with the informational 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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate safe, non-destructive behavior. The description adds value by detailing the nature of the output: 'intake screening, missing facts, complexity flags, and handoff guidance'. 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 a single sentence that efficiently conveys the tool's purpose and output. No unnecessary words or redundancy. Perfectly concise.

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

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

Given the complexity (6 parameters, 1 required, high schema coverage, and existence of an output schema), the description adequately covers the tool's function and returns. It lacks examples or guidance on parameter interplay, but the output schema likely compensates. Overall, it is sufficiently complete.

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

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

Schema description coverage is 100%, with each parameter having a clear description in the schema. The tool description does not add additional meaning beyond what the schema already provides. Baseline 3 is appropriate given high coverage.

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

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

The description clearly states the action: 'Run a Legal Fournier public calculator or screener directly inside MCP'. It specifies what it returns: 'intake screening, missing facts, complexity flags, and handoff guidance'. This sufficiently distinguishes it from sibling tools like check_beckham_eligibility or compare_tax_regimes, which are more specific.

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

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

The description does not explicitly state when to use this tool versus its siblings. There is no mention of prerequisites, alternatives, or when not to use it. The tool_id enum provides some context, but the description itself offers no guidance on selection criteria.

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