Spain Legal by Legal Fournier
Server Details
Spain legal MCP for visas, Beckham, NIE/TIE, residency, nationality, tax, and contact handoff.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 7 of 7 tools scored.
Each tool addresses a distinct aspect of Spanish legal and residency processes, with no overlap in purpose. For example, check_beckham_eligibility is separate from compare_tax_regimes, and explain_nie_process is unique.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., 'check_beckham_eligibility', 'get_visa_options', making the set predictable and easy to navigate.
Seven tools cover the core needs for Spanish legal assistance without being overwhelming. The scope is well-balanced for the domain.
The set covers key areas like tax regimes, visas, residency, and escalation, but lacks direct tools for property or business legal matters, though the escalation tool fills some gaps.
Available Tools
9 toolscheck_beckham_eligibilityCheck Beckham EligibilityARead-onlyIdempotentInspect
Screen Spain's Beckham regime using qualitative gatechecks, returning the rule trace, review level, and canonical MCP resources for follow-up.
| Name | Required | Description | Default |
|---|---|---|---|
| move_reason | Yes | Main reason for relocating to Spain. | |
| ownership_band | No | Optional ownership context for director-style cases. | |
| employment_type | Yes | Employment structure that will support the move. | |
| years_since_last_spanish_residency | Yes | Number of years since the applicant was last a Spanish tax resident. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | High-level Beckham eligibility outcome. |
| reasons | Yes | Positive signals supporting the result. |
| summary | Yes | One-line explanation of the result. |
| next_steps | Yes | Suggested next steps. |
| references | Yes | Secondary Legal Fournier references. |
| review_level | Yes | How much human review is still advisable before treating the result as filing-ready. |
| decision_trace | Yes | Structured trace of the main Beckham screening factors. |
| blocking_issues | Yes | Blocking or weakening issues. |
| qualifying_paths | Yes | Potential qualifying paths. |
| key_rules_applied | Yes | Stable rules applied by the tool. |
| related_resource_uris | Yes | Canonical MCP resources an agent can read next without leaving the server. |
| official_legal_sources | Yes | Official legal sources anchoring the Beckham analysis. |
| suggested_follow_up_tools | Yes | Tool calls that are likely to advance the analysis. |
| current_verification_flags | Yes | Live-verification warnings for fact-sensitive or time-sensitive Beckham points. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds value by detailing the tool's qualitative nature and specific outputs (rule trace, review level, MCP resources), which are behavioral traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the key verb 'Screen', no wasted words, and efficiently communicates purpose and outputs.
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 (referenced in context signals) and the description listing output types, the tool is fairly complete. Minor improvement could include prerequisites or expected input constraints, but overall sufficient.
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 description. The tool description does not add parameter-specific semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens Spain's Beckham regime using qualitative gatechecks and lists specific outputs (rule trace, review level, canonical MCP resources). It uses specific verb 'screen' and identifies the resource, distinguishing it from siblings like 'get_visa_options' or 'compare_tax_regimes'.
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 screening Beckham eligibility but does not explicitly state when to use this tool versus alternatives like 'compare_tax_regimes' or 'get_visa_options'. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_tax_regimesCompare Tax RegimesARead-onlyIdempotentInspect
Compare Beckham versus standard Spanish resident taxation conceptually, returning reasoning, review level, and canonical MCP resources instead of rate tables.
| Name | Required | Description | Default |
|---|---|---|---|
| employment_type | No | Employment structure to test against the conceptual tax comparison. | |
| has_foreign_income | No | Whether foreign-source income is material to the profile. | |
| prefers_predictability | No | Whether the applicant values a simpler, more predictable regime structure. | |
| has_significant_foreign_assets | No | Whether foreign assets are materially relevant to planning. |
Output Schema
| Name | Required | Description |
|---|---|---|
| caveats | Yes | Caveats that limit the comparison. |
| summary | Yes | Short explanation of the recommendation. |
| comparison | Yes | Topic-by-topic conceptual comparison. |
| references | Yes | Secondary Legal Fournier references. |
| next_actions | Yes | Next actions that sharpen the tax answer. |
| review_level | Yes | How much human review is still advisable before treating the result as filing-ready. |
| decision_trace | Yes | Structured trace of the main tax-comparison factors. |
| recommendation | Yes | Conceptual starting recommendation. |
| likely_fit_notes | Yes | Why the profile leans toward a given regime. |
| key_rules_applied | Yes | Stable rules applied by the tool. |
| related_resource_uris | Yes | Canonical MCP resources an agent can read next without leaving the server. |
| official_legal_sources | Yes | Official tax and mobility sources anchoring the comparison. |
| suggested_follow_up_tools | Yes | Tool calls that are likely to advance the analysis. |
| current_verification_flags | Yes | Live-verification warnings for entry-path, timing, or filing issues. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating that the tool returns 'reasoning, review level, and canonical MCP resources' rather than rate tables, which provides deeper insight into the output nature. 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 of 20 words, concise and front-loaded with the core action. Every word adds value without 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 complexity of tax regime comparison and the presence of an output schema, the description adequately explains what is returned (reasoning, review level, canonical MCP resources). It could benefit from mentioning error conditions or prerequisites, but for a conceptual tool with rich annotations, 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 coverage is 100% with adequate descriptions for all four parameters. The tool description does not add extra meaning beyond what is in the schema parameter descriptions. Baseline score of 3 is appropriate since the schema does the heavy lifting.
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 ('Compare') and objects ('Beckham versus standard Spanish resident taxation') and distinguishes itself from rate tables and sibling tools by emphasizing 'conceptually' and 'returning reasoning, review level, and canonical MCP resources instead of rate tables.' It clearly states what the tool does and how it differs from similar 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 implies the tool is for conceptual comparison rather than detailed rate tables, but it does not explicitly state when to use it versus sibling tools like 'check_beckham_eligibility' or other context. The usage context is implied but not fully clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_legal_fournier_contact_requestCreate Legal Fournier Contact RequestAInspect
Create an accepted Legal Fournier lead from an agent workflow after explicit user consent. This is a consequential action: call only when the user has asked to contact Legal Fournier and has consented to follow-up.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | User's name for Legal Fournier follow-up. | |
| Yes | User's email address for Legal Fournier follow-up. | ||
| phone | No | Optional phone or WhatsApp number. | |
| lead_id | No | Optional upstream lead ID. | |
| urgency | No | Requested urgency for Legal Fournier review. | |
| agent_app | No | Name of the agent app or connector. | |
| tool_name | No | Tool or workflow that generated this contact request. | |
| legal_area | Yes | Main legal or tax area for the request. | |
| risk_flags | No | Known risk flags or complexity triggers. | |
| source_url | No | Optional URL where the agent flow started. | |
| case_summary | Yes | Non-sensitive summary of the matter to send to Legal Fournier. | |
| referrer_url | No | Optional referrer URL. | |
| tool_context | No | Short note about the tool flow that produced this lead. | |
| missing_facts | No | Important facts still missing for lawyer review. | |
| source_surface | No | Agent surface sending the request. | |
| idempotency_key | No | Stable idempotency key for safe retries. | |
| confirmed_consent | Yes | Must be true only after the user explicitly asks the agent to contact Legal Fournier. | |
| consent_to_contact | Yes | Must be true only after the user consents to Legal Fournier contacting them. | |
| preferred_language | No | Preferred follow-up language. | |
| agent_handoff_message | No | Agent-prepared handoff summary, ideally from route_to_legal_fournier_help. | |
| related_resource_uris | No | MCP resource URIs already used in the analysis. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the request was accepted by Legal Fournier. |
| source | Yes | Lead source bucket. |
| lead_id | Yes | Public lead identifier recorded in WordPress. |
| message | Yes | Human-readable confirmation message. |
| entry_id | Yes | Internal WordPress lead entry ID. |
| admin_queue | Yes | Where Legal Fournier staff can review the request. |
| lead_status | Yes | Whether this was a new accepted lead or an idempotent duplicate. |
| next_actions | Yes | Safe follow-up instructions for the calling agent. |
| source_surface | Yes | Agent surface recorded for attribution. |
| representation_notice | Yes | Notice that contact request submission does not create representation. |
Tool Definition Quality
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.
explain_nie_processExplain NIE ProcessARead-onlyIdempotentInspect
Return the stable NIE and TIE workflow, the key procedural distinctions, and the canonical process resource for agents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| forms | Yes | Relevant forms and administrative references. |
| steps | Yes | Ordered process steps. |
| summary | Yes | Short overview of the NIE/TIE process. |
| references | Yes | Secondary Legal Fournier references. |
| next_actions | Yes | Next actions to progress the procedure. |
| review_level | Yes | How much human review is still advisable before treating the result as filing-ready. |
| decision_trace | Yes | Structured trace of the procedural distinctions that matter. |
| common_mistakes | Yes | Common mistakes in NIE/TIE processing. |
| key_distinctions | Yes | Key distinctions that agents should preserve. |
| key_rules_applied | Yes | Stable procedural rules applied by the tool. |
| related_resource_uris | Yes | Canonical MCP resources an agent can read next without leaving the server. |
| official_legal_sources | Yes | Official legal and administrative sources anchoring the procedure. |
| suggested_follow_up_tools | Yes | Tool calls that are likely to advance the analysis. |
| current_verification_flags | Yes | Live-verification warnings for office-level or fee-level volatility. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds value by specifying what is returned (stable workflow, distinctions, resource), providing context beyond safety annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and front-loaded. No wasted words, earns its place by conveying key information immediately.
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 zero parameters and presence of output schema, description adequately covers the tool's purpose. Could mention when to use, but guidelines dimension already covers that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100% trivially. Description adds meaning by detailing what the tool returns, fulfilling the role of explaining behavior. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns stable NIE and TIE workflow, key procedural distinctions, and canonical process resource. Verb 'return' is specific, resource is well-defined, and distills from siblings like check_beckham_eligibility or get_visa_options.
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 when-to-use or when-not-to-use guidance. Implied for agents needing process info, but no alternatives mentioned. Could be improved by noting best use case before other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_legal_fournier_toolFind Legal Fournier ToolBRead-onlyIdempotentInspect
Match a Spain legal, tax, property, business, or private-client case to the best Legal Fournier public tool page and MCP workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Optional broad area when the agent already knows it. | |
| query | No | Natural-language user goal or case summary, such as 'high-income founder buying property in Spain'. | |
| max_results | No | Maximum number of matched public tools to return when include_all_tools is false. | |
| include_all_tools | No | Return the full Legal Fournier public tool catalog instead of only top matches. | |
| complexity_signals | No | Signals that should affect matching and escalation. | |
| preferred_language | No | Preferred public-page language when an equivalent translated tool exists. |
Output Schema
| Name | Required | Description |
|---|---|---|
| handoff_url | Yes | Site-controlled consultation handoff URL. |
| catalog_size | Yes | Number of public Legal Fournier tools in the MCP catalog. |
| legal_notice | Yes | General legal notice that agents must preserve when using tool results. |
| next_actions | Yes | Immediate actions for the agent after matching the public tool. |
| matched_tools | Yes | Ranked public tools and their agent workflow guidance. |
| query_summary | Yes | Short summary of the matching inputs and result count. |
| agent_use_rules | Yes | Rules for agents using the public tools with MCP outputs. |
| catalog_resource_uri | Yes | Canonical MCP resource URI for the complete public tool catalog. |
| recommended_mcp_sequence | Yes | Recommended MCP tool sequence before the public-page or human handoff. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is lower. The description adds that the tool returns 'the best Legal Fournier public tool page and MCP workflow', which provides some behavioral context but does not detail additional traits like ranking criteria or result limit behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's action and scope. There is no extraneous information, and it is front-loaded for quick comprehension.
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 fully described schema (100% coverage), an output schema (mentioned), and only 6 parameters with no nested objects, the description is sufficient to understand the core function. However, it could be slightly more explicit about how matching works or what 'best' means, but overall it is complete for the complexity level.
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?
All six parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add meaning beyond the schema; it only refers to a 'case' which aligns with the 'query' parameter. No extra semantic context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool matches a legal case to the best tool page and workflow. The verb 'match' and resource 'Legal Fournier public tool page and MCP workflow' are specific. However, it does not explicitly differentiate from sibling tools like check_beckham_eligibility or route_to_legal_fournier_help, though the matching purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to find the right tool for a case, but it provides no explicit guidance on when to use versus alternatives, no when-not-to-use conditions, and no mention of prerequisite knowledge or context. This is a significant gap for a tool that acts as a recommender.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_residency_pathGet Residency PathARead-onlyIdempotentInspect
Explain the next permanent-residency or nationality milestone from current status and time in Spain, with explicit caution flags for counting issues.
| Name | Required | Description | Default |
|---|---|---|---|
| current_status | Yes | Current Spanish immigration or nationality status. | |
| years_in_spain | Yes | Years already spent in Spain under the relevant stay or residence history. | |
| nationality_track | No | Optional nationality timeline group for a more specific nationality answer. | |
| has_absence_concerns | No | Whether absences or continuity problems may weaken the residence or nationality clock. | |
| special_nationality_basis | No | Optional basis for the one-year nationality track when that exception is being claimed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| summary | Yes | Short explanation of where the person sits on the path. |
| milestones | Yes | Key milestones on the path. |
| next_steps | Yes | Immediate next steps. |
| references | Yes | Secondary Legal Fournier references. |
| review_level | Yes | How much human review is still advisable before treating the result as filing-ready. |
| caution_notes | Yes | Important cautions. |
| decision_trace | Yes | Structured trace of the main timing factors. |
| key_rules_applied | Yes | Stable rules applied by the tool. |
| nationality_status | Yes | Nationality stage given the provided track information. |
| related_resource_uris | Yes | Canonical MCP resources an agent can read next without leaving the server. |
| official_legal_sources | Yes | Official legal sources anchoring the residence and nationality timeline analysis. |
| suggested_follow_up_tools | Yes | Tool calls that are likely to advance the analysis. |
| current_verification_flags | Yes | Live-verification warnings for route, continuity, or timing issues. |
| permanent_residency_status | Yes | Long-term residence stage. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by mentioning 'explicit caution flags for counting issues,' which goes beyond the annotations. 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 sentence of 20 words, front-loaded with the key action ('explain the next ... milestone'), and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (2 required, 3 with enums), an output schema exists (though not shown), the description is complete enough. It captures the core function and hints at output traits (caution flags). A slightly more detailed mention of the output's structure could improve it, but current is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by framing the parameters within the overall goal ('explain... milestone') and hinting at caution flags, which relates to has_absence_concerns and other parameters. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to explain the next permanent-residency or nationality milestone from current status and time in Spain. It uses specific verbs and resources, and the context (siblings like get_visa_options, check_beckham_eligibility) confirms it is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like get_visa_options or explain_nie_process. The purpose is clear, but no guidance on exclusions or when-not-to-use is provided, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_visa_optionsGet Visa OptionsARead-onlyIdempotentInspect
Rank Spain residence routes using evergreen logic and return decision traces, next actions, and canonical MCP resources for the leading branches.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | Main relocation intent. | |
| nationality | Yes | Applicant nationality as a country name or ISO-style country code. | |
| income_source | Yes | Main source of income for the move. | |
| employer_location | No | Where the main employer or client base is located, if known. | |
| has_eu_family_link | No | Whether an EU family-member route may need separate review. | |
| investment_profile | No | Whether the investment plan is passive or tied to an operating business. | |
| has_spanish_job_offer | No | Whether the applicant already has a Spanish job offer. | |
| eu_family_relationship | No | Optional relationship label when an EU-family route may be relevant. |
Output Schema
| Name | Required | Description |
|---|---|---|
| references | Yes | Secondary Legal Fournier references, demoted behind MCP-native context. |
| next_actions | Yes | Next actions to progress the analysis. |
| review_level | Yes | How much human review is still advisable before treating the result as filing-ready. |
| general_notes | Yes | General notes that apply across the route list. |
| ranked_routes | Yes | Ranked visa or residence routes. |
| decision_trace | Yes | Structured trace of the main route-selection factors. |
| profile_summary | Yes | One-line summary of the screened profile. |
| ruled_out_routes | Yes | Common routes ruled out by stable legal logic. |
| key_rules_applied | Yes | Stable rules that drove the recommendation. |
| related_resource_uris | Yes | Canonical MCP resources an agent can read next without leaving the server. |
| official_legal_sources | Yes | Official legal sources that anchor the recommendation. |
| suggested_follow_up_tools | Yes | Tool calls that are likely to advance the analysis. |
| current_verification_flags | Yes | Live-verification warnings for volatile or fact-sensitive points. |
| nationality_classification | Yes | High-level nationality bucket used by the route logic. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds value by disclosing that it returns decision traces, next actions, and canonical MCP resources, and uses 'evergreen logic' indicating dynamic reasoning. 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 sentence that is front-loaded with the core action ('Rank Spain residence routes') and efficiently includes key outputs. Every part 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?
Given the tool's complexity (8 parameters, output schema exists) and the annotations, the description is fairly complete. It covers purpose, logic, and outputs. However, it could briefly explain 'evergreen logic' or provide more context on the ranking criteria, but it does not hinder usability.
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 description does not need to explain parameters. It adds no additional meaning beyond the schema, which already describes each parameter. Baseline score 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 it ranks Spain residence routes and returns decision traces, next actions, and MCP resources. It uses a specific verb ('rank') and resource ('Spain residence routes'), and distinguishes from sibling tools like get_residency_path by focusing on ranking with decision traces.
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 ranking residence routes but does not explicitly state when to use this tool versus alternatives like get_residency_path or check_beckham_eligibility. No guidelines on prerequisites or 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.
route_to_legal_fournier_helpRoute To Legal Fournier HelpARead-onlyIdempotentInspect
Decide whether a Spain legal matter should be escalated to Legal Fournier and return a service match, preparation checklist, and ready-to-send handoff message.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Area of Spain legal help that needs human escalation. | |
| urgency | No | How quickly the user needs human help. | |
| blockers | No | Known blockers that make a self-serve answer less reliable. | |
| already_filed | No | Whether the user already has a live filing, notice, denial, or active procedure. | |
| preferred_language | No | Preferred language for the human handoff. |
Output Schema
| Name | Required | Description |
|---|---|---|
| summary | Yes | Short explanation of the handoff recommendation. |
| urgency | Yes | Urgency level used for the handoff recommendation. |
| why_now | Yes | Reasons supporting escalation. |
| references | Yes | Secondary Legal Fournier references for the handoff. |
| booking_url | Yes | Preferred consultation-booking URL when the user wants direct legal advice now. |
| intake_fields | Yes | Structured intake payload an agent can map into a contact form, CRM, or booking handoff. |
| should_escalate | Yes | Whether human escalation is recommended from the supplied facts. |
| what_to_prepare | Yes | What the agent should gather for the handoff. |
| recommended_service | Yes | |
| agent_handoff_message | Yes | Ready-to-send summary an agent can reuse when escalating to Legal Fournier. |
| related_resource_uris | Yes | Canonical MCP resources an agent can read next without leaving the server. |
| representation_notice | Yes | Legal notice explaining that contact or booking does not itself create representation. |
| suggested_follow_up_tools | Yes | Tool calls that are likely to advance the analysis. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description only adds that it returns structured output. It does not elaborate on behavioral aspects beyond what annotations supply, such as side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose and output, front-loaded with the key decision. Somewhat dense but not verbose; could be slightly improved by breaking into bullet points for clarity.
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 five parameters (one required, three enums) and existence of an output schema, the description adequately covers the tool's function and outputs. Lacks explicit handling of edge cases but is sufficient for a decision-oriented 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?
Input schema covers 100% of parameters with descriptions; the tool description adds no extra meaning or constraints beyond what the schema already provides. 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?
Describes specific decision-making action ('decide whether...should be escalated') and lists concrete outputs (service match, checklist, handoff message), clearly distinguishing it from sibling tools that perform other tasks like eligibility checks or direct contact requests.
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?
Implies usage context (escalation decisions for Spain legal matters) but provides no explicit guidance on when to use this tool versus siblings such as find_legal_fournier_tool or create_legal_fournier_contact_request. No exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_legal_fournier_toolRun Legal Fournier ToolARead-onlyIdempotentInspect
Run a Legal Fournier public calculator or screener directly inside MCP, returning intake screening, missing facts, complexity flags, and handoff guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| facts | No | General facts for the direct MCP screening run. | |
| numbers | No | Optional numeric facts for calculator-style intake. | |
| tool_id | Yes | Public Legal Fournier tool to run directly inside MCP. | |
| user_goal | No | Natural-language user goal or case summary. | |
| complexity_signals | No | Signals that should trigger human review. | |
| preferred_language | No | Preferred public page language for selected_url. |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | Public tool title. |
| outcome | Yes | Direct MCP screening outcome. |
| summary | Yes | Short explanation of the direct MCP run. |
| tool_id | Yes | Tool that was run directly in MCP. |
| handoff_url | Yes | Legal Fournier consultation handoff URL. |
| legal_notice | Yes | General legal notice agents must preserve. |
| next_actions | Yes | Immediate next actions for the agent. |
| selected_url | Yes | Best public URL after applying preferred language. |
| missing_facts | Yes | Facts the agent should collect before relying on the screening output. |
| numeric_notes | Yes | Calculator-style numeric notes, with current-law caveats. |
| update_policy | Yes | How this direct MCP runner should be updated and verified. |
| handoff_reason | Yes | Reason for the handoff recommendation or caveat. |
| public_tool_url | Yes | Canonical English public tool URL. |
| complexity_flags | Yes | Signals that make human review advisable. |
| related_mcp_tools | Yes | Other MCP tools paired with this direct run. |
| selected_language | Yes | Language used for selected_url. |
| handoff_recommended | Yes | Whether the direct MCP run recommends Legal Fournier human review. |
| related_resource_uris | Yes | Canonical MCP resources an agent can read next without leaving the server. |
| direct_screening_notes | Yes | Direct MCP screening notes and usage caveats. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is a safe read. The description adds behavioral context by detailing the types of outputs (intake screening, missing facts, complexity flags, handoff guidance), which goes 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 a single sentence that is clear and free of redundancy. It is concise and to the point, though it could be slightly more structured by separating the action from the outputs.
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 6 parameters, full schema coverage, and presence of annotations and output schema, the description is adequately complete. It explains what the tool does and what it returns, but does not mention that the tool_id must be one from a specific enum list, though this is captured 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 coverage is 100%, with all 6 parameters described in the schema. The description adds no additional parameter-specific information, so it meets the baseline of 3 without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a Legal Fournier public calculator or screener, specifying the verb 'run' and the resource type. It also lists the return values (intake screening, missing facts, complexity flags, handoff guidance), distinguishing it from sibling tools like 'check_beckham_eligibility' or 'get_visa_options' which are more specific checks.
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 guidance on when to use this tool versus its siblings. It does not mention prerequisites, exclusions, or conditions that would help an agent decide between 'run_legal_fournier_tool' and alternatives like 'find_legal_fournier_tool' or 'check_beckham_eligibility'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!