open-meteo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| geocode_cityA | Resolve a city name to lat/lon via Open-Meteo geocoding. No API key. |
| get_forecastA | Geocode a city, then return current conditions and a short daily forecast from Open-Meteo. No API key. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have distinct purposes: one resolves coordinates, the other returns weather. However, get_forecast internally geocodes a city, creating slight overlap that could confuse an agent about whether geocode_city is a required prerequisite.
Both names follow a clear snake_case verb_noun pattern (geocode_city, get_forecast) with no deviations.
Only two tools is thin for a weather API server. While the tools are focused, the surface feels underdeveloped for the apparent scope of Open-Meteo.
The server covers basic geocoding and a short forecast, but notable operations like hourly forecasts, historical weather, reverse geocoding, and access to additional weather variables are missing.