OpenWeatherMap MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct, covering specific weather and location data types like current weather, forecasts, air pollution, and geocoding. However, there is some overlap between 'get-daily-forecast', 'get-weather-forecast', and 'get-onecall-weather', which could cause confusion as they all provide forecast data with different scopes or formats.
Naming Consistency5/5
All tool names follow a consistent 'get-' or 'geocode-' prefix pattern with descriptive kebab-case nouns, such as 'get-current-weather' and 'geocode-location'. This uniformity makes the tools predictable and easy to understand at a glance.
Tool Count5/5
With 11 tools, the server is well-scoped for an OpenWeatherMap integration, covering a comprehensive range of weather and location services. Each tool serves a distinct purpose, from basic weather queries to specialized forecasts and alerts, without feeling bloated or sparse.
Completeness5/5
The tool set provides complete coverage for weather and location data, including current conditions, various forecast types (minutely, hourly, daily), air pollution, alerts, and geocoding. There are no obvious gaps, enabling agents to handle a wide range of weather-related queries effectively.
Average 2.9/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Get current air quality data' implies a read-only operation but doesn't specify data freshness, rate limits, authentication requirements, error conditions, or response format. For a tool that likely makes external API calls, this leaves significant behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, which is appropriate for a simple data retrieval tool. It's front-loaded with the core purpose. However, given the lack of differentiation from siblings and missing behavioral context, this brevity might be under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (retrieving current air quality data likely involves external API calls), no annotations, no output schema, and multiple similar sibling tools, the description is incomplete. It doesn't explain what 'current' means, what data is returned, how it differs from 'get-air-pollution', or any operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has 100% coverage with a well-documented 'location' parameter. Since schema_description_coverage is high (100%), the baseline score is 3. The description adds no parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current air quality data' clearly states the verb ('Get') and resource ('current air quality data'), making the basic purpose understandable. However, it doesn't distinguish this tool from its sibling 'get-air-pollution' - both appear to retrieve air pollution data, so the distinction isn't clear from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. With multiple weather/pollution-related siblings including 'get-air-pollution', 'get-current-weather', and various forecast tools, there's no indication of what makes this tool unique or when it should be preferred over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the conversion action but lacks details on error handling, rate limits, authentication needs, or what happens with ambiguous queries. For a tool with no annotation coverage, this is a significant gap in transparency about its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single, clear sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of geocoding (which can involve ambiguous inputs and varied outputs), the lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or how reverse geocoding works (coordinates to location name). For a tool with no structured support, more contextual detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'limit') with clear descriptions. The tool description adds no additional meaning beyond what the schema provides, such as examples or edge cases. With high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting location names to coordinates or vice versa. It specifies the verb 'convert' and the resource 'location', making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-location-info', which might provide similar or overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, and with sibling tools like 'get-location-info' available, there's no indication of how this tool differs or when it should be preferred. This lack of comparative guidance limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what data is retrieved but doesn't mention any behavioral traits such as rate limits, authentication requirements, data freshness (real-time vs. cached), error conditions, or response format. For a data retrieval tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with a single, clear sentence: 'Get air quality index and pollution data'. Every word earns its place, with no redundant or unnecessary information. It efficiently communicates the core purpose without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of environmental data tools and the lack of annotations and output schema, the description is incomplete. It doesn't address key contextual aspects like data sources, temporal scope (current vs. historical), units of measurement, or how results are structured. For a tool with no structured output information, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('latitude' and 'longitude') clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema (e.g., it doesn't explain coordinate systems, precision requirements, or geographic scope). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get air quality index and pollution data' with a specific verb ('Get') and resource ('air quality index and pollution data'). However, it doesn't distinguish itself from the sibling tool 'get-current-air-pollution', which appears to serve a very similar purpose, making differentiation unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get-current-air-pollution' and 'get-current-weather' available, there's no indication of whether this tool is for historical data, specific timeframes, or how it differs from other pollution/weather tools. Usage context is implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It lacks information about rate limits, error handling, data freshness, authentication needs, or response format. For a read operation with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too minimal. It doesn't explain what 'current weather conditions' includes (temperature, humidity, etc.), response format, or behavioral constraints. Given the complexity and lack of structured data, it should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no parameter-specific information beyond what's in the schema. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current weather conditions for a location', making the purpose explicit. It distinguishes from siblings like forecasts or alerts by specifying 'current' conditions, but doesn't explicitly contrast with all alternatives like 'get-weather-forecast'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-daily-forecast' or 'get-hourly-forecast'. It mentions 'current weather conditions' which implies real-time data, but offers no explicit usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 8-day limit but doesn't cover other critical aspects like rate limits, authentication needs, error handling, or what the output looks like (e.g., format, data fields). For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating the tool's function and key constraint (8-day limit), making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the forecast includes (e.g., temperature, precipitation), how results are structured, or any behavioral traits like rate limits. For a tool with 4 parameters and rich functionality, this leaves too much undefined for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain interactions between parameters like 'days' and 'include_today'). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get daily weather forecast') and resource ('weather forecast'), specifying the scope ('for up to 8 days'). It distinguishes from siblings like 'get-current-weather' by focusing on daily forecasts, though it doesn't explicitly differentiate from 'get-weather-forecast' which might be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-hourly-forecast' or 'get-weather-forecast'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a forecast but doesn't describe key behavioral traits such as data format, potential errors (e.g., invalid location), rate limits, authentication needs, or whether it's a read-only operation. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get minute-by-minute precipitation forecast for next hour.' It efficiently conveys the core purpose without unnecessary words, making it easy for an agent to parse. Every part of the sentence earns its place by specifying key details like granularity and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a weather forecasting tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., error handling, data format), usage context relative to siblings, and output details. While the schema covers parameters well, the overall context for effective tool invocation is insufficient, especially for a tool that likely returns structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('limit' and 'location'), including constraints and examples. The description doesn't add any semantic details beyond what the schema provides (e.g., it doesn't explain how 'location' affects the forecast or the meaning of 'precipitation' in the output). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get minute-by-minute precipitation forecast for next hour.' It specifies the action ('Get'), resource ('precipitation forecast'), and temporal scope ('minute-by-minute... for next hour'), which is specific and informative. However, it doesn't explicitly distinguish this tool from sibling tools like 'get-hourly-forecast' or 'get-daily-forecast' in terms of granularity or precipitation focus, missing full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-hourly-forecast' or 'get-daily-forecast' for comparison, nor does it specify use cases or exclusions (e.g., when precipitation data is needed vs. general weather). This leaves the agent without context for tool selection among similar weather-related options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'comprehensive weather data' but doesn't describe what that includes beyond 'current + 7-day forecast', nor does it mention rate limits, authentication needs, error conditions, or response format. For a weather API tool with no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without waste. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a weather data tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'comprehensive' means beyond mentioning current and 7-day forecast, nor does it help the agent understand when to choose this tool over its many specialized siblings. The description should provide more context about the tool's scope and differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description adds no parameter information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive weather data (current + 7-day forecast)'. It specifies both the verb ('Get') and the resource ('weather data') with scope details. However, it doesn't explicitly distinguish this comprehensive tool from its many siblings that provide specific weather components (current, hourly, daily, etc.), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its many siblings. With tools like get-current-weather, get-daily-forecast, get-hourly-forecast, and get-weather-forecast available, the agent receives no help in choosing between comprehensive data (this tool) versus specific components (siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Get active weather alerts and warnings' implies a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns real-time or historical data, or what format the alerts come in. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just five words, front-loading the essential purpose with zero wasted language. Every word earns its place: 'Get' (action), 'active' (temporal scope), 'weather alerts and warnings' (resource). This is a model of efficient tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a weather alert tool with no annotations and no output schema, the description is insufficiently complete. It doesn't indicate what types of alerts are returned (severe thunderstorm, flood, tornado), whether alerts are filtered by severity, what geographic scope applies, or what the response format looks like. Given the complexity of weather alert systems and the lack of structured metadata, more contextual information would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single 'location' parameter fully documented in the schema. The description adds no additional parameter information beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide extra context about how location affects alert retrieval.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('active weather alerts and warnings'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get-current-weather' or 'get-weather-forecast', but the focus on 'alerts and warnings' provides some implicit distinction from general weather data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-current-weather' and 'get-weather-forecast' available, there's no indication whether this tool should be used for emergency situations, severe weather only, or as a complement to other weather tools. The user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the forecast duration ('up to 5 days') but doesn't cover other important aspects like rate limits, authentication requirements, error handling, or what the forecast includes (e.g., temperature, precipitation). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without unnecessary words. It's front-loaded with the main purpose and appropriately sized for the tool's complexity. Every part of the sentence earns its place by specifying key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the forecast returns (e.g., data structure, time intervals), potential limitations, or how it differs from sibling tools. For a weather forecasting tool with multiple similar alternatives, more context is needed to help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's already in the input schema, which has 100% coverage. It mentions 'up to 5 days', which aligns with the 'days' parameter's description in the schema, but provides no additional context about parameter interactions or usage examples. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get weather forecast for up to 5 days'. It specifies the verb ('Get'), resource ('weather forecast'), and scope ('up to 5 days'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'get-daily-forecast' or 'get-hourly-forecast', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-daily-forecast', 'get-hourly-forecast', and 'get-current-weather', the agent is left to infer usage based on tool names alone. No explicit when/when-not statements or alternative recommendations are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 48-hour limit, which is useful, but doesn't cover other important aspects like rate limits, authentication needs, error handling, or what the output format looks like (e.g., JSON structure, timestamps). For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get hourly weather forecast') and includes the key constraint ('for up to 48 hours'). There is no wasted text, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and scope but lacks details on usage guidelines, behavioral traits, and output format. With no output schema, the description should ideally hint at what data is returned, but it doesn't, leaving the agent uncertain about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all three parameters (hours, location, units). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting. However, it doesn't compensate for any gaps since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('hourly weather forecast') with a specific scope ('for up to 48 hours'). It distinguishes from siblings like 'get-daily-forecast' by specifying 'hourly' but doesn't explicitly differentiate from 'get-minutely-forecast' or 'get-weather-forecast' which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get-daily-forecast' or 'get-current-weather'. The description mentions the 48-hour limit but doesn't explain if this is the best tool for short-term vs. long-term forecasts or how it relates to other forecast tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication needs, error handling (e.g., invalid coordinates), or what happens with edge cases (e.g., coordinates over water). The phrase 'reverse geocoding' hints at a standard mapping service behavior, but lacks specifics needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get location information') and adds clarifying context ('from coordinates (reverse geocoding)'). There is zero wasted verbiage, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (reverse geocoding with 2 parameters), no annotations, and no output schema, the description is incomplete. It fails to explain what information is returned (e.g., address components, place types), potential limitations (e.g., coverage areas, accuracy), or how results are structured. This leaves significant gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for latitude and longitude parameters including valid ranges. The description adds no additional parameter semantics beyond what's in the schema, such as coordinate format (e.g., decimal degrees), precision requirements, or examples. Baseline 3 is appropriate since the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get location information') and the method ('from coordinates (reverse geocoding)'), which distinguishes it from sibling tools like 'geocode-location' (likely forward geocoding). However, it doesn't specify what type of location information is returned (e.g., address, place name, administrative details), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have coordinates and need location information, but provides no explicit guidance on when to use this versus alternatives like 'geocode-location' (which likely converts addresses to coordinates). There's no mention of prerequisites, error conditions, or performance considerations, leaving usage context partially implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-openweathermap MCP server](https://glama.ai/mcp/servers/robertn702/mcp-openweathermap/badges/card.svg)](https://glama.ai/mcp/servers/robertn702/mcp-openweathermap)

Score Badge

Copy to your README.md:

[![mcp-openweathermap MCP server](https://glama.ai/mcp/servers/robertn702/mcp-openweathermap/badges/score.svg)](https://glama.ai/mcp/servers/robertn702/mcp-openweathermap)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/robertn702/mcp-openweathermap'

If you have feedback or need assistance with the MCP directory API, please join our Discord server