MCP weather 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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_forecastA | Get the weather forecast for a city on one day. Args: city: City name, for example Lisbon day: Date as YYYY-MM-DD, within the next 16 days |
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 1 tool
With a single tool there is nothing to confuse it with; the purpose (daily forecast for a city) is unambiguous. An agent cannot misselect among tools here.
get_forecast follows a clear verb_noun convention, though with only one tool there is no pattern to actually verify. It is readable and predictable, but consistency is untested.
One tool is thin even for a narrowly scoped weather server; users would reasonably expect current conditions or multi-day output. It is not mismatched to the stated purpose, but it is on the sparse edge.
The surface covers only a single-day forecast, with no tool for current conditions, multi-day ranges, alerts, or location lookup/geocoding. These are standard weather operations that agents would commonly need and cannot work around with this set.