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 4/5 across 9 of 9 tools scored.
Most tools have clear, distinct purposes (e.g., Beckham eligibility vs. NIE process vs. visa options). However, the three tools involving Legal Fournier (find_legal_fournier_tool, route_to_legal_fournier_help, run_legal_fournier_tool) could cause confusion as they all relate to the same external service, though descriptions help differentiate them.
All tools follow a consistent verb_noun pattern in snake_case (e.g., check_beckham_eligibility, get_residency_path, create_legal_fournier_contact_request). Naming conventions are uniform and predictable.
With 9 tools, the set is well-scoped for a specialized legal advisory server covering residency, visas, tax regimes, and NIE processes, plus contact routing. No tool feels extraneous, and the count is balanced for the domain.
The tools cover major areas (Beckham regime, taxes, NIE, residency, visas, and contact). However, there are notable gaps in specific legal domains like property transactions, inheritance, business law, or litigation. The server seems designed as a triage to an external service, leaving deeper coverage absent.
Available Tools
11 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, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds context about return values (rule trace, review level, canonical MCP resources) but no further behavioral traits like auth needs or rate limits. With annotations covering the core traits, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the purpose and what it returns. Every word earns its place with 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 screening tool with 4 parameters (3 required), full schema coverage, annotations, and an output schema, the description adequately summarizes purpose and output. A brief usage note (e.g., when to choose this over compare_tax_regimes) would make it fully 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%, so the schema already documents each parameter. The tool description does not add any additional meaning beyond what the schema provides. Baseline 3 is correct.
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 (screen, returning) and explicitly names the Beckham regime as the resource. It distinguishes from sibling tools like compare_tax_regimes or get_visa_options, none of which mention this specific eligibility check.
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, nor are there any exclusions or prerequisites mentioned. The description lacks explicit usage context despite sibling tools existing for related tasks.
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, destructiveHint=false, idempotentHint. The description adds value by stating the tool returns 'reasoning, review level, and canonical MCP resources' and clarifies it does not provide rate tables, which goes beyond annotation information.
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 purpose. It is concise but could benefit from slightly more detail on usage 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?
The description adequately covers the tool's purpose and output format. With an output schema present, return values do not need further explanation. It is complete for a conceptual comparison tool among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add further meaning to the parameters beyond what the schema already provides; it only mentions output 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 uses specific verbs ('Compare') and clearly identifies the resources ('Beckham versus standard Spanish resident taxation'), and distinguishes from sibling tools like 'check_beckham_eligibility' which focuses on eligibility, not comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for conceptual comparison ('conceptually, returning reasoning... instead of rate tables') but does not explicitly state when to use this tool versus alternatives (e.g., check_beckham_eligibility) 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.
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. |
| booking_url | Yes | Site-controlled consultation booking URL to offer when the user wants to speak with Legal Fournier now. |
| 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 (readOnlyHint=false, openWorldHint=true) indicate the tool mutates data. The description adds context as a 'consequential action' requiring explicit consent, which goes beyond the minimal annotation info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with purpose and consequential warning. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and usage conditions adequately. With output schema present, return values are not needed. The high parameter count is handled by schema coverage.
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 documents all parameters. The description does not add parameter-specific details, but baseline 3 is appropriate given complete 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 states it creates an 'accepted Legal Fournier lead' after explicit consent, distinguishing it from sibling tools like 'route_to_legal_fournier_help' which likely handle routing instead of creation.
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 limits usage to 'only when the user has asked to contact Legal Fournier and has consented to follow-up'. It warns it's a 'consequential action' but does not mention exclusions or alternative tools.
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=true, idempotentHint=true, destructiveHint=false. Description adds 'stable' which reinforces non-destructive nature but provides no additional behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 18 words, directly states purpose. Every word is necessary; no filler or repetition. Front-loaded with the core action and resource.
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 and zero parameters, the description is complete for its purpose. It explains the three main outputs: workflow, distinctions, and resource. No gaps for this simple, stable 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?
No parameters exist, baseline score is 4. Description adds no parameter info, which is acceptable since schema coverage is 100% and there are no parameters to document.
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 the stable NIE and TIE workflow, key procedural distinctions, and canonical resource. Verbs 'Return' and nouns 'workflow' make purpose precise. Distinct from sibling tools like eligibility checks or tax regime comparisons.
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. Given the tool's nature as an explainer, usage is implied but not differentiated from related tools like get_visa_options or run_legal_fournier_tool.
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 ToolARead-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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond by revealing that the tool matches to a 'public tool page and MCP workflow', providing operational behavior not covered by 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, efficient sentence that immediately communicates the tool's purpose. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters with full schema coverage, annotations, and an existing output schema (not provided but indicated), the description gives a sufficient overall picture. It could mention how to interpret the output, but the output schema likely handles that. Minor 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?
Schema description coverage is 100% (all 6 parameters have descriptions). The description does not add meaning beyond the schema; it simply states the matching function. 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 'Match' and specifies the resource: 'Spain legal, tax, property, business, or private-client case'. It also defines the output as 'best Legal Fournier public tool page and MCP workflow', distinguishing it from sibling tools like 'check_beckham_eligibility' which target specific tasks.
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 over siblings or when not to use it. However, the context of sibling tools (e.g., 'run_legal_fournier_tool', 'route_to_legal_fournier_help') implies that this tool is for initial case matching, but explicit guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paid_call_availabilityGet Paid Call AvailabilityARead-onlyIdempotentInspect
Read live Cal.com availability for the 45-minute agent-paid Legal Fournier consultation. This tool never creates a quote, booking, order, or payment.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End of the availability window as an ISO 8601 date-time. | |
| from | Yes | Start of the availability window as an ISO 8601 date-time. | |
| timezone | Yes | IANA timezone for the customer, such as Europe/Madrid. |
Output Schema
| Name | Required | Description |
|---|---|---|
| slots | Yes | |
| success | Yes | |
| timezone | Yes | |
| openapi_url | Yes | |
| quote_endpoint | Yes | |
| booking_enabled | Yes | |
| duration_minutes | Yes | |
| fulfillment_mode | Yes | |
| payment_endpoint | Yes | |
| fulfillment_notice | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by specifying the source (Cal.com) and the consultation details (45-minute, agent-paid), while annotations already indicate read-only and idempotent behavior. 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?
Two sentences, no redundant words. Both sentences are essential: first states the primary action, second clarifies limitations. Excellent front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema (exists) and annotations, the description fully covers the tool's purpose, constraints, and non-effects. For a simple read-only availability tool, 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?
Schema description coverage is 100% with clear descriptions for from, to, and timezone (ISO 8601, IANA). The description does not add additional parameter meaning beyond the schema, so 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 specifies it reads live availability for a 45-minute agent-paid Legal Fournier consultation and explicitly states it never creates quotes, bookings, orders, or payments, which effectively distinguishes it from sibling tools like create_legal_fournier_contact_request.
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 for when to use (check availability) and what it does not do (no creation of bookings), but does not directly mention specific alternatives or when-not-to-use scenarios, though the negative statement helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paid_consultation_optionsGet Paid Consultation OptionsARead-onlyIdempotentInspect
Discover and arrange paid consultations with Legal Fournier through x402 in USDC on Base. Returns live options for a written email consultation and a 45-minute call, including current prices, fulfillment terms, request schemas, quote endpoints, and payment endpoints. Agents can use the returned HTTPS endpoints, after explicit user authorization, to submit the email consultation or book the call. This MCP tool is read-only and never creates an order or submits payment itself.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| offers | Yes | |
| success | Yes | |
| openapi_url | Yes | |
| settlement_notice | Yes | |
| agent_instructions | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explicitly states the tool is read-only and never creates orders or payment, aligning with annotations. It adds context about returned endpoints requiring user authorization, which goes beyond the annotation 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?
Description is concise, well-structured, and front-loaded. Every sentence adds value: purpose, returned content, usage instructions, and safety note.
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 0 parameters, rich annotations, and presence of output schema, the description provides sufficient context: what is returned, how agents should interact, and safety guarantees. No 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?
Zero parameters, so baseline is 4. Description does not need to add parameter info; schema coverage is 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?
Description clearly states the tool discovers and arranges paid consultations with specific details (email vs call) and returns live options. However, it does not explicitly differentiate from sibling tools like get_paid_call_availability, which may overlap.
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?
Description explains that agents should use the returned endpoints after user authorization to actually book, and that this tool is read-only. It implies when to use it (before booking) but does not state when not to use or name alternatives explicitly.
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 read-only and idempotent behavior. The description adds a behavioral detail: the tool provides 'explicit caution flags for counting issues,' which goes beyond the annotations. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is well-structured and front-loaded with the core purpose. Every part of the sentence 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 description covers the main purpose and a key behavioral aspect (caution flags). Given the complexity of the domain (immigration) and the existence of an output schema, the description is sufficiently complete. It could optionally mention the type of output (e.g., steps or warnings) but is not deficient.
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 documents each parameter. The description mentions 'current status and time in Spain', which maps to two parameters, but does not elaborate on the optional parameters (nationality_track, has_absence_concerns, special_nationality_basis). The description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Explain') and specifies the resource ('next permanent-residency or nationality milestone') with a distinct scope ('from current status and time in Spain'). It also mentions a unique behavior ('explicit caution flags for counting issues'), which differentiates it from sibling tools like 'get_visa_options' or 'explain_nie_process'.
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 provide any guidance on when to use this tool versus alternatives (e.g., instead of 'get_visa_options' or 'check_beckham_eligibility'). There is no mention of prerequisites, limitations, or explicit 'when-to-use' or '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.
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 and idempotentHint=true, indicating no side effects. The description adds behavioral context by mentioning 'evergreen logic' (suggesting stable, up-to-date reasoning) and that it returns decision traces and next actions, which helps the agent understand the output format beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose ('Rank Spain residence routes') and efficiently conveys additional outputs. Every word earns its place, and there is no superfluous 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 tool's complexity (8 parameters, including nested enums and optional fields) and the existence of an output schema (not shown but referenced), the description provides sufficient context about the tool's behavior ('evergreen logic') and outputs (decision traces, next actions, resources). It does not explain the meaning of 'evergreen logic' in detail, but overall it is adequate for an agent to understand the tool's role.
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 input schema already documents all parameters with descriptions. The tool description does not add any additional meaning or constraints for the parameters beyond what is in the schema, so it meets the baseline for high coverage without further improvement.
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 'Rank' and the resource 'Spain residence routes', clearly stating the tool's function. It also specifies that it returns decision traces, next actions, and canonical MCP resources, which distinguishes it from sibling tools like 'check_beckham_eligibility' or 'get_residency_path'.
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 that the tool is used for ranking visa options by providing Spain residence routes based on input parameters, but it does not explicitly state when to use this tool versus alternatives like 'get_residency_path' or 'check_beckham_eligibility'. No usage exclusions or alternative tools are mentioned.
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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is safe. The description adds behavioral context about the return values (service match, checklist, handoff message), which goes beyond annotations. No contradictions or missing disclosures.
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 conveys the main purpose and outputs. It is concise but could be slightly more structured (e.g., split into two sentences). 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?
Given the tool's complexity (5 parameters, 1 required, output schema exists), the description sufficiently covers the decision logic and outputs. It explains the return values even though an output schema is present, which adds completeness. However, it does not explain how the handoff message should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds no additional meaning to individual parameters beyond what the schema provides. It focuses on outputs, not parameter enrichment.
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 ('decide whether to escalate') and resource ('Spain legal matter to Legal Fournier'), and clearly states the outputs (service match, checklist, handoff message). It distinguishes itself from siblings like 'create_legal_fournier_contact_request' and 'run_legal_fournier_tool' by focusing on the triage/decision step.
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 deciding escalation, but does not explicitly state when to use it versus alternatives (e.g., if already decided, use 'create_legal_fournier_contact_request'). No when-not or exclusion criteria are provided.
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 read-only, idempotent, and non-destructive behavior. The description adds value by detailing the return types (intake screening, missing facts, complexity flags, handoff guidance). No contradictions with annotations. It could mention that it does not modify any data, but the annotations cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise sentence that front-loads the core purpose. However, it could be structured to briefly mention key parameters or the enum of tool IDs for clarity. Still efficient and 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?
Despite having 6 parameters, an output schema, and sibling tools, the description provides minimal context. It does not explain how the tool integrates with the user goal or how complexity signals affect output. A more thorough description linking parameters to use cases is needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description does not add further semantic clarification for parameters like 'facts' or 'numbers'. Baseline 3 is appropriate as the description does not compensate or enhance parameter understanding.
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 specifies the verb 'run' and the resource 'Legal Fournier public calculator or screener', and states the tool returns specific outputs like intake screening and complexity flags. This distinguishes it from sibling tools such as 'find_legal_fournier_tool' and 'create_legal_fournier_contact_request'.
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 sibling list implies other tools for discovery or routing, but the description does not clarify when to choose this execution tool over them or what prerequisites (e.g., having a specific tool_id) are needed.
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!