GoodbyeMatrix Residency & Citizenship Index

Explain a glossary term

explain_term

Read-onlyIdempotent

Explains a term on relocation, residency, citizenship, tax and asset protection from the GoodbyeMatrix glossary (more than 120 terms, for example golden visa, 183-day rule, tax residency certificate, flag theory) with the glossary page in German and English. The definition is returned in the requested language (English or German); a term without an English entry yet comes with the German definition and a note. Related terms are listed when the search term matches several entries. Read-only: it only retrieves and computes from the GoodbyeMatrix data set, stores nothing, sends nothing and calls no external services.

Input Schema

Name	Required	Description	Default
`term`	Yes	Term in English or German, for example "183-day rule" or "Wegzugsbesteuerung".
`language`	No	Response language: "en" (English, default) or "de" (German).	en

Output Schema

Name	Required	Description
`ok`	Yes
`term`	No
`tool`	No
`found`	Yes
`stand`	Yes	Date of the source data (YYYY-MM-DD).
`notice`	Yes	General information, not legal, tax or immigration advice.
`schema`	No
`related`	No
`language`	Yes
`definition`	No
`glossaryPage`	No
`definitionNote`	No	Only when the English definition is not available yet and the German one is returned.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedOutput schema / properties / definitionNote

Added value: +{
+  "description": "Only when the English definition is not available yet and the German one is returned.",
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld=false, and the description still adds real behavior: language fallback (German definition plus a note when no English entry exists) and related-term listing on multi-match. The closing read-only sentence largely restates the annotations, but the fallback and multi-match behavior go meaningfully beyond them.

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

Conciseness4/5

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

Front-loaded with the core action and glossary scope, then behavior, then the safety note. Most sentences earn their place, though the final 'stores nothing, sends nothing and calls no external services' clause is partially redundant with the annotations.

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

Completeness5/5

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

An output schema exists, so return-value formats need not be described. The description covers coverage scope, language handling, fallback behavior and multi-match related terms — enough for an agent to call it correctly with no open questions.

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

Parameters4/5

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

Schema coverage is 100% (baseline 3), and the description adds meaning on top: it explains the observable effect of the language parameter, including the German fallback with a note, which the schema's enum/default does not convey. The term parameter's format is left to the schema and its own examples.

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?

Specific verb (explains) plus resource (a glossary term from the GoodbyeMatrix glossary), with concrete example terms. It is unmistakably distinct from the sibling program/quote/consultation tools, which handle program comparison and quoting rather than glossary definitions.

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

Usage Guidelines3/5

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

Usage is implied by the glossary framing and the term examples, and the fallback rule hints at what to expect. However, it never states when to reach for this tool versus siblings like get_program or search_programs, nor any exclusions, so the agent must infer the boundary.

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

All GoodbyeMatrix Residency & Citizenship Index 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?