Expatriator Immigration Knowledge

get_procedure_guide

Get a step-by-step guide for a Spanish procedure (booking portals, documents needed, common problems). Use list_procedure_guides for valid codes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "procedure": "<procedure>"
    },
    "name": "get_procedure_guide"
  }
}

Input Schema

Name	Required	Description	Default
`language`	No	Guide language (default en)
`procedure`	Yes	Procedure code, e.g. padron

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 25, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses the nature of the returned content (a step-by-step guide) and the code prerequisite, but says nothing about permissions, rate limits, or whether an invalid code errors versus returning an empty guide.

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

Conciseness5/5

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

Two tightly packed sentences with zero waste; the purpose and returned content are front-loaded before the routing hint.

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

Completeness4/5

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

For a two-parameter read tool with a fully documented schema and no output schema, the description covers the purpose, key output content, and code sourcing. It could specify the default language behavior or error handling, but nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100% – the schema already documents both the procedure code and the language enum with its default. The description adds only the pointer to list_procedure_guides for valid codes, so baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb (Get) and resource (step-by-step guide for a Spanish procedure), and even enumerates the content it returns (booking portals, documents needed, common problems). It distinguishes itself from list_procedure_guides, which it names as the source of valid codes.

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

Usage Guidelines4/5

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

Explicitly routes the agent to list_procedure_guides for valid procedure codes, which is a clear when-to-use-this-other-tool instruction. It does not address search_immigration_knowledge as an alternative, so a small gap remains.

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

All Expatriator Immigration Knowledge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?