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
6 toolsopenmeteo_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_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!