baseline-mcp
This server provides climate and weather context via MCP tools: historical rankings, forecast context, station cross-checks, and comparisons, and it always includes confidence/reliability notes.
get_climate_context: Ask natural-language questions about weather/climate for any land location, getting 10-day forecasts plus 35-year ranked percentile context.
get_context_for_coordinates: Same climate context for exact latitude/longitude without geocoding (e.g., property, field, trailhead).
get_water_year_status: Water-year precipitation and temperature totals with percentile ranks against 35 historical years, useful for drought monitoring and agriculture.
compare_to_normal: Compare current/forecast temperature or precipitation to 35-year normals and get percentile rankings.
compare_locations: Rank precipitation, temperature, or snowfall across 2–10 locations or curated categories (ski resorts, watersheds, cities, national parks, etc.) over water year, season, month, or ski season.
Responses include explicit reliability statements: near-tie ranks are disclosed, US station cross-checks (ACIS) may confirm or contradict the grid, and seasonal outlooks carry honest skill labels.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@baseline-mcpHow does today's temperature in San Francisco compare to normal?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Baseline Climate
Stop your agent inventing climate context. Ranked 35-year records for any point on Earth, cross-checked against real stations, with an explicit reliability note to relay instead of guess.
Ask it something, and this is what comes back.
A ranking — with the near-tie disclosed, and a station agreeing:
August 2026: Mean temperature was 75°F, +2.8°F from normal, ranking as the 8th warmest since 1991 — though the 7th warmest through 9th warmest years are within 0.7°F of each other. A nearby station (CASPER-NATRONA COUNTY AP, 8.4 mi) agrees: +2.1°F from its own normal, against the reanalysis's +2.8°F.
A station that does not agree — the gauge a mile away read half the grid's total:
March 2026: Precipitation totaled 2.30 in — near average for this period historically. A nearby station (BOZEMAN MONTANA STATE UNIVERSITY, 1.3 mi) measured 1.12 in, against the reanalysis's 2.30 in.
A wind ranking that says plainly it is modeled, not measured:
March 2026: Modeled peak gust: 60 mph, ranking as the 3rd gustiest since 1991 — though it's within 1 mph of the 6th gustiest year. A station (Saratoga, 32.1 mi) measured a peak gust of 59 mph. The reanalysis figure is a modeled estimate, not a direct reading.
A seasonal outlook carrying its own skill label:
Leaning wetter than normal for Sep–Nov in Nairobi, on odds we haven't been able to verify here — below normal 5%, near normal 19%, above normal 76%. Forecasts here do track wetter and drier seasons, so the direction is the part worth using; whether the percentages themselves beat a climatological guess has not been shown.
Four things worth noticing. It gives you the rank, not just the number. It tells you when the rank is a near-tie, so you don't over-read it. It goes and asks a real weather station whether the gridded record is right — and when the station disagrees, it says so rather than papering over it. And when it can't vouch for its own forecast, it tells you that too.
The data isn't new. Asking it a question is.
ERA5 has been sitting in public archives for years. Interrogating it meant knowing which dataset, writing the code, and having an afternoon. That cost is what collapsed — and the interesting consequence is that people now ask things they'd never have thought worth the trouble.
The Bozeman example above isn't a weather lookup. It's a construction schedule dispute, where the question was whether rain actually stopped work — and the gridded record said one thing while the gauge a mile away said another. The wind example is a trucking corridor. Neither would have been worth opening a climate dataset for. Both take a sentence now.
That's the claim: not that historical weather data exists, but that the cost of asking it a real question has fallen far enough that weather becomes one ordinary input into questions that aren't about weather.
Related MCP server: mcp-weather
What it won't claim
Most tools hand you a number. This one hands you the number and its standing.
Near-ties are disclosed. "8th warmest — though the 7th through 9th are within 0.7°F" stops a model reporting a rank as though it were a meaningful gap.
Station disagreement moves confidence, and says which way. A gauge reading 1.12 in against a grid's 2.30 in is reported, not averaged away.
When no cross-check ran, it says why — no nearby station, outside the covered region, source didn't respond. The gap is named rather than left for the model to fill.
Seasonal outlooks carry an honest skill label. Calibrated from ECMWF SEAS5 against 35 years of observations, then labelled by what testing actually showed: that the odds beat a climatological guess here, or that only the direction is worth using, or — where a simple warming trend predicted the season better than the model did — that the model isn't the thing to go on. We publish the cases where our own forecast isn't the best available answer.
Every response carries an assessment field with Baseline Climate's own confidence statement, and
the tool descriptions instruct the model to relay it rather than compose its own. That exists
because the failure mode is real: given a bare number, models invent records that weren't broken,
assert a dataset is unreliable somewhere it isn't, and recycle one station disagreement across
unrelated answers.
What it's made of
Global daily record | ERA5-Land reanalysis, 0.1°, 1991–present, land-only |
Station cross-check | ACIS (NOAA RCC). United States only — outside the US, answers say plainly that no station check ran |
Seasonal outlook | ECMWF SEAS5, calibrated per region. Precipitation only — temperature has not yet cleared our skill test, and we don't issue one until it does |
Forecast | Open-Meteo |
Rankings use the full 1991–present record; "normal" means the WMO 1991–2020 reference period. See METHODOLOGY.md for how rankings, percentiles and water years are computed, and where the limits are.
Tools
get_climate_context— a natural-language question; forecast plus 35-year ranked context.get_context_for_coordinates— the same for an exact lat/lon.get_water_year_status— precipitation and temperature since the start of the water year, ranked against 35 years.compare_to_normal— how unusual near-term conditions are at one location.compare_locations— rank precipitation, temperature or snowfall across 2–10 locations, or a curated category, over a water year, season, month or ski season.
Install
Requires an API key. Self-serve signup isn't available yet — email Chad McNutt (chadmcnutt@gmail.com) during this early period.
pip install baseline-mcp # or: uvx baseline-mcpClaude Code
claude mcp add baseline \
--env BASELINE_API_URL=https://api.baselinecontext.com \
--env BASELINE_API_KEY=your-key-here \
-- uvx baseline-mcpClaude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"baseline": {
"command": "uvx",
"args": ["baseline-mcp"],
"env": {
"BASELINE_API_URL": "https://api.baselinecontext.com",
"BASELINE_API_KEY": "your-key-here"
}
}
}
}Cursor — .cursor/mcp.json, same shape as above.
Contributing
This package is a thin translation layer: no climate logic lives here, and every tool call is an
HTTP request to the Baseline Climate API. See CONTRIBUTING.md in the repository for local
development setup.
MIT licensed.
Available Tools
1 toolget_climate_contextA
Get statistically rigorous weather and climate context for any location on Earth (land only). Answers natural-language questions with 10-day forecast data and historical percentile rankings against a 35-year ERA5 daily climatology (1991-2025, WMO 1991-2020 normals). Use this when you need to know not just what conditions are or will be, but how unusual they are relative to history.
query MUST be phrased as a question in one of these forms (the location goes where LOCATION is shown; the underlying parser matches these patterns specifically and will fail on other phrasings, e.g. "weather context for LOCATION" does not work):
"Will LOCATION be warmer/wetter than normal this week?"
"Has LOCATION been dry this water year?" / "this year?"
"How cold/warm/wet was last winter/spring/summer/fall in LOCATION?"
"What is the wettest/driest month in LOCATION?"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description must disclose all behaviors. It specifies 'land only', data sources (ERA5, WMO normals), and query format requirements. It also transparently notes that alternative phrasings will fail, giving clear behavioral expectations.
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?
Description is two efficient paragraphs: first states core purpose and data context, second provides vital usage guidelines. Every sentence adds value, no redundancy. Front-loaded with the essential function.
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 the tool's single parameter and presence of an output schema, the description covers all needed aspects: what it does, when to use, how to phrase queries, and failure modes. Nothing essential is missing.
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 has 0% coverage, but description compensates thoroughly by detailing the exact required structure of the 'query' parameter, including multiple valid patterns and explicit examples. This adds essential semantic meaning beyond the bare schema.
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?
Description clearly states it provides statistically rigorous weather/climate context using forecast and historical percentiles. It explicitly contrasts with simple weather queries by emphasizing 'how unusual' conditions are, effectively distinguishing its purpose from basic weather tools.
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?
Explicitly states when to use: needing unusualness relative to history. Provides exact query formats and warns against failing phrasings. No sibling tools exist, but description fully covers usage context and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.1- First observed
get_climate_context
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly defined.
The single tool name 'get_climate_context' follows a clear verb_noun pattern. Consistency is trivial with one tool.
A single tool is too few for what could be a broader climate data server. While the tool is detailed, one tool makes the server feel incomplete and limited in scope.
The tool only handles specific query forms (e.g., 'Will LOCATION be warmer...?') and excludes other natural language questions. There are clear gaps in functionality, such as providing raw data or different time ranges.
Maintenance
Related MCP Connectors
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
The official Model Context Protocol server for Ambee. It gives any MCP-compatible AI assistant — Claude, ChatGPT, Cursor, VS Code, Ollama, and more direct access to live air quality, pollen, and weather data. To get started, including information on signing up and obtaining your Ambee key, check out the Ambee documentation on https://docs.ambeedata.com
Climate MCP — wraps Open-Meteo Climate API (free, no auth)
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables retrieval of historical weather data (temperature, precipitation, conditions, etc.) from Visual Crossing for specified locations and dates.1GPL 3.0
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server built with the mcp-framework to provide weather-related tools and data to AI clients. It enables integration of weather capabilities and custom tools into the MCP ecosystem for use with platforms like Claude Desktop.7 npm-
- AlicenseNot gradedqualityCmaintenanceMCP server for NASA POWER climate data, offering a climatology tool to retrieve long-term monthly averages for any coordinate. Supports natural language queries through the Pipeworx gateway.3 npmMIT
- FlicenseAqualityDmaintenanceA Model Context Protocol (MCP) server that provides weather data using the OpenWeather One Call API 3.0. This server allows AI agents to access current weather, forecasts, and historical weather data for any location.35 npm-