Weather MCP
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_locationsC | Find weather locations matching a place name. |
| get_weatherC | Get current conditions and a daily forecast. |
| weather_dashboardC | Show an interactive weather dashboard with location and unit controls. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Prefab Renderer (weather_dashboard) |
TDQS
Scored across 3 tools
Each tool has a distinct purpose: location search, weather data retrieval, and an interactive dashboard. No overlap or ambiguity in their functions.
Two tools follow the verb_noun pattern (search_locations, get_weather), but weather_dashboard breaks the pattern by leading with a noun. This is a minor deviation that doesn't cause confusion.
Three tools is lean but appropriately scoped for a weather server. It covers the essential workflows without unnecessary bloat.
The core workflow of searching locations and getting weather is covered. Missing advanced features like alerts or historical data, but these are not critical for a basic weather service.