open-meteo-mcp-lite

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clear, distinct purpose: two manage default location, one searches locations, and three retrieve weather data (current, daily forecast, hourly forecast). Potential overlap between get_forecast and get_hourly_forecast is resolved by descriptions explicitly distinguishing daily vs hourly granularity.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: get_* for retrieval, set_* for configuration, search_* for lookup. The naming is predictable and uniform across the entire set.
Tool Count5/5
Six tools is well-scoped for a weather API lite server, covering configuration, location search, and three data retrieval modes. The count is neither sparse nor excessive, and each tool serves a necessary function.
Completeness5/5
The tool set covers the core workflow: search location, set/get default location, get current weather, and get daily or hourly forecasts. Minor omissions like clearing a default location or historical data are acceptable given the 'lite' designation, and no critical operation is missing.
Average 3.5/5 across 6 of 6 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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, the description carries the full burden. It discloses the 16-day limit but fails to explain how location is specified (city name vs. coordinates), whether the tool is read-only, or any error/return behavior. This is insufficient for a tool with four optional parameters.
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 with no wasted words. It efficiently communicates the core function and a key constraint.
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 has four optional parameters and sibling tools that target similar functionality, the description is too sparse. It does not clarify how to select a location (city vs. coordinates), what happens if both are provided, or how this differs from get_weather/get_hourly_forecast. The lack of an output schema makes this gap more significant.
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 already provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The description adds no additional meaning about parameter usage or precedence, simply repeating the day limit already present in the schema.
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 gets a weather forecast for a location, with an explicit 16-day limit. It distinguishes from siblings like get_hourly_forecast by focusing on the forecast aspect, though it doesn't differentiate explicitly from get_weather.
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_hourly_forecast or get_weather. The description does not mention any exclusions, prerequisites, or situational context.
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. It discloses the time range but does not explain location resolution when both location and coordinates are supplied, nor does it describe error handling, response format, or other behavioral traits. The only added value is the hour limit, which is already present in the schema's maximum constraint.
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 sentence that is front-loaded with the verb and resource. Every word contributes to the core meaning, with no filler.
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 four optional parameters with potential ambiguity (location name vs coordinates) and no output schema, the description is not sufficient for correct invocation. It fails to specify precedence or interaction between location fields, and the sibling tool search_location suggests location naming may require resolution. The tool is relatively simple but has hidden complexity.
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 already describes all four parameters with types, ranges, and descriptions (100% coverage), so the baseline is 3. The description adds no additional meaning beyond re-stating the hour range; it does not clarify the relationship between location and latitude/longitude.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 with a specific verb and resource: 'Get hourly weather forecast for a location' and adds a precise scope (up to 384 hours / 16 days). This distinguishes it from sibling tools like get_forecast, which likely covers non-hourly forecasts.
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 does not explicitly state when to use this tool versus alternatives such as get_forecast or get_weather. The hourly scope implies use cases, but no exclusions or alternative recommendations are provided, leaving the agent to infer based on the tool name.
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 only restates the core function, failing to mention how location is resolved (e.g., default location, city vs coordinates), what happens if no parameters are provided (all are optional), or any response details.
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, straightforward sentence with no redundant information. It is appropriately sized for a simple tool and front-loads the key action.
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?
The description leaves ambiguity about how to specify a location (given three optional parameters) and what the output looks like, since there is no output schema. It also does not mention if a default location is used when no parameters are provided, which is relevant given sibling tools for default locations.
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 all parameters are already described clearly. The tool description adds no additional meaning beyond what the schema provides, aligning with the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('current weather conditions') for a location. It distinguishes itself from sibling tools like get_forecast and get_hourly_forecast by focusing on current conditions.
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 word 'current' implies usage for immediate conditions versus forecasts, but the description provides no explicit guidance on when to prefer this tool over siblings or how to specify the location. It does not mention prerequisites like searching for a location first.
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 states the basic function but does not mention whether the operation is read-only, how results are ordered, or any side effects. The lack of such context leaves significant ambiguity for an agent.
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 concise sentence that is front-loaded with the action verb. Every word earns its place, with no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and full schema coverage, the description adequately covers the primary purpose and output. It does not elaborate on the return format, but the statement 'get coordinates' provides sufficient context given the low complexity.
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%, so the baseline is 3. The description does not add any additional meaning beyond the schema; it neither explains parameter relationships nor provides extra context, so it remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' with a clear resource 'location' and states the outcome 'get coordinates'. It is easily distinguished from sibling tools like set_default_location or get_weather, which serve different purposes.
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 the tool is used to look up a location by name, but it does not explicitly state when to use it over alternatives, nor does it mention any exclusions. There is no reference to sibling tools or conditions, so guidance is only implicit.
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, and the description only states the action without disclosing any behavioral details like return format, error handling when no default location is configured, or whether it requires prior setup. The description does not say what the tool returns or what 'default location' means in practice.
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, concise sentence that immediately states the tool's purpose without any filler. It is front-loaded and contains exactly the necessary information for a simple getter.
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?
For a zero-parameter tool, the description is largely complete, but since there is no output schema, it does not specify the format of the returned location (e.g., string, object, lat/long). This leaves some ambiguity about how the output can be used with sibling tools like get_weather, which may require a location format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meanings. The schema already covers everything trivially, and the empty parameter list is self-explanatory. The description adds no parameter information because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the currently configured default location' uses a specific verb ('Get') and a clear resource ('default location'), distinguishing it from sibling tools like set_default_location (mutates) and search_location (searches arbitrary locations).
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 gives a clear purpose but does not explicitly state when to use this tool versus alternatives such as search_location for finding locations or get_weather for weather data. Usage is implied rather than explicitly scoped.
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, the description carries full burden for behavioral disclosure. It indicates a state-changing operation but does not disclose whether it overwrites an existing default, the persistence scope, or any validation/error behavior. This is a significant gap for a mutation tool.
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?
A single, front-loaded sentence that uses the verb 'set' and includes the key context. No redundancy or wasted words.
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?
The tool has moderate complexity (4 optional parameters, no output schema, no annotations). The description covers the core purpose but omits details on parameter grouping, persistence, and expected return. It is adequate but not complete.
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 each parameter has a description. The tool description does not add clarity on the required combination (location OR latitude/longitude+name), but since the schema already documents individual parameters, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (set) and resource (default location), and adds the context of weather queries with no location specified. This distinguishes it from siblings like get_default_location and search_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to establish a default so weather queries can omit location. It does not explicitly mention alternatives or exclusions, but the sibling tools' names and the clear verb 'set' provide enough context for the agent.
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:

[![open-meteo-mcp-lite MCP server](https://glama.ai/mcp/servers/ominiverdi/open-meteo-mcp-lite/badges/card.svg)](https://glama.ai/mcp/servers/ominiverdi/open-meteo-mcp-lite)

Score Badge

Copy to your README.md:

[![open-meteo-mcp-lite MCP server](https://glama.ai/mcp/servers/ominiverdi/open-meteo-mcp-lite/badges/score.svg)](https://glama.ai/mcp/servers/ominiverdi/open-meteo-mcp-lite)

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/ominiverdi/open-meteo-mcp-lite'

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