Geo-Parity

What It Costs to Arrive

arrival_cost

Read-onlyIdempotent

The cash needed to ARRIVE somewhere, as opposed to what a month costs once you live there: the entry fee for a given passport, the first month's rent, the deposit, and a long-stay visa fee where one has been verified against the issuing government. READ complete BEFORE totalUsd. Rent covers a subset of the country spine and most visa fees could not be verified, so the total is a FLOOR whenever complete is false, and missing names every component that could not be priced. The total can legitimately be 0 - visa-free entry into a country with no rent figure sums to nothing known - which is honest arithmetic and a false headline. depositMonths is a STATED ASSUMPTION, not a measurement: no free global dataset of deposit norms exists. The entry route itself is derived exactly from passport mobility data, so 'for this passport, this destination is visa-free' is always answered even when no fee is.

Input Schema

Name	Required	Description
`income`	No	Monthly remote income in USD. Optional; enables housing's income-relative view but is not needed for the arrival total.
`passport`	Yes	ISO alpha-2 of the traveller's passport, e.g. 'US'. Determines the entry route and therefore the fee.
`destination`	Yes	ISO alpha-2 of the destination. Must be in the PPP country registry; some countries with a verified nomad-visa fee (e.g. BB) are not and appear only in find_nomad_visas.
`depositMonths`	No	Months of rent held as a deposit. Defaults to the site's stated assumption of 1; override it if you know the market.

Output Schema

Name	Required	Description	Default
`ok`	No
`rows`	No
`focus`	No
`updated`	No
`excluded`	No
`attribution`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

addedInput schema / examples

Added value: +[
+  {
+    "destination": "GB",
+    "passport": "US"
+  }
+]

First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on genuinely new behavior: the total is a FLOOR whenever `complete` is false, `missing` enumerates every unpriced component, a total of 0 is legitimate-but-misleading, and `depositMonths` is a stated assumption rather than a measurement. This is exactly the kind of context structured fields cannot carry.

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?

It is front-loaded with the core definition and each sentence carries distinct information — floor semantics, missing list, zero-total caveat, deposit assumption, entry-route derivation. It is dense and leans on emphatic capitals, but avoids padding; only minor tightening is possible.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, and the description instead supplies the interpretive frame the output requires (complete/missing/floor logic). For a 4-parameter required-passport/destination tool, nothing an agent needs to invoke or read the result correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it says the entry route is 'derived exactly from passport mobility data' and explains the rationale for `depositMonths` ('no free global dataset of deposit norms exists'), which the schema does not state. The `destination` parameter gains nothing new over the schema's registry note.

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?

The description states a specific verb and resource — 'the cash needed to ARRIVE somewhere' — and immediately contrasts it with 'what a month costs once you live there,' which cleanly separates it from cost-of-living siblings like compare_total_cost. It even enumerates the components the total is built from (entry fee, first month's rent, deposit, verified long-stay visa fee).

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?

It gives operational guidance ('READ `complete` BEFORE `totalUsd`') and routes the agent elsewhere in one case, naming find_nomad_visas for countries absent from the PPP registry. The intended context (pre-move arrival budgeting vs ongoing monthly cost) is clear, though there is no explicit when-not-to-use statement beyond the opening contrast.

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

All Geo-Parity 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?