open-meteo-mcp-server
Server Details
Global weather via Open-Meteo: forecast, ERA5 archive, marine, air quality, geocoding, elevation.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 6 of 6 tools scored.
Each tool targets a distinct domain: geocoding, air quality, elevation, weather forecast, historical weather, and marine weather. Descriptions clarify boundaries and prevent overlap.
All tools follow the pattern 'openmeteo_verb_noun' (e.g., openmeteo_get_forecast) except openmeteo_geocode which uses a verb-noun compound. This is highly consistent and predictable.
6 tools cover the essential subdomains of weather and climate data without being excessive. Each tool serves a clear and necessary function for the server's purpose.
The tool set covers geocoding, air quality, elevation, forecast, historical, and marine data. Minor omissions include specialized tools like weather alerts or current conditions, but these are often covered by the forecast tool's variables.
Available Tools
10 toolsopenmeteo_dataframe_describeOpenmeteo Dataframe DescribeARead-onlyIdempotentInspect
List the tables and their columns on a DataCanvas staged by openmeteo_get_historical. Call this first to discover table names before querying with openmeteo_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| canvas_id | Yes | Canvas ID returned by openmeteo_get_historical when truncated: true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tables | Yes | Tables and views registered on this canvas. |
| canvas_id | Yes | Canvas ID that was inspected. |
| expires_at | Yes | ISO 8601 expiry after the sliding 24 h TTL. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by noting the dependency on openmeteo_get_historical, but doesn't elaborate further on 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?
Two efficient sentences with no wasted words. The purpose is front-loaded and structure is clean.
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 simple tool with one well-documented parameter and output schema, the description covers purpose, usage, and prerequisite adequately.
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 single parameter canvas_id has full schema description. The description adds no extra semantic details, so baseline of 3 applies.
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 lists tables and columns on a DataCanvas staged by openmeteo_get_historical, differentiating it from siblings like openmeteo_dataframe_query by specifying it as a discovery step.
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 'Call this first to discover table names before querying with openmeteo_dataframe_query', providing clear when-to-use and subsequent action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_dataframe_queryOpenmeteo Dataframe QueryARead-onlyInspect
Run a read-only SQL SELECT against tables staged on a DataCanvas by openmeteo_get_historical. Pass the canvas_id returned when openmeteo_get_historical spills (truncated: true). Tables are named by the spillover helper (e.g. spilled_); use openmeteo_dataframe_describe to list available tables and their columns before querying.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Read-only SELECT statement. Reference table names from openmeteo_dataframe_describe. Example: SELECT AVG(temperature_2m) AS avg_temp, strftime(time, '%Y-%m') AS month FROM spilled_abc123 GROUP BY month ORDER BY month | |
| canvas_id | Yes | Canvas ID returned by openmeteo_get_historical when truncated: true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Result rows (capped at the canvas row limit, default 10 000). |
| canvas_id | Yes | Canvas ID that was queried. |
| row_count | Yes | Total rows in the full result before any cap. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that tables are named by spillover helper (e.g., spilled_<id>) and that the query is read-only SQL, confirming the safety profile without contradiction.
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 packed with essential information: purpose, prerequisite, and cross-reference to describe. No wasted 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?
Given the presence of an output schema (not shown but noted) and annotations, the description fully covers how to use the tool, what to expect from parameters, and how it fits with other 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 descriptions for sql and canvas_id. The description adds context that sql must be a read-only SELECT and canvas_id comes from a specific trigger, enhancing understanding 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?
Description clearly states it runs a read-only SQL SELECT against tables staged by openmeteo_get_historical. It distinguishes from siblings by specifying the prerequisite step and referring to the describe tool for table exploration.
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 says when to use (after a spillover from openmeteo_get_historical with truncated:true) and advises using openmeteo_dataframe_describe to list tables. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_geocodeOpenmeteo GeocodeARead-onlyIdempotentInspect
Resolve a place name to ranked coordinate matches with country, region, elevation, timezone, and population. Required prerequisite for name-based queries — all weather tools take latitude/longitude, not place names. Returns up to 10 matches ranked by population/relevance; use country or admin1 to disambiguate when multiple cities share a name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Place name to search. Can be a city, region, or landmark (e.g., "Seattle", "Mount Rainier"). Weather tools require coordinates — use the lat/lon from this result. | |
| count | No | Max results to return (1–10). Default 5. Return more when disambiguating common names like "Springfield" or "Portland". | |
| language | No | Response language for place names (ISO 639-1, e.g., "en", "de", "fr"). Default "en". | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of results returned |
| results | Yes | Ranked matches (most relevant first). Empty when no results match. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by explaining ranking by population/relevance and the 10-result limit. Does not contradict annotations.
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?
Three sentences with no fluff: states purpose, usage context, and disambiguation advice. Well-structured and 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?
Given the annotations and output schema, the description fully explains the tool's role as a prerequisite for weather queries, how to use it, and what results to expect. Covers all necessary aspects.
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 good parameter descriptions. The description adds extra context by explaining ranking and disambiguation tips using output fields like country and admin1, which goes 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 verb 'resolve' and the resource 'place name to ranked coordinate matches', listing specific output fields. It distinguishes from sibling weather tools that take coordinates, not place names.
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 says it's a 'required prerequisite for name-based queries' and that 'all weather tools take latitude/longitude, not place names', providing clear when-to-use and alternative information. Also advises using country or admin1 to disambiguate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_get_air_qualityOpenmeteo Get Air QualityARead-onlyIdempotentInspect
Modeled CAMS (Copernicus Atmosphere Monitoring Service) air quality forecast: PM2.5, PM10, nitrogen dioxide, sulphur dioxide, ozone, carbon monoxide, dust, pollen, and European/US AQI indices. This is modeled grid data, not measured station readings — for measured data, use openaq-mcp-server. Forecast only (no historical archive). Common variables: pm2_5, pm10, carbon_monoxide, nitrogen_dioxide, sulphur_dioxide, ozone, dust, european_aqi, us_aqi, alder_pollen, birch_pollen, grass_pollen, mugwort_pollen, olive_pollen, ragweed_pollen.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in decimal degrees. Use openmeteo_geocode to resolve a place name. | |
| timezone | No | IANA timezone or "auto". Default "auto". | auto |
| longitude | Yes | Longitude in decimal degrees. | |
| forecast_days | No | Forecast horizon in days (1–7). Default 5. | |
| hourly_variables | No | Hourly air quality variables (e.g., ["pm2_5", "pm10", "ozone", "nitrogen_dioxide", "european_aqi", "us_aqi"]). At least one required. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hourly | No | Per-hour records with "time" (ISO 8601) + one key per requested variable. Units: pm2_5/pm10/dust in μg/m³, carbon_monoxide in μg/m³, nitrogen_dioxide/sulphur_dioxide/ozone in μg/m³, european_aqi/us_aqi as index values. |
| latitude | Yes | Snapped latitude |
| timezone | Yes | Resolved IANA timezone |
| longitude | Yes | Snapped longitude |
| data_source | Yes | Data source identifier — this is modeled forecast data from CAMS, not measured station data. |
| hourly_units | No | Variable → unit string for hourly data (e.g., {"pm2_5": "μg/m³", "european_aqi": "EAQI"}). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds that data is modeled grid data, not station measurements, and is forecast-only. This gives important behavioral context about data source and temporal scope.
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, well-structured paragraph that front-loads the core purpose and data source, then covers limitations, variable examples, and alternatives without redundancy. Every sentence serves a purpose.
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 presence of an output schema (not shown but noted), the description adequately covers purpose, limitations, parameter guidance, and alternatives. It could mention the output format briefly but is otherwise complete for a forecast 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?
All parameters have schema descriptions (100% coverage). The description adds value by providing example hourly_variables and clarifying that latitude should be resolved via openmeteo_geocode, going beyond what the schema alone 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 it provides modeled CAMS air quality forecast data for specific pollutants and indices. It distinguishes itself from measured station readings (openaq-mcp-server) and from historical data, which helps an agent select the correct tool.
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 tells the agent to use openaq-mcp-server for measured data and warns that only forecast data is available (no historical archive). Also suggests using openmeteo_geocode for place name resolution and lists common variables, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_get_elevationOpenmeteo Get ElevationARead-onlyIdempotentInspect
Terrain elevation from the Copernicus Digital Elevation Model (~90m resolution) for one or more coordinate pairs. Accepts up to 100 pairs per call. Useful for geographic context, elevation-adjusted weather interpretation, or route planning.
| Name | Required | Description | Default |
|---|---|---|---|
| latitudes | Yes | Array of latitudes in decimal degrees (up to 100). Must be same length as longitudes. | |
| longitudes | Yes | Array of longitudes in decimal degrees (up to 100). Must be same length as latitudes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| elevations | Yes | Elevation values in input order |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by specifying the data source (Copernicus DEM) and resolution (~90m), and the input constraint of up to 100 pairs, without contradicting annotations.
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 that front-load the core function, followed by use cases and constraints. Every sentence adds value with no redundancies.
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 an output schema present and simple input structure, the description covers enough context (source, resolution, limit, use cases) for the agent to invoke correctly. No missing critical information.
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 both parameters with details (range, length). The description adds only the hint of 'coordinate pairs' and the limit, which is already in schema constraints. 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 'Terrain elevation from the Copernicus Digital Elevation Model (~90m resolution) for one or more coordinate pairs,' providing a specific verb (get) and resource (elevation from DEM). It distinguishes from siblings like forecast, air quality, and marine.
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?
Lists use cases (geographic context, elevation-adjusted weather interpretation, route planning) and mentions the input limit of up to 100 pairs. However, it does not explicitly state when not to use this tool or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_get_ensembleOpenmeteo Get EnsembleARead-onlyIdempotentInspect
Probabilistic ensemble weather forecast — up to 51 ensemble members, up to 16 days ahead with optional past_days (0–92). Each member's values appear as separate columns named with a member suffix (e.g. temperature_2m_member01, temperature_2m_member02). Use the spread across members to compute exceedance probabilities, quantify forecast uncertainty, and build decision thresholds. Available models: "ecmwf_ifs025" (51 members, global, 0.25°), "gfs025" (31 members, global, 0.25°), "icon_seamless" (40 members, global/Europe blend), "gem_global" (21 members, global, 0.25°). Omit models to use the API default blend. Large multi-member, multi-day pulls produce thousands of records and spill to DataCanvas when canvas is enabled. At least one of hourly_variables or daily_variables is required.
| Name | Required | Description | Default |
|---|---|---|---|
| models | No | Ensemble model to use: "ecmwf_ifs025" (51 members, global 0.25°), "gfs025" (31 members), "icon_seamless" (40 members), "gem_global" (21 members). Omit to use the API default blend. | |
| latitude | Yes | Latitude in decimal degrees. Use openmeteo_geocode to resolve a place name to coordinates. | |
| timezone | No | IANA timezone (e.g., "America/Los_Angeles") or "auto" to use the location's local timezone. Default "auto". | auto |
| canvas_id | No | DataCanvas token for large multi-member queries. When records exceed ~500, results spill to this canvas for SQL querying. Omit to create a fresh canvas. | |
| longitude | Yes | Longitude in decimal degrees. | |
| past_days | No | Include this many days of past ensemble data before today (0–92). Default 0. | |
| forecast_days | No | Forecast horizon in days (1–16). Default 7. | |
| daily_variables | No | Daily variables to fetch across all ensemble members (e.g., ["temperature_2m_max", "temperature_2m_min", "precipitation_sum"]). Each variable appears as temperature_2m_max_member01, … At least one of hourly_variables or daily_variables required. | |
| wind_speed_unit | No | Wind speed unit. Default "kmh". | kmh |
| hourly_variables | No | Hourly variables to fetch across all ensemble members (e.g., ["temperature_2m", "precipitation", "wind_speed_10m"]). Each variable appears as temperature_2m_member01, temperature_2m_member02, … in the output. At least one of hourly_variables or daily_variables required. | |
| temperature_unit | No | Temperature unit. Default "celsius". | celsius |
| precipitation_unit | No | Precipitation unit. Default "mm". | mm |
Output Schema
| Name | Required | Description |
|---|---|---|
| daily | No | Per-day records with "time" (YYYY-MM-DD) + per-member columns (e.g., temperature_2m_max_member01). Absent when only hourly_variables were requested. When truncated, contains a preview only; query canvas_id for the full dataset. |
| model | No | Ensemble model used (e.g. "ecmwf_ifs025") |
| hourly | No | Per-hour records with "time" (ISO 8601) + per-member columns for each requested variable (e.g., temperature_2m_member01, temperature_2m_member02). Absent when only daily_variables were requested. When truncated, contains a preview only; query canvas_id for the full dataset. |
| latitude | Yes | Snapped latitude (Open-Meteo snaps to nearest grid point) |
| timezone | Yes | Resolved IANA timezone |
| canvas_id | No | DataCanvas token — present when record_count exceeded inline limit. Query with SQL using this token. |
| elevation | Yes | Terrain elevation at grid point (meters) |
| longitude | Yes | Snapped longitude |
| truncated | Yes | True when the response exceeded the inline record limit and data spilled to canvas_id. Query the canvas for the full dataset. |
| daily_units | No | Variable → unit string for daily data. Absent when no daily_variables were requested. |
| hourly_units | No | Variable → unit string for hourly data (e.g., {"temperature_2m_member01": "°C"}). Absent when no hourly_variables were requested. |
| member_count | No | Number of ensemble members in the response |
| record_count | Yes | Total number of records (hourly + daily rows) in this response |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint and idempotentHint as true. The description adds critical behavioral context: naming convention for members (e.g., temperature_2m_member01), spill behavior to DataCanvas for large queries, and that omitting models uses API default blend. No contradictions.
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 dense paragraph that front-loads the core purpose and key behaviors. It could be more structured (e.g., model list as bullets) but is clear and efficient without wasted words. Minor loss due to density.
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 and output schema, the description covers essential behaviors: purpose, output naming, data spill, model options, and required variable condition. It does not detail output schema structure (handled by schema) but provides sufficient context for selection and use.
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%, but the description adds value by explaining how parameters affect ensemble output (e.g., past_days range, naming convention, large spill). It duplicates some schema descriptions but enriches with behavioral implications. Does not introduce new parameter details beyond 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 explicitly states 'Probabilistic ensemble weather forecast' and details capabilities: up to 51 members, up to 16 days, optional past_days, with member suffix naming. It also lists distinct models, differentiating it from deterministic siblings like openmeteo_get_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 provides usage context: 'Use the spread across members to compute exceedance probabilities, quantify forecast uncertainty, and build decision thresholds.' It implies when to use ensemble vs deterministic, and notes optional model omission for default blend. Lacks explicit when-not-to-use, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_get_floodOpenmeteo Get FloodARead-onlyIdempotentInspect
GloFAS (Global Flood Awareness System) river discharge forecast and historical reanalysis. Returns daily ensemble river discharge (m³/s) for the river nearest to the given coordinates — no river ID needed, the API snaps to the nearest stream. Forecast horizon up to 210 days ahead; reanalysis history back to 1984-01-01. Use start_date/end_date for historical pulls and forecast_days for future forecasts; both can be combined. Available daily variables: "river_discharge" (ensemble mean), "river_discharge_mean", "river_discharge_min", "river_discharge_max", "river_discharge_median", "river_discharge_p25" (25th percentile), "river_discharge_p75" (75th percentile). Returns null for coordinates far from any river or in areas without GloFAS coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date for historical reanalysis (YYYY-MM-DD, inclusive). Must be on or after start_date. | |
| latitude | Yes | Latitude in decimal degrees. The API snaps to the nearest river — no river ID required. Use openmeteo_geocode to resolve a place name. | |
| timezone | No | IANA timezone or "auto". Default "auto". | auto |
| longitude | Yes | Longitude in decimal degrees. | |
| start_date | No | Start date for historical reanalysis (YYYY-MM-DD, e.g., "2023-01-01"). GloFAS reanalysis covers from 1984-01-01. | |
| forecast_days | No | Number of forecast days ahead (1–210). Omit when fetching historical data only via start_date/end_date. | |
| daily_variables | Yes | Daily discharge variables to fetch (e.g., ["river_discharge", "river_discharge_p25", "river_discharge_p75", "river_discharge_min", "river_discharge_max"]). Required. |
Output Schema
| Name | Required | Description |
|---|---|---|
| daily | Yes | Per-day records with "time" (YYYY-MM-DD) + one key per requested variable containing discharge in m³/s, or null for coordinates outside GloFAS coverage. |
| latitude | Yes | Snapped latitude (nearest river grid point) |
| timezone | Yes | Resolved IANA timezone |
| longitude | Yes | Snapped longitude |
| daily_units | No | Variable → unit string for daily data (e.g., {"river_discharge": "m³/s"}). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint, indicating safe repeated calls. The description adds value by noting the API returns null for coordinates far from rivers or areas without GloFAS coverage, which is not revealed by annotations alone. No contradiction.
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 approximately 120 words, front-loaded with the primary purpose. Sentences are clear and structured. There is minor redundancy in repeating variable names, but overall it is efficient and avoids unnecessary detail.
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 presence of an output schema and comprehensive annotations, the description covers input parameters, behavior, and edge cases (null for no coverage). It adequately informs an agent about when and how to use the tool, with sufficient detail for correct invocation.
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 meaning by explaining that latitude/longitude snap to the nearest river, lists available daily_variables, and clarifies that forecast_days and date ranges can be combined. This goes beyond the schema's field 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 clearly states the tool returns daily ensemble river discharge (m³/s) for the nearest river using GloFAS data. It specifies the verb 'get' and resource 'flood' with precise details on data source and snap-to-river behavior, distinguishing it from siblings like openmeteo_get_forecast which focus on general weather.
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 explains when to use for historical reanalysis (1984-01-01 onward) or forecasts (up to 210 days). It mentions combining start_date/end_date with forecast_days and suggests openmeteo_geocode for place resolution, but does not explicitly compare with sibling tools like openmeteo_get_forecast or openmeteo_get_historical for non-flood data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_get_forecastOpenmeteo Get ForecastARead-onlyIdempotentInspect
Weather forecast for coordinates: hourly and/or daily variables for up to 16 days ahead, with optional past_days (up to 92) for recent history. Use past_days instead of openmeteo_get_historical for dates within the last 1–5 days, since ERA5 has a variable lag. Returns per-timestamp records — each hourly entry contains a "time" field (ISO 8601) plus one key per requested variable; each daily entry contains a "time" field (YYYY-MM-DD) plus requested variables. Common hourly variables: temperature_2m, precipitation, wind_speed_10m, relative_humidity_2m, cloud_cover, uv_index, apparent_temperature, precipitation_probability, weather_code, surface_pressure, visibility, wind_direction_10m, wind_gusts_10m, dew_point_2m. Common daily variables: temperature_2m_max, temperature_2m_min, precipitation_sum, wind_speed_10m_max, sunrise, sunset, uv_index_max, precipitation_hours, weather_code. At least one of hourly_variables or daily_variables is required.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in decimal degrees (e.g., 47.6062 for Seattle). Use openmeteo_geocode to resolve a place name to coordinates. | |
| timezone | No | IANA timezone (e.g., "America/Los_Angeles") or "auto" to use the location's local timezone. Default "auto". The timezone from openmeteo_geocode is ideal to pass here. | auto |
| longitude | Yes | Longitude in decimal degrees (e.g., -122.3321 for Seattle). | |
| past_days | No | Include this many days of past data before today (0–92). Use for recent history — ERA5 archive has a variable ~5-day lag. Default 0. | |
| forecast_days | No | Number of forecast days (1–16). Default 7. | |
| daily_variables | No | Daily summary variables (e.g., ["temperature_2m_max", "temperature_2m_min", "precipitation_sum", "wind_speed_10m_max", "sunrise", "sunset", "uv_index_max"]). At least one of hourly_variables or daily_variables is required. | |
| wind_speed_unit | No | Wind speed unit: "kmh" (km/h), "mph", "ms" (m/s), or "kn" (knots). Default "kmh". | kmh |
| hourly_variables | No | Hourly variables to fetch (e.g., ["temperature_2m", "precipitation", "wind_speed_10m", "relative_humidity_2m", "cloud_cover", "uv_index", "apparent_temperature"]). At least one of hourly_variables or daily_variables is required. | |
| temperature_unit | No | Temperature unit. Default "celsius". | celsius |
| precipitation_unit | No | Precipitation unit: "mm" or "inch". Default "mm". | mm |
Output Schema
| Name | Required | Description |
|---|---|---|
| daily | No | Per-day records. Each object has a "time" field (YYYY-MM-DD) plus one key per requested variable with its value. Units are in the daily_units map. Absent when only hourly_variables were requested. |
| hourly | No | Per-hour records. Each object has a "time" field (ISO 8601) plus one key per requested variable with its value. Units are in the hourly_units map. Absent when only daily_variables were requested. |
| latitude | Yes | Snapped latitude (Open-Meteo snaps to nearest grid point) |
| timezone | Yes | Resolved IANA timezone |
| elevation | Yes | Terrain elevation at grid point (meters) |
| longitude | Yes | Snapped longitude |
| daily_units | No | Map of variable name → unit string for daily data. Absent when no daily_variables were requested. |
| hourly_units | No | Map of variable name → unit string for hourly data (e.g., {"temperature_2m": "°C", "precipitation": "mm"}). Absent when no hourly_variables were requested. |
| utc_offset_seconds | Yes | UTC offset in seconds for this timezone at query time |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds transparency about data source lag, return format (per-timestamp records with time field and keys), and distinction between hourly and daily entries.
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 somewhat long but well-structured: function summary, usage guidance, return format, variable lists. Front-loaded with main purpose. Could be slightly more concise but effective.
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, 2 required, high schema coverage, and existing output schema, the description is complete: explains return structure, variable options, usage alternatives, and data lag.
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% (baseline 3). Description adds meaning by listing common variables, explaining return format details, and emphasizing that past_days is for recent history.
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 provides weather forecasts for coordinates with hourly/daily variables and up to 16 days ahead. It distinguishes from siblings by advising to use past_days instead of openmeteo_get_historical for recent dates.
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 advises using past_days instead of openmeteo_get_historical for the last 1-5 days due to ERA5 lag. Provides common variable examples and notes that at least one of hourly/daily variables is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_get_historicalOpenmeteo Get HistoricalARead-onlyIdempotentInspect
Historical weather from the ERA5 reanalysis archive (1940–present). Requires start_date and end_date (ISO 8601 date, e.g., "2024-07-01"). ERA5 has a variable lag of up to ~5 days — for dates within the last week, use openmeteo_get_forecast with past_days instead. Uses the same variable names as the forecast API for direct comparison. Large date ranges (multi-year hourly) produce thousands of records — these spill to DataCanvas for SQL querying when canvas is enabled. At least one of hourly_variables or daily_variables is required.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | End date (YYYY-MM-DD, inclusive). Must be on or after start_date. For dates within the last ~5 days, use openmeteo_get_forecast with past_days instead. | |
| latitude | Yes | Latitude in decimal degrees. Use openmeteo_geocode to resolve a place name to coordinates. | |
| timezone | No | IANA timezone or "auto". Default "auto". | auto |
| canvas_id | No | DataCanvas token for multi-year or multi-variable queries. When a query exceeds ~500 records, results spill to this canvas for SQL querying. Omit to create a fresh canvas. | |
| longitude | Yes | Longitude in decimal degrees. | |
| start_date | Yes | Start date (YYYY-MM-DD, e.g., "2024-07-01"). ERA5 covers from 1940-01-01 to approximately 5 days ago. | |
| daily_variables | No | Daily summary variables (e.g., ["temperature_2m_max", "temperature_2m_min", "precipitation_sum", "wind_speed_10m_max"]). At least one of hourly_variables or daily_variables required. | |
| wind_speed_unit | No | Wind speed unit. Default "kmh". | kmh |
| hourly_variables | No | Hourly ERA5 variables (e.g., ["temperature_2m", "precipitation", "wind_speed_10m", "relative_humidity_2m", "cloud_cover", "soil_moisture_0_to_7cm"]). At least one of hourly_variables or daily_variables required. | |
| temperature_unit | No | Temperature unit. Default "celsius". | celsius |
| precipitation_unit | No | Precipitation unit. Default "mm". | mm |
Output Schema
| Name | Required | Description |
|---|---|---|
| daily | No | Per-day records with "time" (YYYY-MM-DD) + variable keys. Absent when only hourly_variables were requested. When truncated, contains only a preview; query canvas_id for the full dataset. |
| hourly | No | Per-hour records with "time" (ISO 8601) + variable keys. Absent when only daily_variables were requested. When truncated, contains only a preview; query canvas_id for the full dataset. |
| latitude | Yes | Snapped latitude |
| timezone | Yes | Resolved IANA timezone |
| canvas_id | No | DataCanvas token — present when record_count exceeded inline limit. Query with SQL using this token. |
| elevation | Yes | Elevation at grid point (meters) |
| longitude | Yes | Snapped longitude |
| truncated | Yes | True when the response exceeded inline record limit and data spilled to canvas_id. Query the canvas for the full dataset. |
| date_range | Yes | Date range of returned data |
| daily_units | No | Variable → unit string for daily data. Absent when no daily_variables were requested. |
| hourly_units | No | Variable → unit string for hourly data (e.g., {"temperature_2m": "°C", "precipitation": "mm"}). Absent when no hourly_variables were requested. |
| record_count | Yes | Total number of records (hourly or daily rows) in this response |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses the ~5-day ERA5 data lag, the spillover to DataCanvas for large queries, and the requirement for at least one variable set. While comprehensive, it could mention rate limits or data volume expectations more explicitly.
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 concise at four sentences, front-loading the purpose and key constraints. Each sentence adds unique value without redundancy, making it easy for an agent to parse quickly.
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 11 parameters, required fields, and presence of an output schema, the description sufficiently covers usage scenarios, data lag, large-query handling, and tool alternatives. It is complete for an agent to understand invocation context.
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 covers all 11 parameters with 100% description coverage, including details like date formats and coordinate ranges. The description adds general context (e.g., variable name parity with forecast API) but does not significantly enhance individual parameter understanding 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 from the ERA5 archive covering 1940–present. It distinguishes from siblings by specifically mentioning the forecast tool for recent dates, making the purpose unambiguous.
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 explicitly states when to use (historical dates) and when not to (use openmeteo_get_forecast for the last week). It also provides prerequisites like required date parameters and at least one variable set, offering clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openmeteo_get_marineOpenmeteo Get MarineARead-onlyIdempotentInspect
Marine weather forecast for a coastal or ocean coordinate: wave height, wave period, wave direction, wind-wave height, swell height, sea-surface temperature. Forecast horizon up to 7 days. Returns per-timestamp records — each entry contains a "time" field plus one key per requested variable. Best for open-ocean and coastal exposed points — sheltered inland waters return near-zero wave values. Common hourly variables: wave_height, wave_direction, wave_period, wind_wave_height, wind_wave_direction, wind_wave_period, swell_wave_height, swell_wave_direction, swell_wave_period. Common daily: wave_height_max, wave_direction_dominant, wave_period_max. Note: ocean_current_velocity is null for non-open-ocean coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude of a coastal or ocean point. Use openmeteo_geocode to resolve a place name. Inland points return near-zero wave values. | |
| timezone | No | IANA timezone or "auto". Default "auto". | auto |
| longitude | Yes | Longitude in decimal degrees. | |
| forecast_days | No | Forecast horizon in days (1–7). Default 7. | |
| daily_variables | No | Daily marine summary variables (e.g., ["wave_height_max", "wave_direction_dominant", "wave_period_max"]). At least one of hourly_variables or daily_variables required. | |
| hourly_variables | No | Hourly marine variables (e.g., ["wave_height", "wave_direction", "wave_period", "wind_wave_height", "swell_wave_height"]). At least one of hourly_variables or daily_variables required. |
Output Schema
| Name | Required | Description |
|---|---|---|
| daily | No | Per-day summary records with "time" (YYYY-MM-DD) + variable keys (e.g., wave_height_max in meters, wave_direction_dominant in degrees, wave_period_max in seconds). |
| hourly | No | Per-hour records with "time" (ISO 8601) + one key per requested variable (e.g., wave_height in meters, wave_direction in degrees, wave_period in seconds). Absent when only daily_variables were requested. |
| latitude | Yes | Snapped latitude |
| timezone | Yes | Resolved IANA timezone |
| longitude | Yes | Snapped longitude |
| daily_units | No | Variable → unit string for daily data. Absent when no daily_variables were requested. |
| hourly_units | No | Variable → unit string for hourly data (e.g., {"wave_height": "m", "wave_period": "s"}). Absent when no hourly_variables were requested. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations (readOnlyHint, idempotentHint) by explaining forecast horizon (up to 7 days), return format (per-timestamp records with time field), and null behavior for certain coordinates. No contradiction with annotations.
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 compact paragraph that front-loads the purpose and then details variables. It is concise but could be more structured (e.g., bullet points) for easier scanning. No superfluous sentences.
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 the tool's complexity (marine variables, multiple forecast types), the description covers coordinate constraints, variable lists, forecast horizon, return format, and a notable edge case (null ocean_current_velocity). The output schema exists, so return structure does not need full explanation.
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 100% schema coverage, the description still adds meaningful context: it lists common hourly and daily variable names, notes that at least one of hourly_variables or daily_variables is required, and explains that ocean_current_velocity is null for non-open-ocean coordinates.
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 it as a 'Marine weather forecast' with specific variables (wave height, period, etc.), distinguishing it from sibling tools like openmeteo_get_forecast which cover general weather. The verb 'get' combined with 'marine' precisely communicates its scope.
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 usage context: 'Best for open-ocean and coastal exposed points' and warns that 'sheltered inland waters return near-zero wave values.' It also notes null values for ocean_current_velocity. However, it does not explicitly compare with sibling tools or specify when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!