GoodbyeMatrix Residency & Citizenship Index

List CBI programmes

list_cbi_programs

Read-onlyIdempotent

For questions about which citizenship by investment (second passport) programmes exist or what they start from: lists the 9 programmes GoodbyeMatrix prices (St Kitts and Nevis, Antigua and Barbuda, Dominica, Grenada, Saint Lucia, Vanuatu, Sao Tome and Principe, Nauru, Argentina) with region, route (contribution, investment or both), starting amount in USD for a single applicant, professional fee label, processing time, number of visa-free destinations where known, calculator and programme page links, and short notes. 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
`language`	No	Response language: "en" (English, default) or "de" (German).	en

Output Schema

Name	Required	Description
`ok`	Yes
`notice`	No
`schema`	No
`currency`	No
`language`	Yes
`overview`	No
`programs`	Yes
`updatedAt`	No	Data status: the date of the response (UTC, YYYY-MM-DD). Prices and rules are maintained continuously and every response is calculated live, so the data status is the date of the response in every case, not an older date.
`dataStatus`	No	Note on the data status in German and English: calculated live, status = date of the response.
`generatedAt`	No
`documentation`	No
`quoteEndpoint`	No
`rulesChangedAt`	No	Last change to prices or rules (UTC date, YYYY-MM-DD).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 21, 2026

addedOutput schema / properties / dataStatus

Added value: +{
+  "description": "Note on the data status in German and English: calculated live, status = date of the response.",
+  "properties": {
+    "de": {
+      "type": "string"
+    },
+    "en": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / rulesChangedAt

Added value: +{
+  "description": "Last change to prices or rules (UTC date, YYYY-MM-DD).",
+  "type": "string"
+}

addedOutput schema / properties / updatedAt / description

Added value: +"Data status: the date of the response (UTC, YYYY-MM-DD). Prices and rules are maintained continuously and every response is calculated live, so the data status is the date of the response in every case, not an older date."

First observedOct 19, 2026

TDQS

A3.9/5.0

Behavior3/5

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

The 'Read-only: only retrieves... stores nothing, sends nothing and calls no external services' sentence largely restates annotations that already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=true, so it adds little beyond structured data. It does not disclose pagination, data freshness, or failure modes for a list tool whose annotations already carry the safety profile.

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 user question it answers, which is the right priority. The long parenthetical enumerating all nine countries and eight output fields is heavy but does communicate scope; it borders on listing returns that the output schema already covers.

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?

An output schema exists, so return values need not be described, yet the description enumerates row fields anyway — redundant but harmless. With the single covered parameter and rich annotations, the definition is sufficient for correct invocation, though the redundancy slightly bloats it.

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?

There is one optional parameter (language) with 100% schema description coverage and an enum, so the schema already fully documents it. The description adds no language-selection guidance or default behavior, so the baseline 3 applies.

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 and resource (lists the 9 CBI programmes GoodbyeMatrix prices) and enumerates the exact programmes and row fields returned. An agent can distinguish it from get_program (single programme), search_programs, and compare_programs without opening any schema.

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?

Gives an explicit trigger: 'For questions about which citizenship by investment programmes exist or what they start from.' That clearly establishes when to reach for this tool, but it never names the sibling to prefer for adjacent intents (e.g. compare_programs, get_program) or states exclusions.

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?