Skip to main content
Glama

open-meteo-mcp-server

by io.github.cyanheads

Openmeteo Dataframe Query

openmeteo_dataframe_query
Read-only

Run a read-only SQL SELECT against tables staged on a DataCanvas by openmeteo_get_forecast, openmeteo_get_historical, openmeteo_get_marine, openmeteo_get_air_quality, openmeteo_get_ensemble, openmeteo_get_flood, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesRead-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_idYesCanvas ID returned by openmeteo_get_forecast, openmeteo_get_historical, openmeteo_get_marine, openmeteo_get_air_quality, openmeteo_get_ensemble, openmeteo_get_flood, or openmeteo_get_climate when truncated: true.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoResult rows — a preview capped at 100. When row_count exceeds this, page the rest by re-issuing the SQL with LIMIT / OFFSET.
errorNoPresent when the call failed. Absent on success.
canvas_idNoCanvas ID that was queried.
row_countNoTotal rows in the full result before any cap.

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reinforces the read-only nature (matching the readOnlyHint annotation) and adds useful context about the spill/truncation mechanism and the requirement to reference the exact table names. This goes beyond the annotation alone, clarifying that the tool operates on staged data and is safe to call without side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no waste. The core action is stated first, followed by the necessary context on origin and discovery, and the alternative tool. Every sentence earns its place, and the description is appropriately front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (so return format is already captured), the description covers all operational essentials: when to use, what inputs to supply, and how to discover table names. An agent has everything needed to invoke it correctly without further research.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, both parameters are already well-documented. The description adds value by clarifying the provenance of canvas_id (returned by specific tools when truncated) and how sql should reference table names discovered via describe, enriching the schema definitions and reducing ambiguity for an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Run a read-only SQL SELECT') and resource ('tables staged on a DataCanvas'), and explicitly names the sibling tools that stage those tables. It clearly distinguishes itself from the describe tool by focusing on querying rather than listing, leaving no ambiguity about its function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: it should be called when any of the listed openmeteo_get_* tools return truncated: true, and it references the canvas_id and table_name from those tools. It also directs the agent to openmeteo_dataframe_describe when table discovery is needed, effectively outlining both when to use this tool and when to use its sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All open-meteo-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Each weather data tool (forecast, historical, marine, air_quality, ensemble, flood, climate) targets a distinct domain and data source, so they are largely unambiguous. However, openmeteo_get_forecast with past_days and openmeteo_get_historical overlap for recent dates, though the descriptions explicitly clarify which to use when, slightly muddying the boundary.

Naming Consistency5/5

Tool names follow a consistent openmeteo_<verb>_<object> pattern with clear actions (get, search, describe, query) and objects (forecast, historical, marine, air_quality, ensemble, flood, climate, elevation, locations, dataframe). This is highly predictable and uniform across all 11 tools.

Tool Count5/5

With 11 tools, the server covers a comprehensive set of weather data categories (forecast, historical, marine, air quality, ensemble, flood, climate, elevation) plus location search and dataframe utilities. This is well-scoped for a data-heavy weather API without being bloated, and each tool serves a distinct purpose.

Completeness5/5

The tool surface covers all major weather data needs: forecasts, historical reanalysis, marine conditions, air quality, ensemble forecasts, flood discharge, climate projections, and elevation. Location search is a proper prerequisite for coordinate-based queries, and dataframe query/describe handle large result sets, filling any gaps for data analysis workflows.

Resources