Weather MCP Server
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_alertsD | – |
| get_forecastD | – |
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 clearly distinct purposes: get_alerts retrieves weather alerts or warnings, while get_forecast provides weather predictions. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the need for current alerts versus future forecasts.
Both tools follow a consistent verb_noun pattern with 'get_' as the prefix, ensuring predictability and readability. The naming is uniform across the set, with no deviations in style or convention, which aids in tool identification and usage.
With only two tools, the server feels thin for a weather domain that typically includes more operations like current conditions, historical data, or location-based queries. While the tools cover alerts and forecasts, the scope is limited, potentially hindering comprehensive weather-related tasks.
The tool set is severely incomplete for a weather server, missing core functionalities such as getting current conditions, searching locations, or accessing historical data. Agents will face significant gaps when trying to perform common weather-related workflows, leading to potential failures or workarounds.