Geo-Parity

Compare climate normals and comfortable days

compare_climate

Read-onlyIdempotent

Monthly climate normals from ERA5 reanalysis (2015-2024) via Open-Meteo: mean daily maximum and minimum temperature, average monthly rainfall, and a count of comfortable days. Pass city (slug) or country (alpha-2) for one place's twelve months — a country answers through a named representative city, because a country does not have one climate. Otherwise cities are ranked by comfortable days, for a single month (1-12) or across the year; the seasonal question is the one people actually have, and an annual total hides it. A comfortable day has a maximum between 18 and 27 C with under 1 mm of rain — a STATED PREFERENCE, not an objective measure: it is temperate-biased and scores hot destinations low on terms they did not agree to, so mean maximum and rainfall travel with every row for callers who want to rank on those instead. ERA5 is reanalysis rather than station observation, which makes it complete and comparable across countries.

Input Schema

Name	Required	Description
`city`	No	City slug (e.g. "lisbon"). Returns that city's twelve months.
`limit`	No	Return at most this many cities.
`month`	No	Rank a single month. Omit to rank on the whole year.
`country`	No	ISO alpha-2. Returns the representative city's months, naming which city.
`minComfortDays`	No	Filter: minimum comfortable days in the ranked window.

Output Schema

Name	Required	Description	Default
`ok`	No
`city`	No
`rows`	No
`month`	No
`updated`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

addedInput schema / examples

Added value: +[
+  {
+    "limit": 15,
+    "month": 1
+  }
+]

First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds genuinely non-obvious context: the ERA5 reanalysis source and 2015-2024 window, the reanalysis-vs-station caveat, and the crucial disclosure that 'comfortable days' is a stated temperate-biased preference rather than an objective measure. It does not describe pagination or the output shape, but the output schema exists, so that is a minor gap.

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?

Well front-loaded — source, metrics, then mode selection, then the caveat. It is on the long side and includes a couple of editorial asides ('the seasonal question is the one people actually have, and an annual total hides it'), but those asides carry routing value rather than padding.

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 annotations carrying safety and an output schema present, the description only needs to supply source provenance, metric definitions, mode routing, and caveats — and it does all four. An agent has everything required to call this correctly and to interpret the ranking honestly.

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 interpretive value beyond the schema: what `country` actually resolves to (a named representative city, since a country has no single climate), and that `minComfortDays` operates over the ranked window. Format details like the slug and alpha-2 forms are already in the schema.

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 (compare monthly climate normals) and enumerates exactly what is returned: mean daily max/min temperature, average monthly rainfall, and a comfortable-day count. It also distinguishes its two operating modes (single-place lookup vs. ranked comparison), which no sibling tool covers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly routes the caller: pass `city` or `country` for one place's twelve months, otherwise cities are ranked. It also explains the `month` vs. year choice and justifies the seasonal default, so an agent knows which path to take without inference.

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?