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.6/5 across 11 of 11 tools scored.
Each tool targets a distinct Open-Meteo API endpoint (forecast, historical, climate, air quality, flood, marine, elevation, geocoding, data canvas). Descriptions and parameters clearly differentiate them, leaving no ambiguity.
All tools share the 'openmeteo_' prefix and mostly follow a verb_noun pattern (e.g., 'get_forecast'), but two tools ('openmeteo_dataframe_describe' and 'openmeteo_dataframe_query') use a noun_verb pattern. This minor inconsistency prevents a perfect score.
11 tools cover the major Open-Meteo APIs without redundancy. The count is well-suited for the server's purpose of providing diverse weather and climate data access.
The tool surface includes all essential weather/climate data types (forecast, historical, ensemble, marine, air quality, flood, elevation, geocoding) and adds data canvas querying for large datasets. No obvious gaps for typical use cases.
Available Tools
11 toolsopenmeteo_dataframe_describeOpenmeteo Dataframe DescribeARead-onlyIdempotentInspect
List the tables and their columns on a DataCanvas staged by openmeteo_get_historical, openmeteo_get_ensemble, or openmeteo_get_climate. 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, openmeteo_get_ensemble, or openmeteo_get_climate 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 indicate read-only and idempotent behavior. The description adds context about the tool's role in the workflow (discovery step) and the source of the canvas ID, enhancing transparency beyond 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, front-loaded with purpose, then usage guidance. No wasted words, efficient structure.
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 simple tool (one parameter, output schema exists), the description fully covers what the tool does and its role in the workflow. No 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 3. The description does not add additional parameter detail beyond what's in the schema, which already describes canvas_id's origin. No extra semantics needed.
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 'List the tables and their columns on a DataCanvas' with a specific verb and resource. It distinguishes from the sibling openmeteo_dataframe_query tool by advising to call this first before querying.
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 clear when-to-use ('Call this first to discover table names before querying with openmeteo_dataframe_query') and implies alternatives by naming the staging tools that produce the canvas.
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, openmeteo_get_ensemble, or openmeteo_get_climate. Pass the canvas_id returned when any of those tools spills (truncated: true), and reference the exact table_name those tools return alongside it. Call openmeteo_dataframe_describe to list staged tables and their columns when you need to discover names.
| 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, openmeteo_get_ensemble, or openmeteo_get_climate when truncated: true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Result rows — a preview capped at 100. When row_count exceeds this, page the rest by re-issuing the SQL with LIMIT / OFFSET. |
| 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 declare readOnlyHint=true. The description adds context on data source and prerequisites (canvas_id, table_name), consistent 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?
Three sentences, front-loaded with core action, no redundant words, well structured.
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?
Covers action, prerequisites, related tools, example query, and read-only nature. Output schema exists, so return values are covered.
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 description adds meaning: sql must be read-only SELECT with example, canvas_id from specific tools with truncated true.
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 runs read-only SQL SELECT against tables from specific staging tools, distinguishing it from sibling tools like openmeteo_dataframe_describe.
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 when to use (after staging tools spill with truncated true), how to get canvas_id and table names, and recommends openmeteo_dataframe_describe for discovering tables.
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. Search by a bare place name (city, region, or landmark); never fold a qualifier into it — pass "Baoding", not "Baoding Hebei", and "Paris", not "Paris, France". To disambiguate places that share a name, set the country input (ISO 3166-1 alpha-2, e.g. "US") and/or read the admin1 and country fields on each ranked result — admin1 is a result field for choosing among matches, not a search input. Returns up to 10 matches ranked by population/relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Place name to search — a bare city, region, or landmark ("Seattle", "Mount Rainier"). Do not fold in a region or country qualifier ("Baoding", not "Baoding Hebei"); use the country input to disambiguate. 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". | |
| country | No | ISO 3166-1 alpha-2 country code (e.g. "US", "FR") to disambiguate places that share a name. Omit for a global search. | |
| language | No | Language for matching and returning place names (ISO 639-1, e.g., "en", "de", "zh"). The API matches name against the localized index for this language, so set it to match the script of name — e.g. language "zh" for "上海", "ru" for "Москва". Default "en"; a query in a recognized non-Latin script (CJK, Hangul, Cyrillic, Arabic, Greek, Hebrew, Thai, Devanagari) that misses under "en" is retried once with the language inferred from its script. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of results returned |
| results | Yes | Ranked matches (most relevant first). Never empty — when nothing matches, the tool fails with no_results instead of returning an empty array. |
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 valuable behavioral details: returns up to 10 matches ranked by population/relevance, language retry logic for non-Latin scripts, and that admin1 is a result field not a search input.
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 well-structured and front-loaded. Each sentence adds value, though it is slightly long. No redundant 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 the tool's role as a geocoding resolver with output schema and annotations, the description covers all necessary aspects: purpose, usage, disambiguation, parameter semantics, and return characteristics. No 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 nuance beyond schema: reiterates the 'no qualifier' rule for name, explains language script inference retry, and clarifies country pattern purpose. This elevates it above baseline.
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 resolves place names to ranked coordinate matches with country, region, elevation, timezone, and population. It distinguishes itself from sibling tools by noting that weather tools require lat/lon, 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?
Explicit guidance on when to use (prerequisite for name-based weather queries), when not to (do not fold qualifiers), and how to disambiguate (use country input or read admin1/country fields). Instructions are clear and actionable.
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_climateOpenmeteo Get ClimateARead-onlyIdempotentInspect
Long-range climate projections from bias-corrected daily CMIP6 models, covering 1950-01-01 to 2050-12-31 at any coordinate. Answers "what will conditions look like through 2050?" — the future-projection counterpart to openmeteo_get_historical (ERA5, what happened). Daily resolution only. Available models: "CMCC_CM2_VHR4", "FGOALS_f3_H", "HiRAM_SIT_HR", "MRI_AGCM3_2_S", "EC_Earth3P_HR", "MPI_ESM1_2_XR", "NICAM16_8S". With 2+ models each variable appears once per model with the model name as suffix (e.g. temperature_2m_max_CMCC_CM2_VHR4); a single or omitted model returns plain variable names. Not all models carry all variables — missing combinations return null. Multi-decade daily pulls across several models produce thousands of records and spill to DataCanvas for SQL querying when canvas is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| models | No | CMIP6 models to include: "CMCC_CM2_VHR4", "FGOALS_f3_H", "HiRAM_SIT_HR", "MRI_AGCM3_2_S", "EC_Earth3P_HR", "MPI_ESM1_2_XR", "NICAM16_8S". With 2+ models each variable column is suffixed with the model name (e.g. temperature_2m_max_MRI_AGCM3_2_S). Omit to use the API default (a single model, unsuffixed columns). | |
| end_date | Yes | End date (YYYY-MM-DD, inclusive, max 2050-12-31). Must be on or after start_date. | |
| 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-decade or multi-model 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., "2049-01-01"). CMIP6 projections cover 1950-01-01 to 2050-12-31. | |
| daily_variables | No | Daily climate variables to fetch (e.g., ["temperature_2m_max", "temperature_2m_min", "precipitation_sum", "wind_speed_10m_mean", "shortwave_radiation_sum"]). Required — the Climate API is daily-only. | |
| wind_speed_unit | No | Wind speed unit. Default "kmh". | kmh |
| temperature_unit | No | Temperature unit. Default "celsius". | celsius |
| precipitation_unit | No | Precipitation unit. Default "mm". | mm |
Output Schema
| Name | Required | Description |
|---|---|---|
| daily | Yes | Per-day records with "time" (YYYY-MM-DD) + one key per requested variable — per-model suffixed keys when 2+ models were requested (e.g. temperature_2m_max_CMCC_CM2_VHR4). Null values mean the model does not carry that variable. When truncated, contains only a preview; query canvas_id for the full dataset. |
| models | No | Climate models requested — echoes the models parameter. Absent when models was omitted (API default model; the response carries no provenance). |
| latitude | Yes | Snapped latitude (Open-Meteo snaps to nearest grid point) |
| timezone | Yes | Resolved IANA timezone |
| canvas_id | No | DataCanvas token — present only when truncated is true (data spilled). 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 |
| table_name | No | DuckDB table name for the staged data — pass to openmeteo_dataframe_query. Present only when truncated is true. |
| daily_units | No | Column → unit string for daily data (e.g., {"temperature_2m_max_CMCC_CM2_VHR4": "°C"}). |
| record_count | Yes | Total number of daily records in this response |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds key behavioral details beyond annotations: daily resolution only, variable name suffixing with multiple models, null returns for missing combinations, and DataCanvas spill for large queries. 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 paragraph but efficiently covers purpose, limitations, model behavior, edge cases, and spill mechanism. It is front-loaded with the main purpose. Could be slightly better structured (e.g., bullet models list), but still concise with 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 11 parameters, 4 required, 100% schema coverage, and an output schema, the description provides comprehensive context: date range, model behavior, null handling, canvas spill for large results, and contrasts with historical tool. It fully equips an agent to understand when and how to use 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 contextualizing parameters: daily_variables as required for daily-only data, models suffixing behavior, and canvas_id spill for large queries. This goes beyond the schema's parameter documentation.
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 long-range climate projections from CMIP6 models covering 1950-01-01 to 2050-12-31 at any coordinate. It explicitly distinguishes from sibling openmeteo_get_historical by calling it the future-projection counterpart, establishing its unique role.
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 tells when to use this tool (for future projections through 2050) and explicitly contrasts it with openmeteo_get_historical for historical ERA5 data. It specifies daily resolution only and explains behavior with multiple models, including variable suffix and null returns for missing combinations.
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") — echoes the requested models parameter. Absent when models was omitted (API default blend; the API reports no provenance). |
| 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 only when truncated is true (data spilled). 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. |
| table_name | No | DuckDB table name for the staged data — pass to openmeteo_dataframe_query. Present only when truncated is true. |
| 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 distinct perturbed ensemble members in the response, counted from the _memberNN column suffixes. The unsuffixed base column (the control run) is not included in this count. |
| 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 indicate read-only and idempotent; description adds critical context: output format (member columns), multi-member large pulls cause DataCanvas spill, model defaults, and forecast horizon limits. 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?
Well-structured with front-loaded key info. Slightly verbose but each sentence adds value (members, models, caveats). No redundant 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 12 parameters and output schema, description covers essential aspects: output naming, model options, large data handling, and variable requirements. Leaves no major gaps for a capable 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 coverage is 100%, baseline 3. Description adds significant value: explains member suffix naming, model member counts, canvas_id purpose, and the requirement for hourly/daily variables, beyond schema definitions.
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?
Clear verb ('get') and resource ('probabilistic ensemble weather forecast') with specific scope (up to 51 members, 16 days). Distinguishes from sibling tools like openmeteo_get_forecast by emphasizing probabilistic nature and ensemble members.
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 use cases: compute exceedance probabilities, quantify uncertainty, build decision thresholds. Mentions required variables and canvas_id for large pulls. Lacks explicit when-not-to-use compared to deterministic forecast, but context is 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 | No | 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 declare readOnlyHint and idempotentHint. The description adds behavioral context: the API snaps to the nearest river, returns null for areas without coverage, and specifies time ranges. 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 front-loaded with purpose and structured with clear sentences. It conveys all essential information without unnecessary verbosity, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (forecast and historical combined, multiple parameters, null returns), and presence of an output schema, the description covers all key aspects: data source, time ranges, parameter usage, variables, and edge cases.
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 how parameters interact (combining historical and forecast), giving examples of daily variables, and clarifying the snapping behavior and date ranges.
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 GloFAS river discharge forecasts and historical reanalysis. It specifies it returns data for the nearest river to given coordinates, distinguishing it from general forecast or historical tools among its 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?
The description explains when to use start_date/end_date for historical data and forecast_days for future forecasts, noting both can be combined. It implicitly guides usage by not mentioning alternatives, but lacks explicit when-not-to-use or comparisons 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_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 only when truncated is true (data spilled). 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 |
| table_name | No | DuckDB table name for the staged data — pass to openmeteo_dataframe_query. Present only when truncated is true. |
| 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?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral details: ERA5 has ~5-day lag, large date ranges spill to DataCanvas, and at least one variable array is required. No contradictions 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?
Five sentences, front-loaded with the main purpose. Each sentence adds essential information without redundancy. Structured logically: data source, date requirements, alternative tool, spill behavior, variable requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 4 required, output schema present), the description covers data source, time range, alternative tool, large-result handling, and required variables. Output schema exists, so return values are not needed. Complete for an AI agent to select and invoke correctly.
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 meaning: start_date/end_date specify ISO format and ERA5 range, daily/hourly variables include examples, canvas_id explains spill behavior, latitude mentions geocode. However, some parameters (temperature_unit, precipitation_unit) are already well-described in the schema, limiting additional value.
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 historical weather from the ERA5 reanalysis archive (1940–present). The verb 'get' combined with the specific resource 'historical weather from ERA5' and mentions of date range and variable requirements make the purpose distinct from 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?
Explicitly tells when to use this tool vs. the forecast sibling: 'For dates within the last week, use openmeteo_get_forecast with past_days instead.' Also explains when DataCanvas spill occurs for large queries, providing clear guidance.
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!