Geo-Parity

Compare Housing Costs & Affordability

compare_housing

Read-onlyIdempotent

Housing cost and affordability across countries, built for remote workers. Returns monthly rent plus TWO ratios that together answer the real question: rent as a share of the LOCAL median wage (are locals priced out?) and as a share of YOUR remote income (can you afford it?). The gap between them - arbitrageGap, in percentage points - is the single number saying whether a place is cheap FOR YOU; pass remoteIncome to get it. Also returns price-to-income and price-to-rent as a percentage of each country's OWN long-run average (OECD), and mortgage rates (ECB, euro area only; absent elsewhere rather than estimated). IMPORTANT: those affordability percentages compare a country with its own history, NOT with other countries - 127 for Spain means 27% less affordable than Spain's norm, not 27% dearer than Germany. Every rent carries rentBasis: 'measured' where a real Eurostat city figure exists (Spain, Portugal, Switzerland only) or 'modelled' from the site's price basket, which understates housing by up to ~40% where housing has decoupled from the general price level. National averages; not financial advice.

Input Schema

Name	Required	Description	Default
`sort`	No	'affordability' = rent as a share of your remote income, lowest first (falls back to raw rent when no income given); 'rent' = monthly rent; 'localBurden' = rent as a share of the local median wage; 'priceToIncome' = price-to-income vs long-run average.	affordability
`flatM2`	No	Flat size in m² used to convert measured per-m² rents. Default 70; echoed back so the assumption is visible.
`country`	No	Optional ISO 3166-1 alpha-2 code; echoes that country's row and rank.
`remoteIncome`	No	Your monthly income in USD, earned remotely. Enables rentPctOfYourIncome and arbitrageGap; omit for the local-only view.
`maxRentPctOfIncome`	No	Optional filter: keep only countries where rent is at most this percentage of your remote income. Requires remoteIncome.

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: +[
+  {
+    "remoteIncome": 6000,
+    "sort": "affordability"
+  }
+]

First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses data provenance (Eurostat, OECD, ECB), that euro-area-only mortgage rates are simply absent rather than estimated, that 'modelled' rent understates housing by up to ~40%, that percentages are country-relative not cross-country, and a 'not financial advice' disclaimer. This is exactly the kind of context annotations 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?

Dense but front-loaded: the core value proposition and the gap metric come first, with caveats (OECD interpretation, rentBasis, modelled understatement) following. Each sentence adds interpretive value, though the block is long enough that a reader must work to parse it.

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?

For a 5-parameter, zero-required, output-schema-backed tool, this is complete: it covers what is returned, how the key derived metric is produced, the data sources, and the interpretation traps. Nothing an agent needs to call or interpret it 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 real meaning: it explains what `remoteIncome` unlocks (`rentPctOfYourIncome`, `arbitrageGap`) and clarifies that the affordability ratios are self-referential. It doesn't restate every field, which is appropriate given the schema already covers them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('housing cost and affordability across countries') and carves out a niche against siblings like compare_food_cost and compare_total_cost by naming the exact question it answers (local burden vs. remote-income affordability and the `arbitrageGap`). An agent can distinguish it 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.

Usage Guidelines4/5

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

Gives clear conditional usage guidance for the key parameter ('pass `remoteIncome` to get it'), distinguishing the local-only view from the personal-affordability view. It never explicitly names an alternative sibling tool or a when-not-to-use condition, so it stops short of a 5.

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?