Geo-Parity

Build a defensible pay range for a role in a country

build_pay_range

Read-onlyIdempotent

Returns a floor, midpoint and ceiling salary for a broad occupation and seniority in a country, anchored on ILO's measured earnings where they exist and on the modelled national wage ladder where they do not — basis says which. Built for the employer side of pay transparency: since 7 June 2026 the EU Pay Transparency Directive has required a starting salary or pay range in the job advert. IT IS NOT LEGAL ADVICE AND DOES NOT CERTIFY COMPLIANCE — it is a market range from official statistics, and every response carries a caveats array saying so, which should be reproduced alongside any figure quoted from it. Seniority is applied as a percentile offset within the country's own distribution rather than a fixed multiplier, so the same level means the same position locally rather than the same ratio. The gender pay gap for the occupation is reported beside the range and never folded into it. ISCO-08 major groups are broad families of work, not job titles.

Input Schema

Name	Required	Description
`country`	Yes	ISO 3166-1 alpha-2 country code (case-insensitive).
`seniority`	No	Defaults to 'mid'. An unrecognised value is rejected.
`occupation`	No	ISCO-08 major group. Defaults to 'total' (all occupations). An unrecognised value is rejected, never widened to the default.

Output Schema

Name	Required	Description
`ok`	No
`year`	No
`basis`	No	'measured' or 'modelled' — never blurred.
`floor`	No
`caveats`	No	Always present. Reproduce these with any quoted figure.
`ceiling`	No
`country`	No
`midpoint`	No
`seniority`	No
`occupation`	No
`genderGapPct`	No
`occupationMedianMonthlyUsd`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

addedInput schema / examples

Added value: +[
+  {
+    "country": "DE",
+    "occupation": "professionals",
+    "seniority": "senior"
+  }
+]

AddedSep 2, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description adds rich behavioral context beyond the annotations: it explains the floor/midpoint/ceiling output, the basis field, the caveats array that should be reproduced, how seniority is applied as a percentile offset, and that gender pay gap data is reported separately. These details help an agent understand the tool's limitations and usage constraints.

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?

The description is front-loaded with the core output before moving to use case, caveats, and methodology. It is dense and somewhat long, but most sentences add substantive context for this legal-adjacent, statistics-based tool.

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?

With rich annotations and an output schema, the description covers the remaining important context: methodology, legal disclaimer, required caveats, interpretation of seniority, and occupation group limitations. Nothing essential for correct invocation appears to be 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 meaningful semantic detail. It clarifies that seniority is a local percentile offset rather than a fixed multiplier and that ISCO-08 major groups are broad families of work, not job titles.

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

Purpose4/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: it returns floor, midpoint and ceiling salary for a broad occupation and seniority in a country. It clearly defines scope, including ILO measured vs modelled basis, but does not explicitly differentiate this tool from similar siblings such as calculate_wage_bands or compare_occupation_pay.

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 a clear use context: employer-side pay transparency and EU job-advert requirements. It also warns that it is not legal advice and does not certify compliance. However, it does not name alternative tools or explicitly state when a different sibling should be used instead.

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?