Residency programmes, golden visas, second passports and citizenship by investment in 80+ countries
Scored across 9 tools
Most tools target clearly distinct actions (search, get one programme, compare, glossary, country overview, two link generators). The main overlap is between list_cbi_programs, search_programs filtered to citizenship-by-investment, and get_cbi_quote called without a programme, which all surface the same 9 CBI programmes — the descriptions differentiate them (catalogue vs. computed family cost vs. filterable search) but an agent could plausibly misselect for 'which second passport programmes exist and cost'.
Every tool is snake_case with a leading verb (compare_, explain_, get_, list_, request_, search_) followed by a clear noun/object. The verb vocabulary is small and reused predictably, with the two link tools sharing the request_*_link pattern.
Nine tools is well-scoped for a read-only index: discovery (search/list), detail (get_program/get_country_overview), comparison, pricing, glossary and two conversion links. No tool looks redundant or missing from the count perspective.
The surface covers search, list, detail, compare, country context, terminology, indicative cost and consultation/quote handoff — a full read-only lifecycle for an index. Minor gaps: no way to enumerate countries or regions for browsing (search requires a known country/region value), and cost quoting/breakdown links exist only for CBI, not the 170+ residency programmes.
Sets 2 to 5 programmes of the index side by side: type, country, minimum amount, physical presence, time to permanent residency and to citizenship, path to citizenship, dual citizenship, tax system of the country, visa-free destinations and the programme page in German and English, plus the date of the source and consultationNote. Read-only: it only retrieves and computes from the GoodbyeMatrix data set, stores nothing, sends nothing and calls no external services.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | 2 to 5 programme ids (as returned by search_programs). | |
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | No | |
| stand | Yes | Date of the source data (YYYY-MM-DD). |
| notice | Yes | General information, not legal, tax or immigration advice. |
| schema | No | |
| language | Yes | |
| programs | Yes | |
| consultationNote | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description reinforces this with concrete operational context ('retrieves and computes from the GoodbyeMatrix data set, stores nothing, sends nothing and calls no external services'), though it could say more about computation or freshness beyond the source date.
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?
Front-loaded with the core action and scope, followed by a compact behavioral disclaimer. The attribute list is long but earns its place by defining output relevance; no filler sentences.
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 a full output schema, rich input schema, and comprehensive annotations, the description is complete enough for correct invocation. A minor gap is that it does not relate the language parameter to the returned programme-page fields.
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 both parameters are fully documented in the schema. The description adds only the 2-to-5 programme constraint, which the schema already enforces via minItems/maxItems, and does not clarify the language parameter's effect on response content.
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?
States a specific verb and resource ('Sets 2 to 5 programmes ... side by side') and enumerates the compared attributes, clearly distinguishing it from single-programme siblings like get_program and list-oriented search_programs.
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 2-to-5 programme scope implies comparison usage, but the description never explicitly says when to choose this over get_program, list_cbi_programs, or search_programs. Usage is inferable rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| 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. |
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.
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.
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.
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.
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.
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.
Answers how much citizenship by investment or a second passport costs for a person or family, or compares programmes by total cost. Calculates the indicative cost for a family: government contribution, investment, fees, professional fees, payment phases and total in USD, plus which family members are eligible, processing time, page links and quoteRequestUrl. With one programme it returns that programme; without program it compares all 9 programmes (St Kitts and Nevis, Antigua and Barbuda, Dominica, Grenada, Saint Lucia, Vanuatu, Sao Tome and Principe, Nauru, Argentina). Nationality and country of birth count for every person in the family, not only for the main applicant. Figures are calculated live at request time from the current GoodbyeMatrix price and rule data; the data status is the date of the response (updatedAt), not an older date. Figures are rounded indicative figures (total to the nearest 1,000 USD), binding only after a pre-check; the user receives the exact amounts by requesting the cost breakdown through quoteRequestUrl. Read-only: it only retrieves and computes from the GoodbyeMatrix data set, stores nothing, sends nothing and calls no external services.
| Name | Required | Description | Default |
|---|---|---|---|
| family | Yes | Everyone who applies together. The first person is the main applicant (role "main"); only the first person has the role "main". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent. Nationalities and country of birth are relevant for every person in the list (partner, children, parents), not only for the main applicant, because exclusions apply per person. | |
| program | No | Programme key: sao_tome (Sao Tome and Principe), vanuatu, dominica, st_lucia (Saint Lucia), st_kitts (St. Kitts and Nevis), grenada, antigua (Antigua and Barbuda), nauru, argentina. Without a programme, the figures cover all programmes at once. | |
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| pages | No | |
| route | No | |
| scope | Yes | |
| total | No | Total in USD, rounded to the nearest 1,000. |
| notice | No | |
| schema | Yes | |
| status | No | ok, partial, review_required, fees_on_request or not_eligible (main applicant excluded by nationality or country of birth: no figures, no link). |
| program | No | Programme key. |
| variant | No | |
| currency | No | |
| language | Yes | |
| programs | No | |
| rounding | No | |
| 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. |
| totalScope | No | total, or known_costs when professional fees are on request. |
| costSummary | No | contribution, investment and professionalFees as published; fees = total minus the other three. |
| eligibility | No | |
| generatedAt | No | |
| overviewUrl | No | Portfolio only: overview page of all programmes with the family filled in. |
| programLabel | No | |
| paymentPhases | No | |
| pricingNotice | No | |
| processingTime | No | |
| rulesChangedAt | No | Last change to prices or rules (UTC date, YYYY-MM-DD). |
| quoteRequestUrl | No | Link to the calculator page of the programme on goodbyematrix.com with the family already filled in; there the user requests the detailed cost breakdown with the exact amounts. null when not_eligible. |
| restrictionNote | No | Only with status not_eligible: why the programme is not possible. |
| websiteEstimate | No | The figure the website calculator shows. |
| restrictionsChecked | No | true when nationalities or a country of birth were given and checked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: figures are computed live from current price/rule data, updatedAt reflects the response date, amounts are rounded to the nearest 1,000 USD, and figures are only binding after a pre-check via quoteRequestUrl. The closing 'stores nothing, sends nothing, calls no external services' sentence largely restates the readOnly/closed-world annotations, slightly diluting the added value.
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?
Purpose and both operating modes are front-loaded and the sentences are information-dense. Some waste remains: the parenthetical list of all 9 programme names duplicates the enum descriptions in the schema, and the read-only sentence duplicates the annotations.
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?
Covers inputs, both modes, computation freshness, rounding/binding caveats, and the follow-up path (quoteRequestUrl) for exact figures. With an output schema present, no return-value documentation is owed, and nothing an agent needs to invoke it correctly is missing.
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 already 100%, so baseline is 3, but the description adds genuinely load-bearing semantics: nationality and country of birth apply to every family member, not just the main applicant, and exclusions apply per person. This flags a non-obvious input requirement that agents could easily miss otherwise.
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?
States the concrete question it answers ('how much citizenship by investment or a second passport costs') plus the second mode (comparing programmes by total cost), with a specific verb+resource. It is clearly distinguishable from siblings like compare_programs and get_program.
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?
Explicitly defines the two modes: with a programme it returns that programme, without one it covers all 9 programmes. However, it never mentions the sibling compare_programs, which plausibly overlaps with the 'compare all programmes' mode, and gives no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarises a country for moving abroad: tax system (residence-based, territorial, no income tax, remittance basis or citizenship-based), the residency and citizenship by investment programmes of the index in that country with their programme pages, and the GoodbyeMatrix climate map, plus the date of the source and consultationNote. Covers about 200 countries. Read-only: it only retrieves and computes from the GoodbyeMatrix data set, stores nothing, sends nothing and calls no external services.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country as ISO 3166-1 alpha-2 code (for example "PA") or name in English or German. | |
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | No | |
| stand | Yes | Date of the source data (YYYY-MM-DD). |
| notice | Yes | General information, not legal, tax or immigration advice. |
| schema | No | |
| country | Yes | |
| language | Yes | |
| taxSystem | No | |
| climateMap | No | |
| cbiPrograms | No | |
| consultationNote | Yes | |
| residencyPrograms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false, idempotentHint and destructiveHint=false, so the closing 'Read-only... stores nothing, sends nothing and calls no external services' largely restates them. What the description does add beyond structured data is the data provenance ('date of the source') and the consultationNote field, which tells the agent what freshness/side-channel content to expect.
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?
Front-loaded with the core purpose in one dense but well-ordered sentence listing the returned sections. The trailing read-only sentence is short but partly redundant with the annotations, keeping it just short of a 5.
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?
An output schema exists, so return shape needs no explanation, and both parameters are fully documented in the schema. The description supplies scope (~200 countries), content coverage and read-only guarantees; only the absence of sibling routing guidance keeps it from the top.
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% and both parameters (country code/name, language) are fully documented in the schema, including the ISO-3166 example and the enum. The description adds nothing about parameter format or behaviour, so the baseline of 3 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?
States a specific verb and resource ('Summarises a country for moving abroad') and enumerates the contents: tax system, CBI/RBI programmes, climate map, source date. It is clearly distinct from programme-level siblings like get_program or get_cbi_quote, though it never names an alternative explicitly.
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 phrase 'for moving abroad' and 'Covers about 200 countries' implies the audience and scope, but there is no explicit instruction on when to use this versus get_program or compare_programs. Selection has to be inferred from the content list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one programme of the index in detail. Residency programmes: minimum amount and investment options, physical presence, time to permanent residency and to citizenship, dual citizenship, settlement area, tax system of the country, steps and excerpts of the GoodbyeMatrix programme texts (overview, qualification, costs, benefits, citizenship timeline, legal basis). Citizenship by investment programmes: routes with starting amounts, visa-free destinations, status (cost calculator, on request, coming soon or closed) and official links. Includes the programme page in German and English, the date of the source and consultationNote. Read-only: it only retrieves and computes from the GoodbyeMatrix data set, stores nothing, sends nothing and calls no external services.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Programme id from search_programs or get_country_overview, or a programme name (word order and country codes are tolerated). | |
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | No | |
| stand | Yes | Date of the source data (YYYY-MM-DD). |
| notice | Yes | General information, not legal, tax or immigration advice. |
| schema | No | |
| program | Yes | The programme; null when the name matches several programmes (see candidates). |
| language | Yes | |
| candidates | No | Only when the name matches several programmes: up to 5 matching programmes with their ids. |
| cbiQuoteNote | No | Only for the 9 programmes with a cost calculator: get_cbi_quote calculates the costs for a specific family. |
| consultationNote | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the bar is lower, but the description still adds real context: it clarifies that the tool 'computes from the GoodbyeMatrix data set', stores nothing, sends nothing and calls no external services, and it notes the source date and consultationNote in the payload. It stops short of mentioning latency, caching, or failure behavior for unknown ids.
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?
Front-loaded and organized by programme type, but the long enumeration of returned fields (overview, qualification, costs, benefits, citizenship timeline, legal basis) is largely duplicated by the output schema. The trailing read-only sentence repeats the annotation hints, adding length without much new selection 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?
With an output schema present, the description need not explain return values, yet it still sketches the payload shape and states the language and source-date fields, which helps an agent decide whether to call it. Only the absence of sibling routing and unknown-id behavior keeps it from a 5.
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% and both parameters are fully documented in the schema, including the enum and default for language. The description adds no syntax or format guidance for 'id' beyond what the schema already says, so the baseline 3 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?
Opens with a specific verb and resource ('Returns one programme of the index in detail') and then breaks down exactly what that means for the two programme categories. It never names a sibling (get_country_overview, compare_programs, search_programs) so the boundary between 'one programme in detail' and the country-level or comparison tools is left implicit.
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?
Usage is only implied: the detail-oriented phrasing plus the schema note that ids come from search_programs or get_country_overview suggests a follow-up call after discovery. There is no explicit statement of when to prefer this over compare_programs or get_country_overview, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| 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). |
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.
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.
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.
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.
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.
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.
Use only when the user explicitly asks to speak with GoodbyeMatrix. Returns the URL of the GoodbyeMatrix consultation page (German or English) and the topics a call covers. The link carries no personal data. Read-only: it returns a URL only; nothing is sent, booked or stored.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | No | |
| stand | Yes | Date of the source data (YYYY-MM-DD). |
| covers | No | |
| notice | Yes | General information, not legal, tax or immigration advice. |
| schema | No | |
| language | Yes | |
| consultationUrl | Yes | |
| languagesOffered | No |
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 beyond that by disclosing privacy behavior ('The link carries no personal data') and explicitly stating 'nothing is sent, booked or stored', which reassures the agent that no side effects occur. It does not discuss failure modes or the URL's lifecycle.
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?
Three tight sentences with the gating condition front-loaded, followed by return content and the no-side-effects note. Every sentence carries information, though the read-only/link sentence partially overlaps the readOnlyHint annotation.
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 zero-required-parameter, read-only lookup with an output schema, the description covers what an agent needs: when to call it, what comes back, and that nothing is stored or transmitted. Return-value detail is rightly left to the output 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 description coverage is 100%, and the single 'language' parameter is fully documented with its enum and default. The description's '(German or English)' only restates what the schema already conveys, so the baseline 3 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?
The description states a specific verb and resource: it returns the URL of the GoodbyeMatrix consultation page plus the topics a call covers. That resource is clearly distinct from siblings such as request_cost_breakdown_link or get_program, so an agent can route without opening the schema.
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?
It gives an explicit gating condition: 'Use only when the user explicitly asks to speak with GoodbyeMatrix.' That is a real when-to-use rule with an implied when-not (do not offer unprompted). It stops short of naming an alternative sibling, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns only the personal link (quoteRequestUrl) for one programme and family: the calculator page on goodbyematrix.com with the family already filled in, where the user requests the detailed cost breakdown with the exact amounts by e-mail from the GoodbyeMatrix team. The link carries the family only, never contact details; the user enters their contact details on that page, checks them and sends the request personally; the privacy consent is never preselected. Read-only: it returns a URL only; nothing is sent, booked or stored.
| Name | Required | Description | Default |
|---|---|---|---|
| family | Yes | Everyone who applies together. The first person is the main applicant (role "main"); only the first person has the role "main". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent. Nationalities and country of birth are relevant for every person in the list (partner, children, parents), not only for the main applicant, because exclusions apply per person. | |
| program | Yes | Programme key: sao_tome (Sao Tome and Principe), vanuatu, dominica, st_lucia (Saint Lucia), st_kitts (St. Kitts and Nevis), grenada, antigua (Antigua and Barbuda), nauru, argentina. | |
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| Name | Required | Description |
|---|---|---|
| program | Yes | |
| language | Yes | |
| programLabel | No | |
| quoteRequestUrl | Yes | Link to the calculator page with the family filled in, where the user enters their contact details and requests the detailed cost breakdown by e-mail. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses meaningful behavior: the link carries family data only (never contact details), the user enters and confirms contact details themselves, the privacy consent is never preselected, and nothing is sent or stored. These privacy and consent guarantees are exactly the context annotations cannot convey.
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?
Front-loads the essential fact (returns only the personal link) in the first clause, then adds privacy caveats. It is one long sentence-like block, slightly dense, but every clause earns its place and nothing is redundant.
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, rich annotations, and full schema coverage, the description fills the remaining gaps: what the URL is, what data it does and does not carry, and the consent/non-sending guarantees. An agent has everything needed to decide and invoke correctly.
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 program, family and language semantics are fully documented in the schema itself. The description only reinforces that the link 'carries the family' already filled in; it adds no field-level guidance beyond the schema, so baseline 3 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?
States a precise verb and resource ('Returns only the personal link (quoteRequestUrl)') and scopes it to one programme and family, naming the concrete artifact and the page it points to. The 'only ... link' framing makes clear it is not the quote itself, distinguishing it from get_cbi_quote.
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?
Explains the use case clearly: the user wants to request a detailed cost breakdown by e-mail and the agent supplies the prefilled calculator page. It implicitly contrasts with amount-returning siblings via 'returns only ... nothing is sent, booked or stored', but does not explicitly name an alternative tool for getting actual amounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the public programmes of the GoodbyeMatrix index: more than 170 residency programmes in more than 80 countries (golden visa or residence by investment, digital nomad visa, independent means visa, active investor visa, skilled worker visa) and 20 citizenship by investment (second passport) programmes. Filters: country, region, programme type, maximum budget in USD, path to citizenship and dual citizenship. Returns a page of matching programmes (total, offset, limit, nextOffset) with id, name, country, type, minimum amount, physical presence, path to citizenship, dual citizenship and the programme page in German and English. Read-only: it only retrieves and computes from the GoodbyeMatrix data set, stores nothing, sends nothing and calls no external services.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Programme type: citizenship_by_investment, residence_by_investment (golden visa), digital_nomad, independent_means (retirees, passive income), active_investor (investor and entrepreneur visas) or skilled_work (skilled worker and talent visas). | |
| limit | No | Number of programmes per page (1 to 10, default 10). | |
| offset | No | Start position for the next page (nextOffset of the previous answer). | |
| region | No | Region: europe, americas (including the Caribbean), asia, africa, middle_east or oceania. | |
| country | No | Country as ISO 3166-1 alpha-2 code (for example "PT") or name in English or German. | |
| language | No | Response language: "en" (English, default) or "de" (German). | en |
| max_budget_usd | No | Maximum minimum investment in USD; programmes without a known amount are not matched. | |
| citizenship_path | No | true: programmes with a path to citizenship; false: programmes without one. | |
| dual_citizenship_allowed | No | true: dual citizenship permitted; false: dual citizenship prohibited. Conditional cases match neither. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | No | |
| limit | No | |
| stand | Yes | Date of the source data (YYYY-MM-DD). |
| total | Yes | |
| notice | Yes | General information, not legal, tax or immigration advice. |
| offset | No | |
| schema | No | |
| filters | No | |
| language | Yes | |
| programs | Yes | |
| nextOffset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the closing 'Read-only... stores nothing, sends nothing, calls no external services' sentence mostly restates structured data. It adds modest value by disclosing pagination fields (total, offset, limit, nextOffset) and that budget filtering silently excludes programmes with unknown amounts, but an output schema is present so the field enumeration is largely redundant.
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?
Purpose and scope are front-loaded, which is good, but it is a single dense paragraph and the tail enumerates return fields that the output schema already defines. Trimming that clause would sharpen the definition without losing 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?
With nine optional parameters, full schema coverage, an output schema and rich annotations, the description supplies the one thing structured fields cannot: corpus scale and coverage, plus the set of filterable dimensions. It is essentially complete for correct invocation; only explicit routing against the comparison and detail siblings is missing.
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 all nine parameters including enum meanings, defaults and the ISO/name country formats are already documented in the schema. The description only restates the filter categories at a high level and adds no syntax or edge-case detail (e.g. filter combination behavior) beyond the schema, so the baseline 3 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?
A specific verb-plus-resource statement: it searches the GoodbyeMatrix programme index, with concrete scope (170+ residency programmes, 80+ countries, 20 CBI programmes) and the enumerated filter dimensions. It never names a sibling tool (compare_programs, list_cbi_programs, get_program), so the agent must infer the boundary rather than read it, which keeps it below a 5.
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?
Usage is clearly framed: this is the paginated filtered-search entry point, and the filter list (country, region, type, budget, citizenship path, dual citizenship) tells the agent when this tool fits. There are no explicit exclusions or pointers to alternatives such as compare_programs for side-by-side comparison or get_program for a single record, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_programs2 fields changedOutput schema / properties / programs / items / properties / betragsHauptartAdded value: +{
+ "description": "Residency only: main kind of the headline amount: kapital_angelegt (capital invested and kept), zahlung (payment that is spent: contribution, fee, membership, minimum tax) or nachweis (proof of funds or income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / programs / items / properties / betragsartAdded value: +{
+ "description": "Residency only: kind of the headline amount (minimumAmount or incomeRequirement) as set by GoodbyeMatrix, one of immobilie (property purchase), bankeinlage (bank deposit), anleihen_fonds (bonds or funds), unternehmen (business investment), investition (minimum investment, several routes), staatsbeitrag (government contribution), mitgliedschaft (membership fee), gebuehr (one-time fee), mindeststeuer (minimum tax per year), vermoegen (proof of funds), einkommen (income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}get_country_overview4 fields changedOutput schema / properties / cbiPrograms / items / properties / betragsHauptartAdded value: +{
+ "description": "Residency only: main kind of the headline amount: kapital_angelegt (capital invested and kept), zahlung (payment that is spent: contribution, fee, membership, minimum tax) or nachweis (proof of funds or income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / cbiPrograms / items / properties / betragsartAdded value: +{
+ "description": "Residency only: kind of the headline amount (minimumAmount or incomeRequirement) as set by GoodbyeMatrix, one of immobilie (property purchase), bankeinlage (bank deposit), anleihen_fonds (bonds or funds), unternehmen (business investment), investition (minimum investment, several routes), staatsbeitrag (government contribution), mitgliedschaft (membership fee), gebuehr (one-time fee), mindeststeuer (minimum tax per year), vermoegen (proof of funds), einkommen (income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / residencyPrograms / items / properties / betragsHauptartAdded value: +{
+ "description": "Residency only: main kind of the headline amount: kapital_angelegt (capital invested and kept), zahlung (payment that is spent: contribution, fee, membership, minimum tax) or nachweis (proof of funds or income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / residencyPrograms / items / properties / betragsartAdded value: +{
+ "description": "Residency only: kind of the headline amount (minimumAmount or incomeRequirement) as set by GoodbyeMatrix, one of immobilie (property purchase), bankeinlage (bank deposit), anleihen_fonds (bonds or funds), unternehmen (business investment), investition (minimum investment, several routes), staatsbeitrag (government contribution), mitgliedschaft (membership fee), gebuehr (one-time fee), mindeststeuer (minimum tax per year), vermoegen (proof of funds), einkommen (income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}get_program2 fields changedOutput schema / properties / program / properties / betragsHauptartAdded value: +{
+ "description": "Residency only: main kind of the headline amount: kapital_angelegt (capital invested and kept), zahlung (payment that is spent: contribution, fee, membership, minimum tax) or nachweis (proof of funds or income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / program / properties / betragsartAdded value: +{
+ "description": "Residency only: kind of the headline amount (minimumAmount or incomeRequirement) as set by GoodbyeMatrix, one of immobilie (property purchase), bankeinlage (bank deposit), anleihen_fonds (bonds or funds), unternehmen (business investment), investition (minimum investment, several routes), staatsbeitrag (government contribution), mitgliedschaft (membership fee), gebuehr (one-time fee), mindeststeuer (minimum tax per year), vermoegen (proof of funds), einkommen (income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}search_programs2 fields changedOutput schema / properties / programs / items / properties / betragsHauptartAdded value: +{
+ "description": "Residency only: main kind of the headline amount: kapital_angelegt (capital invested and kept), zahlung (payment that is spent: contribution, fee, membership, minimum tax) or nachweis (proof of funds or income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / programs / items / properties / betragsartAdded value: +{
+ "description": "Residency only: kind of the headline amount (minimumAmount or incomeRequirement) as set by GoodbyeMatrix, one of immobilie (property purchase), bankeinlage (bank deposit), anleihen_fonds (bonds or funds), unternehmen (business investment), investition (minimum investment, several routes), staatsbeitrag (government contribution), mitgliedschaft (membership fee), gebuehr (one-time fee), mindeststeuer (minimum tax per year), vermoegen (proof of funds), einkommen (income). null when not set.",
+ "type": [
+ "string",
+ "null"
+ ]
+}get_cbi_quote6 fields changedInput schema / properties / family / descriptionPrevious value: -"Everyone who applies together. The first person is the main applicant (role \"main\"); only the first person has the role \"main\". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent."New value: +"Everyone who applies together. The first person is the main applicant (role \"main\"); only the first person has the role \"main\". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent. Nationalities and country of birth are relevant for every person in the list (partner, children, parents), not only for the main applicant, because exclusions apply per person."Input schema / properties / family / items / properties / birthplace / descriptionPrevious value: -"Optional: country of birth as ISO 3166-1 alpha-2 code, as mentioned by the user."New value: +"Optional, per person (not only the main applicant): country of birth as ISO 3166-1 alpha-2 code, as mentioned by the user."Input schema / properties / family / items / properties / nationalities / descriptionPrevious value: -"Optional: every citizenship of this person as ISO 3166-1 alpha-2 codes (for example [\"DE\"] or [\"RU\", \"GE\"] for dual citizens), as mentioned by the user."New value: +"Optional, per person (partner, children and parents included, not only the main applicant): every citizenship of this person as ISO 3166-1 alpha-2 codes (for example [\"DE\"] or [\"RU\", \"GE\"] for dual citizens), as mentioned by the user."Output schema / properties / dataStatusAdded 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"
+}Output schema / properties / rulesChangedAtAdded value: +{
+ "description": "Last change to prices or rules (UTC date, YYYY-MM-DD).",
+ "type": "string"
+}Output schema / properties / updatedAtAdded value: +{
+ "description": "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.",
+ "type": "string"
+}list_cbi_programs3 fields changedOutput schema / properties / dataStatusAdded 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"
+}Output schema / properties / rulesChangedAtAdded value: +{
+ "description": "Last change to prices or rules (UTC date, YYYY-MM-DD).",
+ "type": "string"
+}Output schema / properties / updatedAt / descriptionAdded 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."request_cost_breakdown_link3 fields changedInput schema / properties / family / descriptionPrevious value: -"Everyone who applies together. The first person is the main applicant (role \"main\"); only the first person has the role \"main\". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent."New value: +"Everyone who applies together. The first person is the main applicant (role \"main\"); only the first person has the role \"main\". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent. Nationalities and country of birth are relevant for every person in the list (partner, children, parents), not only for the main applicant, because exclusions apply per person."Input schema / properties / family / items / properties / birthplace / descriptionPrevious value: -"Optional: country of birth as ISO 3166-1 alpha-2 code, as mentioned by the user."New value: +"Optional, per person (not only the main applicant): country of birth as ISO 3166-1 alpha-2 code, as mentioned by the user."Input schema / properties / family / items / properties / nationalities / descriptionPrevious value: -"Optional: every citizenship of this person as ISO 3166-1 alpha-2 codes (for example [\"DE\"] or [\"RU\", \"GE\"] for dual citizens), as mentioned by the user."New value: +"Optional, per person (partner, children and parents included, not only the main applicant): every citizenship of this person as ISO 3166-1 alpha-2 codes (for example [\"DE\"] or [\"RU\", \"GE\"] for dual citizens), as mentioned by the user."request_cost_breakdown_link4 fields changedInput schema / properties / contactRemoved value: -{
- "additionalProperties": false,
- "description": "Optional. Contact details are used only as the user has provided them in this conversation and wants to pass them on to GoodbyeMatrix; the link works without them. They prefill the request form on the page; they are not part of the link and the user still checks and sends the request personally.",
- "properties": {
- "email": {
- "maxLength": 254,
- "type": "string"
- },
- "first_name": {
- "maxLength": 60,
- "type": "string"
- },
- "last_name": {
- "maxLength": 60,
- "type": "string"
- },
- "phone": {
- "description": "With international dialling code, for example +49 151 2345678.",
- "maxLength": 40,
- "type": "string"
- }
- },
- "type": "object"
-}Output schema / properties / contactPrefilledRemoved value: -{
- "description": "Only when contact was given: true if at least one contact field was accepted and will prefill the form.",
- "type": "boolean"
-}Output schema / properties / ignoredFieldsRemoved value: -{
- "description": "Only when contact was given: contact fields that were invalid and dropped.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / quoteRequestUrl / descriptionPrevious value: -"Link to the calculator page with the family filled in, where the user requests the detailed cost breakdown by e-mail."New value: +"Link to the calculator page with the family filled in, where the user enters their contact details and requests the detailed cost breakdown by e-mail."compare_programs3 fields changedInput schema / properties / ids / items / descriptionPrevious value: -"Programme id as returned by search_programs or get_country_overview (for example \"portugal__portugal_golden_visa\" or \"grenada\"); a programme name is matched as well."New value: +"Programme id from search_programs or get_country_overview, or a programme name (word order and country codes are tolerated)."Output schema / properties / programs / items / properties / yearsToCitizenshipAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / programs / items / properties / yearsToCitizenshipTextAdded value: +{
+ "description": "Published wording when the years to citizenship depend on nationality or other conditions.",
+ "type": "string"
+}explain_term1 field changedOutput schema / properties / definitionNoteAdded value: +{
+ "description": "Only when the English definition is not available yet and the German one is returned.",
+ "type": "string"
+}get_program6 fields changedInput schema / properties / id / descriptionPrevious value: -"Programme id as returned by search_programs or get_country_overview (for example \"portugal__portugal_golden_visa\" or \"grenada\"); a programme name is matched as well."New value: +"Programme id from search_programs or get_country_overview, or a programme name (word order and country codes are tolerated)."Output schema / properties / candidatesAdded value: +{
+ "description": "Only when the name matches several programmes: up to 5 matching programmes with their ids.",
+ "items": {
+ "properties": {
+ "country": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "typeLabel": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / program / descriptionAdded value: +"The programme; null when the name matches several programmes (see candidates)."Output schema / properties / program / properties / yearsToCitizenshipAdded value: +{
+ "description": "Shortest published number of years to citizenship.",
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / program / properties / yearsToCitizenshipTextAdded value: +{
+ "description": "Published wording when the years to citizenship depend on nationality or other conditions.",
+ "type": "string"
+}Output schema / properties / program / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]compare_programs1 field changedOutput schema / properties / programs / items / properties / type / enumPrevious value: -[
- "citizenship_by_investment",
- "residence_by_investment",
- "digital_nomad",
- "independent_means",
- "active_investor"
-]New value: +[
+ "citizenship_by_investment",
+ "residence_by_investment",
+ "digital_nomad",
+ "independent_means",
+ "active_investor",
+ "skilled_work"
+]get_country_overview2 fields changedOutput schema / properties / cbiPrograms / items / properties / type / enumPrevious value: -[
- "citizenship_by_investment",
- "residence_by_investment",
- "digital_nomad",
- "independent_means",
- "active_investor"
-]New value: +[
+ "citizenship_by_investment",
+ "residence_by_investment",
+ "digital_nomad",
+ "independent_means",
+ "active_investor",
+ "skilled_work"
+]Output schema / properties / residencyPrograms / items / properties / type / enumPrevious value: -[
- "citizenship_by_investment",
- "residence_by_investment",
- "digital_nomad",
- "independent_means",
- "active_investor"
-]New value: +[
+ "citizenship_by_investment",
+ "residence_by_investment",
+ "digital_nomad",
+ "independent_means",
+ "active_investor",
+ "skilled_work"
+]get_program1 field changedOutput schema / properties / program / properties / type / enumPrevious value: -[
- "citizenship_by_investment",
- "residence_by_investment",
- "digital_nomad",
- "independent_means",
- "active_investor"
-]New value: +[
+ "citizenship_by_investment",
+ "residence_by_investment",
+ "digital_nomad",
+ "independent_means",
+ "active_investor",
+ "skilled_work"
+]search_programs3 fields changedInput schema / properties / type / descriptionPrevious value: -"Programme type: citizenship_by_investment, residence_by_investment (golden visa), digital_nomad, independent_means (retirees, passive income) or active_investor (investor and entrepreneur visas)."New value: +"Programme type: citizenship_by_investment, residence_by_investment (golden visa), digital_nomad, independent_means (retirees, passive income), active_investor (investor and entrepreneur visas) or skilled_work (skilled worker and talent visas)."Input schema / properties / type / enumPrevious value: -[
- "citizenship_by_investment",
- "residence_by_investment",
- "digital_nomad",
- "independent_means",
- "active_investor"
-]New value: +[
+ "citizenship_by_investment",
+ "residence_by_investment",
+ "digital_nomad",
+ "independent_means",
+ "active_investor",
+ "skilled_work"
+]Output schema / properties / programs / items / properties / type / enumPrevious value: -[
- "citizenship_by_investment",
- "residence_by_investment",
- "digital_nomad",
- "independent_means",
- "active_investor"
-]New value: +[
+ "citizenship_by_investment",
+ "residence_by_investment",
+ "digital_nomad",
+ "independent_means",
+ "active_investor",
+ "skilled_work"
+]compare_programsexplain_termget_cbi_quoteget_country_overviewget_programlist_cbi_programsrequest_consultation_linkrequest_cost_breakdown_linksearch_programsVerified residency, citizenship, tax and banking data for Latin America and Latin Europe.
Citizenship by investment and second passport costs for 9 programmes, per family, with eligibility.
Citizenship, residency & tax-residency data for 190+ countries, with origin-aware route planning
Off-plan and ready property in the UAE, Oman, Georgia, Cyprus, Bali, Thailand and London.
Add one secure layer between your agents and this server.
