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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_coordinatesC | |
| get_forecastC | Get weather forecast for a location. Args: latitude: Latitude of the location longitude: Longitude of the location |
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 completely distinct purposes: get_coordinates converts a city name to geographic coordinates, while get_forecast provides weather data for given coordinates. There is no overlap or ambiguity between these functions.
Both tools follow a consistent 'verb_noun' naming pattern (get_coordinates, get_forecast) with identical verb style and snake_case convention throughout. The naming is perfectly uniform and predictable.
With only 2 tools, this server feels severely under-scoped for a weather domain. A weather server should typically include current conditions, forecasts, historical data, alerts, and multiple location input methods. Two tools cannot provide meaningful coverage.
The tool surface is severely incomplete for a weather server. Missing essential operations like getting current weather conditions, temperature data, precipitation forecasts, weather alerts, or supporting direct city name input for forecasts. The workflow requires manual coordinate lookup before getting forecasts, creating unnecessary friction.