Citizenship by descent (Ireland, Canada) plus sourced visa rules for Americans moving abroad.
Scored across 6 tools
The six tools have largely distinct jobs: listing pathways, checking eligibility, fetching pathway requirements, listing visa options, fetching a visa checklist, and retrieving rule changes. The only plausible confusion is between get_pathway_requirements and get_move_checklist because both return documents/cost/processing details, but their domain (descent pathway vs specific visa_id) is clearly stated.
All names use lowercase snake_case with a leading action verb (check_, get_, list_) followed by a clear noun phrase. No mixed conventions or vague verbs are present.
Six tools is well within the appropriate range for an advisory research server. Each tool covers a distinct operation in the citizenship/visa research workflow, with no obvious filler.
The core workflows are covered: discover pathways/visas, check descent eligibility, get requirements/checklists, and review recent rule changes. Minor gaps remain, such as no dedicated recent-change feed for citizenship-by-descent rules and no separate visa-detail tool beyond the option list and checklist, but these are workable.
Check whether a person qualifies for citizenship by descent.
Input is the person's direct ancestral line, one entry per generation,
starting with relation='self'. Every generation between the person and
the ancestor is required, because descent passes generation by generation
and a gap changes the answer.
Exact dates give the most precise result. Year-only input is accepted and
the result carries a caveat; for Ireland, a registration and a birth in the
same year cannot be resolved.
Args:
country: ISO 3166-1 alpha-2, lowercase. Currently 'ie' or 'ca'.
line: The direct line, from the user upward.
as_of: Evaluation date. Defaults to today. Rules with commencement
dates (Canada's Bill C-3) depend on it.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| as_of | No | ||
| country | Yes |
| Name | Required | Description |
|---|---|---|
| caveats | No | Approximations and unresolvable ambiguities in the input. |
| missing | No | |
| sources | No | Law and official guidance the rules were built from. |
| verdict | Yes | One-line plain reading of the confidence band. |
| blockers | No | |
| rationale | Yes | |
| confidence | Yes | green, yellow, or red |
| disclaimer | Yes | |
| learn_more | Yes | |
| pathway_id | Yes | |
| next_action | No | |
| country_code | Yes | |
| supporting_facts | No | |
| rules_verified_as_of | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond annotations: every generation must be supplied, exact dates improve precision, year-only input produces a caveat, and as_of affects commencement-date rules like Canada's Bill C-3.
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 front-loaded with purpose, then immediately explains input shape and date precision caveats. The Args section is focused, with no obvious filler, though the multiple caveat sentences make it slightly longer than strictly necessary.
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 the description need not explain return values. It covers the critical input constraints and evaluation-date behavior well; the main remaining gap is explicit guidance on when this tool is chosen over sibling tools.
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?
Top-level schema description coverage is reported as low, so description compensation matters. The description documents country as lowercase ISO alpha-2 with supported values 'ie' and 'ca', explains that line is ordered from the user upward with relation='self' first, and clarifies that as_of defaults to today and matters for commencement-date rules.
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: checking whether a person qualifies for citizenship by descent. It distinguishes itself from siblings like get_pathway_requirements and list_pathways by focusing on eligibility evaluation for a specific ancestral line.
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 tool's purpose and input requirements, but the description does not explicitly say when to use this tool versus alternatives such as get_pathway_requirements or list_pathways. There are no stated exclusions or routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step-by-step application checklist for one visa, with sources.
Takes a visa_id such as 'es_dnv' or 'pt_d7'. Also returns the fees and any
recent rule changes for that visa.
| Name | Required | Description | Default |
|---|---|---|---|
| visa_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds meaningful payload context (checklist steps with sources, fees, recent rule changes), but says nothing about what happens with an unknown or malformed visa_id.
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 short sentences, purpose front-loaded, parameter example next, secondary return content last. No filler or restatement of the tool name.
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?
A single-parameter read tool with an output schema, so return values need no explanation; the description covers purpose, ID format, and the extra payload. The only real gap is not telling the agent how to obtain a valid visa_id.
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 0%, so the description carries the full burden and does supply concrete ID examples ('es_dnv', 'pt_d7'), which is exactly the missing information. It stops short of saying where valid visa_ids come from (presumably get_visa_options) or that exactly one ID is accepted.
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+resource with scope: a step-by-step application checklist for exactly one visa, including sources. The resource (checklist) is clearly distinct from sibling concerns (eligibility, pathways, rule changes, visa options), though the description does not explicitly name a sibling to route away from.
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 'for one visa' and the example IDs, but there is no explicit when-to-use/when-not, nor any mention of how it relates to get_rule_changes despite the description saying it also returns recent rule changes — a genuine ambiguity an agent must resolve on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Documents, cost, and processing time for a supported descent pathway.
Covers the documents to gather, fees, typical processing time and common pitfalls, with official sources.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful content-scope context (it returns documents, fees, processing time, pitfalls and official sources) but says nothing about freshness, whether results are cached, or any prerequisite that a pathway must first be identified.
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?
It is short with no wasted words, and the content list is front-loaded. However, the two-line sentence fragment lacks an explicit action statement, so brevity comes at the cost of a clear entry point.
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 explained, and annotations cover the safety posture. What is missing for this simple one-parameter read tool is the meaning of 'country', the relationship to list_pathways/check_descent_eligibility, and any scope note such as whether all countries are supported.
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 0% and the sole required parameter is 'country', which the description never mentions. Worse, the tool name implies a pathway identifier is needed while the schema only accepts a country, so the description leaves the key semantic question (how the pathway is specified) unresolved.
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 names the resource (descent pathway requirements) and enumerates its contents (documents, fees, processing time, pitfalls, sources), so the subject matter is clear. But it is written as a noun phrase describing the payload rather than a verb+resource action, and it does nothing to separate it from siblings like get_visa_options or check_descent_eligibility.
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?
There is no statement of when to call this versus check_descent_eligibility, list_pathways, get_visa_options, or get_move_checklist. An agent must infer that it comes after eligibility/pathway selection, and nothing confirms or denies that ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent changes to visa and residence rules that GoThere has verified.
Newest first. Each entry has the old and new value and the official source.
Args:
country: Optional ISO alpha-2 code or English name.
since: Optional date; only changes on or after it are returned.
limit: Maximum entries, 1 to 100. Default 20.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| country | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing ordering ('newest first'), the shape of each entry (old value, new value, official source), and that entries are pre-verified. It does not mention pagination or what an empty result means.
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 what the tool actually returns, then ordering, then entry shape, then a compact Args block. Every sentence adds information; nothing is padded or restated from the schema.
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 needn't explain return values, and it still sketches the entry shape. All three optional parameters are documented with defaults and bounds, and ordering is stated, leaving no ambiguity about how to call it 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 0%, so the description must carry the full burden and it does: country accepts an ISO alpha-2 code or English name, since is an inclusive lower bound date, and limit is bounded 1-100 with a default of 20. These constraints (acceptance formats, inclusivity, max bound) go beyond what the bare schema titles convey.
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 ('recent changes to visa and residence rules') plus a scope qualifier ('verified by GoThere'), which an agent can distinguish from siblings like get_visa_options or get_pathway_requirements. It never names an alternative tool explicitly, so it stops short of the 5 benchmark.
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: filters are optional and the tool returns a chronological list, so an agent can infer this is for checking what changed rather than for looking up current requirements. There is no explicit 'use this instead of X when...' guidance and no exclusion criteria against the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Residence visas GoThere has researched for Americans moving abroad.
Covers Spain, Ireland, Italy, Mexico and Portugal today. Each option
carries the income threshold, fees, processing time, years to permanent
residence and citizenship, each with its source URL and the date it was
last checked.
Args:
country: Optional ISO alpha-2 code or English name, e.g. 'es' or 'Spain'.
category: Optional 'digitalNomad', 'passiveIncome' or 'work'.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the data is researched, limited to five countries, and each record carries a source URL and a last-checked date, which tells the agent about freshness and provenance.
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 and coverage, then the returned fields, then a compact Args block. Every sentence carries information, though the Args section restates parameter names in a slightly verbose docstring style.
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 enumerated, yet the description still names the key fields (income threshold, fees, processing time, years to PR/citizenship, source URL, last checked). Combined with the country coverage list and parameter semantics, an agent has everything needed to call it 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 description coverage is 0%, so the description must carry the load, and it does: country is documented as an ISO alpha-2 code or English name with examples ('es' or 'Spain'), and category enumerates the three valid values ('digitalNomad', 'passiveIncome', 'work') that the schema does not constrain. It stops short of stating that both are optional filters and what the unfiltered default returns.
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+resource ('Residence visas GoThere has researched') and immediately scopes it to Americans moving abroad plus the five covered countries. An agent can tell this apart from siblings like list_pathways or get_pathway_requirements because it is explicitly a researched-options lookup with per-option data fields.
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 country/category args suggest filtering, but the description never says when to call this versus list_pathways or get_pathway_requirements, nor what happens when a country is not covered. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the citizenship-by-descent pathways this server can evaluate.
Returns each supported pathway with its summary, official sources and verification date. Countries marked 'planned' have no rules implemented yet and are listed so their status is clear.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description nevertheless adds real behavioral content: it says each entry carries a summary, official sources and a verification date, and it explains the 'planned' status as having no rules implemented yet — a semantic that is not derivable from the schema or annotations.
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 short sentences, front-loaded with the verb and resource. The clause 'and are listed so their status is clear' is mildly redundant with the preceding statement that they are listed, but the rest of the sentence carries unique information about unimplemented rules.
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 an output schema exists and annotations are rich, the description does the remaining work: it names the fields the agent will see and pre-explains the one surprising state ('planned' with no rules). The only gap is the absence of a pointer to the natural next call, which would make the discovery flow self-contained.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly does not waste text on inputs and instead spends it on what the call returns.
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 ('List the citizenship-by-descent pathways') plus a scope qualifier ('this server can evaluate'), which is far more than a restatement of the name. It does not explicitly contrast itself with siblings like get_pathway_requirements or check_descent_eligibility, so an agent must infer that this is the enumeration/discovery tool, but the inference is easy.
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 'list' framing plus the note about 'planned' countries suggests this is the entry point before calling requirements or eligibility tools, but no sentence says when to use this instead of a sibling or what to do next. No exclusions, no prerequisites, no alternative routing.
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.
check_descent_eligibility4 fields changedInput schema / $defs / LineMember / properties / birth_country / descriptionPrevious value: -"ISO 3166-1 alpha-2 country of birth, e.g. 'IE', 'CA', 'US'. For Northern Ireland use 'IE' — Irish nationality law counts all 32 counties."New value: +"ISO 3166-1 alpha-2 country of birth, e.g. 'IE', 'CA', 'US'. Northern Ireland counts as 'IE': Irish nationality law covers all 32 counties."Input schema / $defs / LineMember / properties / relation / descriptionPrevious value: -"Where this person sits on your direct line. Use exactly one 'self'."New value: +"Where this person sits on the direct line. Exactly one entry is 'self'."Output schema / properties / caveats / descriptionPrevious value: -"Approximations and unresolvable ambiguities in the input. Relay these."New value: +"Approximations and unresolvable ambiguities in the input."Output schema / properties / sources / descriptionPrevious value: -"Law and official guidance the rules were built from. Cite these."New value: +"Law and official guidance the rules were built from."check_descent_eligibility2 fields changedOutput schema / $defsAdded value: +{
+ "Source": {
+ "properties": {
+ "title": {
+ "title": "Title",
+ "type": "string"
+ },
+ "type": {
+ "description": "'official' or 'secondary'",
+ "title": "Type",
+ "type": "string"
+ },
+ "url": {
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url",
+ "type"
+ ],
+ "title": "Source",
+ "type": "object"
+ }
+}Output schema / properties / sourcesAdded value: +{
+ "description": "Law and official guidance the rules were built from. Cite these.",
+ "items": {
+ "$ref": "#/$defs/Source"
+ },
+ "title": "Sources",
+ "type": "array"
+}get_move_checklistget_rule_changesget_visa_optionslist_pathways3 fields changedOutput schema / $defs / PathwayInfo / properties / rules_verified_as_ofAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Rules Verified As Of"
+}Output schema / $defs / PathwayInfo / properties / sourcesAdded value: +{
+ "items": {
+ "$ref": "#/$defs/Source"
+ },
+ "title": "Sources",
+ "type": "array"
+}Output schema / $defs / SourceAdded value: +{
+ "properties": {
+ "title": {
+ "title": "Title",
+ "type": "string"
+ },
+ "type": {
+ "description": "'official' or 'secondary'",
+ "title": "Type",
+ "type": "string"
+ },
+ "url": {
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url",
+ "type"
+ ],
+ "title": "Source",
+ "type": "object"
+}check_descent_eligibilityget_pathway_requirementslist_pathwaysResidency programmes, golden visas, second passports and citizenship by investment in 80+ countries
Verified residency, citizenship, tax and banking data for Latin America and Latin Europe.
Citizenship, residency & tax-residency data for 190+ countries, with origin-aware route planning
Read-only migration data: cities, visa routes, entry rules, costs, safety, climate, with sources.
Add one secure layer between your agents and this server.
