The Open-Meteo MCP Server provides comprehensive access to weather, climate, and environmental data from multiple global sources via the Open-Meteo APIs, enabling LLMs to retrieve and analyze meteorological information.
Core Weather Capabilities
Weather Forecast – 7–16 day forecasts (hourly & daily) including temperature, humidity, precipitation, wind, UV index, and more
Weather Archive – Historical ERA5 reanalysis data from 1940 to present for any coordinates
Air Quality – Forecasts for PM2.5, PM10, ozone, nitrogen dioxide, sulphur dioxide, ammonia, dust, and aerosol optical depth
Marine Weather – Wave height, wave period, wave direction, swell data, and sea surface temperature
Elevation – Digital elevation model data for any geographic coordinates
Geocoding – Search locations worldwide by name or postal code to retrieve coordinates and details
Specialized Weather Model Forecasts
DWD ICON (Germany), NOAA GFS (US), Météo-France (AROME/ARPEGE), ECMWF (global), JMA (Japan), MET Norway (Nordic), GEM (Canada)
Advanced Forecasting
Flood Forecast – River discharge and flood forecasts from GloFAS for up to 210 days
Seasonal Forecast – Long-range forecasts up to 9 months ahead
Climate Projections – CMIP6-based projections with customizable warming scenarios
Ensemble Forecast – Multiple model runs to quantify forecast uncertainty
Customization Options
Temperature units (Celsius/Fahrenheit), wind speed units (km/h, m/s, mph, knots), precipitation units (mm/inch), timezone selection, and custom date ranges
Deployment: Runs via npx, npm, Docker, or HTTP transport with Claude Desktop integration and configurable API endpoints.
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., "@Open-Meteo MCP Server what's the 7-day weather forecast for Paris?"
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.
A comprehensive Model Context Protocol (MCP) server that provides access to Open-Meteo weather APIs for use with Large Language Models.
This MCP server provides complete access to Open-Meteo APIs, including:
Weather Forecast (weather_forecast) - Forecasts up to 16 days (7 by default) with hourly and daily resolution
Weather Archive (weather_archive) - Historical ERA5 data from 1940 to present
Air Quality (air_quality) - PM2.5, PM10, ozone, nitrogen dioxide, pollen, European/US AQI indices, UV index and other pollutants
Marine Weather (marine_weather) - Wave height, wave period, wave direction and sea surface temperature
Elevation (elevation) - Digital elevation model data for given coordinates
Geocoding (geocoding) - Search locations worldwide by name or postal code, get coordinates and detailed location information
DWD ICON (dwd_icon_forecast) - German weather service high-resolution model for Europe
NOAA GFS (gfs_forecast) - US weather service global model with high-resolution North America data
Météo-France (meteofrance_forecast) - French weather service AROME and ARPEGE models
ECMWF (ecmwf_forecast) - European Centre for Medium-Range Weather Forecasts
JMA (jma_forecast) - Japan Meteorological Agency high-resolution model for Asia
MET Norway (metno_forecast) - Norwegian weather service for Nordic countries
Environment Canada GEM (gem_forecast) - Canadian weather service model
Flood Forecast (flood_forecast) - River discharge and flood forecasts from GloFAS (Global Flood Awareness System)
Seasonal Forecast (seasonal_forecast) - Long-range forecasts up to ~7 months ahead
Climate Projections (climate_projection) - CMIP6 climate change projections for different warming scenarios
Ensemble Forecast (ensemble_forecast) - Multiple model runs showing forecast uncertainty
Related MCP server: Weather MCP Server
Node.js >= 22.0.0
No installation required! The server will run directly via npx.
npm install -g open-meteo-mcp-server# Clone the repository
git clone https://github.com/cmer81/open-meteo-mcp.git
cd open-meteo-mcp
# Install dependencies
npm install
# Build the project
npm run buildAdd the following configuration to your Claude Desktop config file:
{
"mcpServers": {
"open-meteo": {
"command": "npx",
"args": ["-y", "-p", "open-meteo-mcp-server", "open-meteo-mcp-server"]
}
}
}{
"mcpServers": {
"open-meteo": {
"command": "npx",
"args": ["-y", "-p", "open-meteo-mcp-server", "open-meteo-mcp-server"],
"env": {
"OPEN_METEO_API_URL": "https://api.open-meteo.com",
"OPEN_METEO_AIR_QUALITY_API_URL": "https://air-quality-api.open-meteo.com",
"OPEN_METEO_MARINE_API_URL": "https://marine-api.open-meteo.com",
"OPEN_METEO_ARCHIVE_API_URL": "https://archive-api.open-meteo.com",
"OPEN_METEO_SEASONAL_API_URL": "https://seasonal-api.open-meteo.com",
"OPEN_METEO_ENSEMBLE_API_URL": "https://ensemble-api.open-meteo.com",
"OPEN_METEO_GEOCODING_API_URL": "https://geocoding-api.open-meteo.com",
"OPEN_METEO_FLOOD_API_URL": "https://flood-api.open-meteo.com",
"OPEN_METEO_CLIMATE_API_URL": "https://climate-api.open-meteo.com"
}
}
}
}If you're developing locally or installed from source:
{
"mcpServers": {
"open-meteo": {
"command": "node",
"args": ["/path/to/open-meteo-mcp/dist/index.js"],
"env": {
"OPEN_METEO_API_URL": "https://api.open-meteo.com",
"OPEN_METEO_AIR_QUALITY_API_URL": "https://air-quality-api.open-meteo.com",
"OPEN_METEO_MARINE_API_URL": "https://marine-api.open-meteo.com",
"OPEN_METEO_ARCHIVE_API_URL": "https://archive-api.open-meteo.com",
"OPEN_METEO_SEASONAL_API_URL": "https://seasonal-api.open-meteo.com",
"OPEN_METEO_ENSEMBLE_API_URL": "https://ensemble-api.open-meteo.com",
"OPEN_METEO_GEOCODING_API_URL": "https://geocoding-api.open-meteo.com",
"OPEN_METEO_FLOOD_API_URL": "https://flood-api.open-meteo.com",
"OPEN_METEO_CLIMATE_API_URL": "https://climate-api.open-meteo.com"
}
}
}
}If you're using your own Open-Meteo instance:
{
"mcpServers": {
"open-meteo": {
"command": "npx",
"args": ["-y", "-p", "open-meteo-mcp-server", "open-meteo-mcp-server"],
"env": {
"OPEN_METEO_API_URL": "https://your-meteo-api.example.com",
"OPEN_METEO_AIR_QUALITY_API_URL": "https://air-quality-api.example.com",
"OPEN_METEO_MARINE_API_URL": "https://marine-api.example.com",
"OPEN_METEO_ARCHIVE_API_URL": "https://archive-api.example.com",
"OPEN_METEO_SEASONAL_API_URL": "https://seasonal-api.example.com",
"OPEN_METEO_ENSEMBLE_API_URL": "https://ensemble-api.example.com",
"OPEN_METEO_GEOCODING_API_URL": "https://geocoding-api.example.com",
"OPEN_METEO_FLOOD_API_URL": "https://flood-api.example.com",
"OPEN_METEO_CLIMATE_API_URL": "https://climate-api.example.com"
}
}
}
}The server also supports Streamable HTTP transport for remote deployments. Set the TRANSPORT environment variable to http:
TRANSPORT=http PORT=3000 npx open-meteo-mcp-serverThis starts an Express server on the specified port (default: 3000) with the MCP endpoint at /mcp. The HTTP transport supports session management with unique session IDs per client.
The server binds to
127.0.0.1by default, so it is reachable only from the local machine. To accept connections from other hosts, setHOST=0.0.0.0explicitly. The Docker image already does this, so published ports work without extra configuration.
For production deployments, bind to a reachable interface and enable authentication and rate limiting:
HOST=0.0.0.0 API_KEY=your-secret-key RATE_LIMIT_RPM=60 TRANSPORT=http PORT=3000 npx open-meteo-mcp-serverIf a browser-based client connects to the server, list its origin in ALLOWED_ORIGINS — requests carrying an unlisted Origin header are rejected with 403 as DNS rebinding protection.
Clients must then include the key in every request:
Authorization: Bearer your-secret-key
# or
X-API-Key: your-secret-key# Start in HTTP mode (production)
npm run start:http
# Development with auto-reload in HTTP mode
npm run dev:httpThe server can be easily deployed using Docker.
Pull and run the official image:
# Pull the latest image
docker pull ghcr.io/cmer81/open-meteo-mcp:latest
# Run the container
docker run -d \
--name open-meteo-mcp \
-p 3000:3000 \
ghcr.io/cmer81/open-meteo-mcp:latest
# Check health
curl http://localhost:3000/healthAvailable tags (no v prefix — the git tag v2.0.0 publishes the image as 2.0.0):
latest - Latest stable release
2.0.0 - Specific version
2.0 - Latest 2.0.x release
2 - Latest 2.x.x release
The repository includes two Docker Compose configurations:
Production (uses pre-built image):
# Start with pre-built image from GitHub Container Registry
docker compose up -d
# View logs
docker compose logs -f
# Stop the server
docker compose downDevelopment (builds from source):
# Build and start from local source
docker compose -f docker-compose.dev.yml up -d
# Rebuild after code changes
docker compose -f docker-compose.dev.yml up -d --buildIf you prefer to build the image yourself:
# Build the image
npm run docker:build
# or
docker build -t open-meteo-mcp-server .
# Run the container
npm run docker:run
# or
docker run -p 3000:3000 open-meteo-mcp-serverCopy .env.example to .env and customize as needed:
cp .env.example .env
# Edit .env with your configurationThen update docker-compose.yml to use the .env file or pass environment variables directly.
The HTTP server includes a health check endpoint:
curl http://localhost:3000/health
# Response: {"status":"ok"}This endpoint is used by Docker's HEALTHCHECK and can be integrated with container orchestration platforms (Kubernetes, Docker Swarm, etc.).
All environment variables are optional and have sensible defaults:
OPEN_METEO_API_URL - Base URL for Open-Meteo forecast API (default: https://api.open-meteo.com)
OPEN_METEO_AIR_QUALITY_API_URL - Air quality API URL (default: https://air-quality-api.open-meteo.com)
OPEN_METEO_MARINE_API_URL - Marine weather API URL (default: https://marine-api.open-meteo.com)
OPEN_METEO_ARCHIVE_API_URL - Historical data API URL (default: https://archive-api.open-meteo.com)
OPEN_METEO_SEASONAL_API_URL - Seasonal forecast API URL (default: https://seasonal-api.open-meteo.com)
OPEN_METEO_ENSEMBLE_API_URL - Ensemble forecast API URL (default: https://ensemble-api.open-meteo.com)
OPEN_METEO_GEOCODING_API_URL - Geocoding API URL (default: https://geocoding-api.open-meteo.com)
OPEN_METEO_FLOOD_API_URL - Flood forecast API URL (default: https://flood-api.open-meteo.com)
OPEN_METEO_CLIMATE_API_URL - Climate projection API URL (default: https://climate-api.open-meteo.com)
TRANSPORT - Transport mode: http for Streamable HTTP, omit for stdio (default: stdio)
PORT - HTTP server port when using HTTP transport (default: 3000)
HOST - Interface the HTTP transport binds to (default: 127.0.0.1, loopback only). Set to 0.0.0.0 to accept connections from other machines. The Docker image sets this to 0.0.0.0 already, so published ports work out of the box.
API_KEY - When set, all requests to /mcp must include this key via Authorization: Bearer <key> or X-API-Key: <key>. Leave unset for open access (local/dev mode). Enforced on GET, POST and DELETE alike.
RATE_LIMIT_RPM - Maximum requests per minute per IP (default: 60). HTTP transport only.
TRUSTED_PROXIES - Comma-separated list of trusted proxy IPs or CIDR ranges (e.g. 10.0.0.0/8,172.16.0.0/12). When set, X-Forwarded-For is honoured only for requests originating from these addresses. Leave unset to always use the direct connection IP.
ALLOWED_ORIGINS - Comma-separated list of browser origins permitted to reach the server (e.g. http://localhost:5173,https://app.example). Protects against DNS rebinding: any request carrying an Origin header that is not listed is rejected with 403. Requests without an Origin header — CLI clients and SDK transports — are unaffected. Empty by default.
/health stays reachable without a key and without rate limiting, so container probes keep working.
The skills/ directory contains SKILL.md files that help AI assistants use this MCP server effectively. They act as contextual guides — the AI reads the relevant skill to know which tool to call and how to use its parameters.
Skill | File | Best for |
|
| Everyday weather: forecasts, historical data, air quality, marine conditions, elevation |
|
| Specific models (ECMWF, GFS, DWD ICON…), ensemble uncertainty, seasonal outlooks, climate projections |
Copy the skill(s) to your Claude skills directory:
cp -r skills/open-meteo ~/.claude/skills/
cp -r skills/open-meteo-advanced ~/.claude/skills/This installs them at ~/.claude/skills/open-meteo/SKILL.md and ~/.claude/skills/open-meteo-advanced/SKILL.md. Claude Code will load the relevant skill automatically when you ask weather-related questions.
Upload the SKILL.md file directly as a document in your Claude Desktop conversation:
For everyday weather questions: upload skills/open-meteo/SKILL.md
For model selection, ensemble, or climate projections: upload skills/open-meteo-advanced/SKILL.md
Upload one skill per conversation. The AI will use it as a reference guide throughout the session.
Find the coordinates for Paris, FranceSearch for locations named "Berlin" and return the top 5 resultsWhat are the coordinates for postal code 75001?Search for "Lyon" in France only (countryCode: FR) with results in French (language: fr)Find all cities named "London" in the United Kingdom with English descriptionsCan you get me the weather forecast for Paris (48.8566, 2.3522) with temperature, humidity, and precipitation for the next 3 days?What were the temperatures in London during January 2023?What's the current air quality in Beijing with PM2.5 and ozone levels?Give me the current European AQI, UV index, and pollen levels (birch, grass, ragweed) in Paris.Get me the wave height and sea surface temperature for coordinates 45.0, -125.0 for the next 5 days.Check the river discharge forecast for coordinates 52.5, 13.4 for the next 30 days.Give me the weekly and monthly temperature outlook for Madrid over the next 4 months.Compare the ICON and GFS ensemble forecasts for Berlin over the next 5 days and show the spread across members.Show me temperature projections for New York from 2050 to 2070 using CMIP6 models.latitude : Latitude in WGS84 coordinate system (-90 to 90)
longitude : Longitude in WGS84 coordinate system (-180 to 180)
temperature_2m : Temperature at 2 meters
relative_humidity_2m : Relative humidity
precipitation : Precipitation
wind_speed_10m : Wind speed at 10 meters
wind_direction_10m : Wind direction
pressure_msl : Mean sea level pressure
cloud_cover : Cloud cover percentage
weather_code : Weather condition code
visibility : Visibility
uv_index : UV index
And many more...
temperature_2m_max/min : Maximum/minimum temperatures
precipitation_sum : Total precipitation
wind_speed_10m_max : Maximum wind speed
sunrise/sunset : Sunrise and sunset times
weather_code : Weather condition code
uv_index_max : Maximum UV index
pm10 : PM10 particles
pm2_5 : PM2.5 particles
carbon_monoxide : Carbon monoxide
nitrogen_dioxide : Nitrogen dioxide
ozone : Ozone
sulphur_dioxide : Sulfur dioxide
ammonia : Ammonia
dust : Dust particles
alder_pollen : Alder pollen (Europe only)
birch_pollen : Birch pollen (Europe only)
grass_pollen : Grass pollen (Europe only)
mugwort_pollen : Mugwort pollen (Europe only)
olive_pollen : Olive pollen (Europe only)
ragweed_pollen : Ragweed pollen (Europe only)
european_aqi : European Air Quality Index
european_aqi_pm2_5 : European AQI for PM2.5
european_aqi_pm10 : European AQI for PM10
european_aqi_nitrogen_dioxide : European AQI for NO₂
european_aqi_ozone : European AQI for ozone
european_aqi_sulphur_dioxide : European AQI for SO₂
us_aqi : US Air Quality Index
us_aqi_pm2_5 : US AQI for PM2.5
us_aqi_pm10 : US AQI for PM10
us_aqi_nitrogen_dioxide : US AQI for NO₂
us_aqi_ozone : US AQI for ozone
us_aqi_sulphur_dioxide : US AQI for SO₂
us_aqi_carbon_monoxide : US AQI for CO
uv_index : UV index
uv_index_clear_sky : UV index under clear sky conditions
wave_height : Wave height
wave_direction : Wave direction
wave_period : Wave period
wind_wave_height : Wind wave height
swell_wave_height : Swell wave height
sea_surface_temperature : Sea surface temperature
temperature_unit : celsius, fahrenheit
wind_speed_unit : kmh, ms, mph, kn
precipitation_unit : mm, inch
timezone : Europe/Paris, America/New_York, etc.
forecast_days : Number of forecast days (varies by API)
past_days : Include past days data
start_date / end_date : Date range for historical data (YYYY-MM-DD format)
# Development with auto-reload
npm run dev
# Build TypeScript
npm run build
# Start production server
npm start
# Run tests
npm test
# Type checking
npm run typecheck
# Linting
npm run lintThe evals/ directory holds an LLM-usability benchmark for this server's tools — a different check than npm test. Unit tests verify the code is correct; this verifies that an LLM given only this server's tools (no other context) can actually complete realistic tasks with them.
evals/evaluation.xml — 10 independent, read-only question/answer pairs built on stable historical data (ERA5 archive, CMIP6 projections, geocoding, elevation), so the expected answers never change over time.
evals/scripts/evaluation.py — harness that launches the server, lets an agent answer each question using only its tools, and compares the answer against the expected one.
npm run build
pip install -r evals/scripts/requirements.txt
export ANTHROPIC_API_KEY=your_api_key_here
npm run eval
# or directly:
python3 evals/scripts/evaluation.py -t stdio -c node -a dist/index.js evals/evaluation.xmlThis calls the real Anthropic API for every question, so it consumes tokens/credits — it's a manual quality check for tool design, not part of CI.
When adding, removing, or renaming a tool, or materially changing a tool's description or schema, consider adding or updating a qa_pair in evals/evaluation.xml that exercises it.
src/
├── index.ts # MCP server entry point
├── client.ts # HTTP client for Open-Meteo API
├── tools.ts # MCP tool definitions
├── types.ts # Zod validation schemas
├── truncation.ts # Response size capping and serialization
└── security.ts # Auth, origin validation, rate limiter, IP extractionThis server provides access to all major Open-Meteo endpoints:
Current weather conditions
Hourly forecasts (up to 16 days)
Daily forecasts (up to 16 days)
Historical weather data (1940-present)
High-resolution regional models (DWD ICON, Météo-France AROME)
Global models (NOAA GFS, ECMWF)
Regional specialists (JMA for Asia, MET Norway for Nordics)
Air quality forecasts
Marine and ocean conditions
River discharge and flood warnings
Climate change projections
Ensemble forecasts for uncertainty quantification
Seasonal forecasts for long-term planning
Multiple model comparison
Customizable units and timezones
The server provides comprehensive error handling with detailed error messages for:
Invalid coordinates
Missing required parameters
API rate limits
Network connectivity issues
Invalid date ranges
Tool responses are capped at 25,000 characters so a single wide query cannot overflow an LLM's context. When a response exceeds the limit, the time-series arrays (hourly, daily, minutely_15) are shortened by an equal ratio — keeping every parallel series aligned on the same timestamps — and two fields are added:
{
"truncated": true,
"truncation_message": "Response truncated from 95538 characters to stay within the 25000-character limit. Narrow the request (start_date/end_date, forecast_days, past_days, or fewer variables) to retrieve the full data."
}To get complete data, narrow the request: shorter date range, fewer forecast_days/past_days, or fewer variables.
Efficient HTTP client with connection pooling
Optimized data serialization
Minimal memory footprint
For detailed API documentation, refer to the openapi.yml file and the Open-Meteo API documentation.
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Clone your fork: git clone https://github.com/your-username/open-meteo-mcp.git
Install dependencies: npm install
Create a feature branch: git checkout -b feature/amazing-feature
Make your changes and add tests
Run tests: npm test
Commit your changes: git commit -m 'Add amazing feature'
Push to the branch: git push origin feature/amazing-feature
Open a Pull Request
This project uses automated releases via GitHub Actions. To create a new release:
# For a patch release (1.0.0 -> 1.0.1)
npm run release:patch
# For a minor release (1.0.0 -> 1.1.0)
npm run release:minor
# For a major release (1.0.0 -> 2.0.0)
npm run release:majorThe GitHub Action will automatically:
Run tests and build the project
Publish to npm with provenance
Create a GitHub release
Update version badges
MIT
Get air quality forecast data including PM2.5, PM10, ozone, nitrogen dioxide and other pollutants.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Air quality variables to retrieve | |
| timezone | No | Timezone for timestamps | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the tool retrieves forecast data, but omits details about rate limits, data sources, update frequency, or geographical coverage. The read nature is implied but not explicitly declared.
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?
The description is a single sentence of about 15 words, which is concise and front-loaded. However, it is quite terse and could incorporate usage hints without sacrificing brevity.
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 6 parameters and no output schema, the description is insufficient. It does not explain the forecast time range (covered by forecast_days), output format, or that it provides hourly data. Context is minimal for a tool with moderate complexity.
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 description coverage is 100%, establishing a baseline of 3. The description mentions example pollutants, but these are already covered by the hourly parameter's enum in the schema. No additional semantic information (e.g., coordinate format, default timezone) is added.
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?
The description uses a specific verb ('Get') and resource ('air quality forecast data') while listing key pollutants (PM2.5, PM10, ozone, nitrogen dioxide), which clearly distinguishes this tool from sibling tools like weather_forecast.
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?
No guidance is provided about when to use this tool versus alternatives (e.g., weather_forecast for general weather). There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get climate change projections from CMIP6 models for different warming scenarios.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| daily | Yes | Climate projection variables to retrieve | |
| start_date | Yes | Start date in YYYY-MM-DD format | |
| end_date | Yes | End date in YYYY-MM-DD format | |
| models | Yes | Climate models to use | |
| temperature_unit | No | celsius | |
| wind_speed_unit | No | kmh | |
| precipitation_unit | No | mm | |
| disable_bias_correction | No | Disable statistical downscaling and bias correction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention data latency, processing time, that projections are model-based and not real-time observations, or any limitations on scenario coverage.
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?
A single sentence is concise but lacks structure. It front-loads the core purpose but could benefit from breaking down into key aspects (e.g., supported models, scenario types, geographic scope) for easier parsing.
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 10 parameters (6 required) and no output schema, the description is incomplete. It does not explain coordinate limits, date range restrictions, model combinations, or how 'warming scenarios' translate to input parameters.
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?
The description adds no parameter-specific information beyond the input schema. With 70% schema coverage, the baseline is 3, but the description fails to enhance understanding of parameters like 'disable_bias_correction' or coordinate system details.
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?
The description clearly identifies the tool as retrieving climate change projections from CMIP6 models for different warming scenarios. It distinguishes from weather forecast siblings, although it could mention the specific focus on long-term projections versus short-term forecasts.
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?
No guidance on when to use this tool versus alternatives like seasonal_forecast or ensemble_forecast. Lacks information on prerequisites, such as valid warming scenario selection or model constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast from German DWD ICON model with high resolution data for Europe and global coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions high resolution and coverage but does not disclose any behavioral traits such as data freshness, accuracy, or limitations. There is no mention of destructive potential or authorization needs.
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?
The description is a single sentence that is concise and front-loaded with the purpose. However, it omits crucial usage guidance, making it slightly under-specified for its conciseness.
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?
With 11 parameters, no output schema, and no annotations, the description is insufficient to fully understand the tool's complexity. It lacks details on return values, data range, or how to interpret output, leaving gaps for an AI agent.
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 description coverage is 100%, so baseline is 3. The description adds no additional context beyond what the schema already provides. It does not explain any parameter meaning or usage nuances.
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?
The description clearly states the verb 'Get', the resource 'weather forecast', and identifies the specific model 'German DWD ICON model' with distinguishing features 'high resolution data for Europe and global coverage'. This effectively differentiates it from sibling tools like gfs_forecast or ecmwf_forecast.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives. While 'high resolution data for Europe' implies a use case, it lacks explicit when-to-use, when-not-to-use, or comparison with other forecast tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast from European Centre for Medium-Range Weather Forecasts with high-quality global forecasts.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it provides forecasts, but lacks disclosure on data freshness, update frequency, rate limits, output structure, or coordinate validation behavior.
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?
Single sentence is efficient, no filler words. Could be slightly rephrased to include more key info without losing conciseness, but it's well-front-loaded.
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?
With 11 parameters, many enums, and no output schema, the description is insufficient. It doesn't explain return format, date ranges, weather codes, or how to interpret results, leaving significant gaps.
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 coverage is 100%, so baseline is 3. The description adds no parameter-specific guidance beyond what the schema already describes, such as meaning of daily vs hourly or default values.
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?
The description clearly states the verb 'Get' and resource 'weather forecast', specifies the source 'European Centre for Medium-Range Weather Forecasts', and mentions 'high-quality global forecasts', which distinguishes it from sibling tools like gfs_forecast or dwd_icon_forecast.
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?
No explicit when-to-use or when-not-to-use guidance. The phrase 'high-quality global forecasts' implies suitability for global needs, but doesn't explicitly compare to alternatives like weather_forecast or other regional models.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get elevation data for given coordinates using digital elevation models.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states what the tool does, not any behavioral traits such as data sources, accuracy, rate limits, or return format. This is insufficient for a tool with no structured behavioral hints.
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?
A single sentence that is efficient and front-loaded. No extraneous words. Every part earns its place.
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?
With two simple parameters and no output schema, the description is mostly complete. However, it could mention the unit of elevation (e.g., meters) or the resolution of the model. Despite this minor gap, it adequately serves its purpose.
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 coverage is 100% with descriptive parameter descriptions (latitude/longitude in WGS84 with bounds). The tool description adds 'using digital elevation models' but does not enhance parameter understanding beyond the schema. Baseline 3 is appropriate.
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?
The description clearly states the tool's action (Get elevation data) and the resource (given coordinates using digital elevation models). It effectively distinguishes from sibling tools that are weather-focused, though sibling differentiation is implicit.
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?
No explicit guidance on when to use this tool versus alternatives. While the sibling tools are weather-related, the description does not state exclusions or context. Usage is implied from the name and description but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ensemble forecasts showing forecast uncertainty with multiple model runs.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| models | Yes | Ensemble models to use | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| forecast_days | No | Number of forecast days | |
| temperature_unit | No | celsius | |
| wind_speed_unit | No | kmh | |
| precipitation_unit | No | mm | |
| timezone | No | Timezone for timestamps |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'forecast uncertainty' but does not specify how uncertainty is represented (e.g., percentiles, range), nor discloses update frequency, data source, or limitations.
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?
Single sentence, no fluff, but could be slightly longer to add value without losing conciseness.
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?
With 10 parameters, no output schema, and no annotations, the description is insufficient for a complex ensemble tool. It omits explanation of available variables, output structure, and interpretation of uncertainty.
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 description coverage is 70%, so most parameters have basic descriptions. The tool's description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
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?
The description clearly states the tool retrieves ensemble forecasts with uncertainty from multiple model runs. It distinguishes from the sibling 'weather_forecast' by emphasizing uncertainty, but does not differentiate from other model-specific siblings.
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?
No guidance on when to use this tool versus alternatives like weather_forecast or model-specific tools. No scenarios or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get river discharge and flood forecasts from GloFAS (Global Flood Awareness System).
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| daily | No | River discharge variables to retrieve | |
| timezone | No | Timezone for timestamps | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days (up to 210 days possible) | |
| ensemble | No | If true, all forecast ensemble members will be returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It only states a generic 'get forecasts' without revealing traits like data update frequency, spatial coverage, probabilistic nature, or whether the tool requires specific permissions. This is insufficient for safe and accurate agent usage.
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?
The description is a single concise sentence with no redundancy. While it could include more detail without bloating, it efficiently communicates the core purpose without filler.
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 lack of an output schema, the description should offer clues about the return format or data structure. It does not, leaving the agent uncertain about what the tool returns. For a tool with 7 parameters and no output specification, the description is incomplete.
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?
The input schema already describes all 7 parameters with 100% coverage, so the tool description adds no extra meaning beyond what the schema provides. Following the rubric, with high coverage, a baseline of 3 is appropriate.
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?
The description clearly states it retrieves river discharge and flood forecasts from the specific GloFAS system, using strong verbs 'Get' and specifying the resource and source. It effectively distinguishes from sibling tools like weather_forecast that handle atmospheric data.
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?
There is no guidance on when to use this tool versus alternatives such as weather_forecast or seasonal_forecast. The description does not specify prerequisites, limitations, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast from Canadian weather service GEM model with high-resolution data for Canada and North America.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get weather forecast', implying read-only behavior, but does not disclose rate limits, data update frequency, geographic coverage limits beyond 'Canada and North America', or any side effects. The behavior is minimally described.
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?
The description is a single sentence of 12 words, efficiently conveying the source model and coverage area. It is front-loaded with key information. Slightly more detail on output structure could be added without harming conciseness.
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?
The description does not mention the structure of the forecast output (e.g., JSON, fields) nor the availability of daily, hourly, or current weather options. Given no output schema, the agent lacks context on what the response will contain. The tool's capabilities beyond the described model and region are not set.
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?
The input schema covers 100% of parameters with descriptions. The tool description does not add any additional semantic information beyond what the schema already provides. Therefore, a baseline score of 3 is appropriate.
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?
The description clearly states the tool provides weather forecasts from the Canadian GEM model, specifically for Canada and North America with high-resolution data. This differentiates it from sibling tools that use other models or regions, though it does not mention the available variable types (daily, hourly) which are detailed in the schema.
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?
No guidance is provided on when to use this tool over the many sibling weather tools. There is no mention of use cases, prerequisites, or scenarios where the GEM model is preferred (e.g., for Canadian regions). The description lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for locations worldwide by place name or postal code. Returns geographic coordinates (latitude and longitude) and detailed location information. Use this tool when you need to convert a location name (e.g., "Paris", "New York") into precise coordinates (latitude/longitude) that are required by other tools. This is essential when you have a location name but need coordinates for data fetching tools.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Place name or postal code to search for. Minimum 2 characters required. Examples: "Paris", "Berlin", "75001", "10967" | |
| count | No | Number of search results to return (maximum 100) | |
| language | No | Language code for translated results (e.g., "fr", "en", "de"). Returns translated results if available, otherwise in English or native language. | |
| countryCode | No | ISO-3166-1 alpha2 country code to filter results (e.g., "FR", "DE", "US"). Limits search to a specific country. | |
| format | No | Return format for results | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns ('geographic coordinates and detailed location information') and its essential purpose in converting names to coordinates. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation versus a write operation. The description adds value but leaves significant behavioral aspects unspecified.
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?
The description is appropriately sized and front-loaded, with the core purpose stated in the first sentence. The second and third sentences provide valuable usage context. While efficient, the third sentence could be slightly more concise by combining concepts about when to use the tool.
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?
For a search tool with no annotations and no output schema, the description provides good context about what the tool does and when to use it. It clearly distinguishes this from sibling weather tools. However, without annotations or output schema, it could better explain the return format, error handling, or limitations of the geocoding service.
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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the 'name' parameter implicitly ('location name or postal code') but provides no additional syntax, format, or usage details. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
The description clearly states the tool's purpose with specific verbs ('search for locations', 'convert a location name into precise coordinates') and resources ('geographic coordinates', 'detailed location information'). It explicitly distinguishes this geocoding tool from sibling weather/forecast tools by focusing on coordinate conversion rather than meteorological data.
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?
The description provides explicit guidance on when to use this tool: 'when you need to convert a location name into precise coordinates that are required by other tools' and 'when you have a location name but need coordinates for data fetching tools.' This clearly differentiates it from sibling tools that provide weather data rather than coordinate conversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast from US NOAA GFS model with global coverage and high-resolution data for North America.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It characterizes the operation as a read (get) but does not disclose rate limits, idempotency, data freshness, or any side effects, and only mentions high-resolution for North America as a trait.
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?
The description is a single sentence with no wasted words, but it could be slightly more informative without sacrificing conciseness.
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 has 11 parameters, no output schema, and many siblings, the description is incomplete. It does not explain return values, default behaviors for omitted parameters, or how high-resolution data affects results.
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?
Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra semantic value beyond what the schema already provides.
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?
The description clearly states the tool retrieves weather forecasts from the US NOAA GFS model, explicitly noting global coverage and high-resolution data for North America, which distinguishes it from sibling tools like dwd_icon_forecast or ecmwf_forecast.
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?
The description implies usage when GFS model forecasts are desired but provides no explicit when-to-use or when-not-to-use guidance or direct comparisons with alternatives like weather_forecast or other model-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast from Japan Meteorological Agency with high-resolution data for Japan and Asia.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only indicates a read operation ('Get weather forecast') but lacks any disclosure about potential limitations, rate limits, or other behavioral traits.
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?
Single sentence with clear subject, verb, and object. No unnecessary words.
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?
Despite rich schema, the description is minimal. It does not explain 'high-resolution' specifics, expected response format, or any JMA-specific nuances, leaving gaps for an agent to correctly interpret the tool.
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 coverage is 100% with descriptions for all 11 parameters. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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?
The description clearly states the tool fetches a weather forecast from the Japan Meteorological Agency, with high-resolution data for Japan and Asia. This specific source and regional focus distinguishes it from many sibling tools like gfs_forecast or metno_forecast.
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?
No guidance is provided on when to use this tool versus the many weather forecast siblings. It does not specify that it is best for Japan/Asia or when other models might be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get marine weather forecast including wave height, wave period, wave direction and sea surface temperature.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Marine weather variables to retrieve | |
| daily | No | Daily marine weather variables to retrieve | |
| timezone | No | Timezone for timestamps | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only lists output variables. It fails to disclose behavioral traits such as whether the tool is read-only, rate limits, data sources, or update frequency. Critical safety and performance characteristics are omitted.
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?
The description is a single, front-loaded sentence with no filler. Every word conveys information, making it highly efficient and easy to parse.
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?
Despite having 7 parameters including daily/hourly options and forecast/past days, the description does not mention output format, data ranges, or how to use the parameters. The lack of output schema and minimal description leaves significant gaps for an agent to correctly invoke the tool.
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 description coverage is 100%, so baseline is 3. The description adds value by listing some variables (wave height, wave period, wave direction, SST), which correspond to hourly parameters. However, it does not cover daily variables or explain parameter relationships, so it adds marginal meaning beyond the 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?
The description clearly states the tool retrieves 'marine weather forecast' and enumerates specific variables (wave height, wave period, wave direction, sea surface temperature), which distinguishes it from the sibling 'weather_forecast' and other general tools. The verb 'Get' combined with the resource 'marine weather forecast' leaves no ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives like 'weather_forecast' or other marine-related siblings. The description does not specify prerequisites, context, or exclusions, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast from French Météo-France models including AROME (high-resolution France) and ARPEGE (Europe).
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions models but does not describe outcomes for out-of-range coordinates, data freshness, rate limits, or the nature of the operation (read-only). Incomplete for safety assessment.
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?
Single concise sentence with 15 words. No redundancy. Front-loaded with the core action ('Get weather forecast') and key differentiator (French models).
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 tool complexity (11 params, no output schema, many sibling tools), the description is too sparse. It lacks details on geographical scope, output format, model selection logic, and typical use cases. The mention of models helps but is insufficient.
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 coverage is 100%, so the schema already documents each parameter. The description adds context about models but does not enhance understanding of individual parameters beyond what the schema provides. Baseline 3 is appropriate.
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 gets weather forecast from Météo-France models (AROME, ARPEGE). This distinguishes it from sibling tools like dwd_icon_forecast or gfs_forecast, as it is specific to French models.
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?
No guidance on when to use this tool vs alternatives. It hints at regional focus (France, Europe via models) but does not explicitly state that it should be used for French/European regions or how it compares to other regional forecast tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast from Norwegian weather service with high-resolution data for Nordic countries.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the tool gets a forecast, but does not disclose data recency, resolution limits, or other behavioral traits essential for an agent to understand the tool's behavior.
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?
The description is a single, well-structured sentence that immediately conveys the core purpose. No redundant information, every word earns its place.
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?
The tool has 11 parameters and no output schema, yet the description offers no information about response format, data structure, or how the high-resolution aspect manifests. For a tool with this complexity, the description is too brief to be complete.
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 description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond what's in the schema; it remains generic. No parameter details are elaborated in the description.
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?
The description clearly states it gets a weather forecast from the Norwegian service, with a specific resource and verb. It mentions 'high-resolution data for Nordic countries', which helps differentiate it from generic weather tools and other regional ones, though the differentiation is implicit.
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?
No explicit guidance on when to use this tool versus the many sibling tools. It implies Nordic focus but doesn't state when not to use it or name alternatives. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get long-range seasonal forecasts for temperature and precipitation up to 9 months ahead.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | 6-hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| forecast_days | No | Number of forecast days: 45 days, 3 months (default), 6 months, or 9 months | |
| past_days | No | Include past days data | |
| start_date | No | Start date in YYYY-MM-DD format | |
| end_date | No | End date in YYYY-MM-DD format | |
| temperature_unit | No | celsius | |
| wind_speed_unit | No | kmh | |
| precipitation_unit | No | mm | |
| timezone | No | Timezone for timestamps |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states it returns seasonal forecasts but omits that it can also include past_days data (retrospective), the distinction between daily and 6-hourly 'hourly' data, and any data source or update frequency. The agent is left uninformed about key operational traits.
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?
The description is a single sentence with no wasted words. It front-loads the core purpose. However, it sacrifices necessary detail for brevity, missing key scoping information.
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 12 parameters, no output schema, and numerous sibling tools, the description is insufficient. It fails to explain the range of output variables, the difference between daily and hourly intervals, the use of date parameters, or how 'forecast_days' maps to months. The tool's full functionality is obscure.
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 description coverage is 75% (high), establishing a baseline of 3. The description adds no parameter-level meaning beyond what the schema already provides, such as clarifying the function of 'hourly' (6-hourly) or the meaning of 'forecast_days' increments. It does not compensate for the 25% of params without schema descriptions.
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?
The description uses a clear verb ('Get') and specifies the resource ('long-range seasonal forecasts for temperature and precipitation') with a time scope ('up to 9 months ahead'). However, it underrepresents the full range of variables available (e.g., wind, humidity, soil moisture), which could mislead an agent about capability. It distinguishes from short-range forecast tools, but not explicitly from climate projections.
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?
No guidance is provided on when to use this tool versus siblings like weather_forecast (short-term) or climate_projection (longer-term). There are no usage conditions, prerequisites, or exclusions stated, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical weather data from ERA5 reanalysis (1940-present) for specific coordinates and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| start_date | Yes | Start date in YYYY-MM-DD format | |
| end_date | Yes | End date in YYYY-MM-DD format | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| temperature_unit | No | celsius | |
| timezone | No | Timezone for timestamps |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It identifies the data source (ERA5 reanalysis) and time range, but lacks details on access limitations, data latency, or whether the operation is read-only.
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?
The description is a single sentence of 13 words, front-loaded with the key purpose. Every word is necessary; no redundancy.
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?
The tool has 8 parameters and no output schema. The description does not explain the return format, units, or any limitations beyond the data source. While basic, it covers the essential purpose and source.
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?
With 88% schema coverage, the input schema already documents most parameters. The description adds context about the data source and time range but does not provide additional meaning for individual parameters beyond the 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?
The description clearly states the tool retrieves historical weather data from the ERA5 reanalysis, specifying the time span (1940-present) and parameters (coordinates and date range). This distinguishes it from sibling tools like weather_forecast.
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?
The description implies usage for historical data retrieval, and the sibling context suggests alternatives for forecasts. However, it does not explicitly state when not to use this tool or provide direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather forecast data for coordinates using Open-Meteo API. Supports hourly and daily data with various weather variables.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in WGS84 coordinate system | |
| longitude | Yes | Longitude in WGS84 coordinate system | |
| hourly | No | Hourly weather variables to retrieve | |
| daily | No | Daily weather variables to retrieve | |
| current_weather | No | Include current weather conditions | |
| temperature_unit | No | Temperature unit | celsius |
| wind_speed_unit | No | Wind speed unit | kmh |
| precipitation_unit | No | Precipitation unit | mm |
| timezone | No | Timezone for timestamps (e.g., Europe/Paris, America/New_York) | |
| past_days | No | Include past days data | |
| forecast_days | No | Number of forecast days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as rate limits, data source limitations, default units, or response format. It only mentions using Open-Meteo API.
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?
Two sentences, brief and to the point. Could be slightly more informative without becoming verbose.
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 11 parameters, no output schema, and no annotations, the description is lacking. It does not cover output format, error handling, usage limits, or how this tool fits among the many sibling forecast tools.
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 coverage is 100% with parameter descriptions. The description adds only a generic summary ('Supports hourly and daily data with various weather variables'), which provides minimal additional value beyond the 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?
Clearly states verb (Get), resource (weather forecast data for coordinates), and mentions hourly and daily data. However, it does not differentiate from sibling forecast tools like dwd_icon_forecast or weather_archive.
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?
No guidance on when to use this tool vs alternative forecast models or the weather_archive tool. The description lacks context for choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.3air_qualityclimate_projectiondwd_icon_forecastecmwf_forecastelevationensemble_forecastflood_forecastgem_forecastgeocodinggfs_forecastjma_forecastmarine_weathermeteofrance_forecastmetno_forecastseasonal_forecastweather_archiveweather_forecastScored across 17 tools
Each tool has a clearly distinct purpose, targeting specific weather or climate data sources, models, or functions. For example, 'air_quality' focuses on pollutants, 'flood_forecast' on river discharge, and 'geocoding' on location conversion, with no overlap in their core functionalities. The descriptions explicitly differentiate them, making misselection unlikely.
All tool names follow a consistent snake_case pattern with a clear noun-based structure (e.g., 'air_quality', 'climate_projection', 'geocoding'). There are no deviations in naming conventions, making the set predictable and easy to parse for agents. This uniformity enhances usability and reduces cognitive load.
With 17 tools, the count is slightly high but reasonable for a comprehensive weather and climate data server covering multiple models, forecasts, and auxiliary functions. Each tool serves a specific niche, such as different regional forecasts or data types, justifying its inclusion without appearing overly bloated. A minor reduction could improve focus, but it's well within an acceptable range.
The tool surface is highly complete for the domain of weather and climate data, offering extensive coverage including forecasts from various global models (e.g., ECMWF, GFS), specialized data (e.g., air quality, floods), historical archives, and essential utilities like geocoding. There are no obvious gaps; agents can perform a full range of data retrieval and conversion tasks seamlessly.
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
Real-time weather conditions and multi-day forecasts via Open-Meteo — free, no API key required
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.