Skip to main content
Glama

open-meteo-mcp-server

by io.github.cyanheads

Openmeteo Search Locations

openmeteo_search_locations
Read-onlyIdempotent

Resolve a place name to ranked coordinate matches with country, region, elevation, timezone, and population. Required prerequisite for name-based queries — all weather tools take latitude/longitude, not place names. Search by a bare place name (city, region, or landmark); never fold a qualifier into it — pass "Baoding", not "Baoding Hebei", and "Paris", not "Paris, France". To disambiguate places that share a name, set the country input (ISO 3166-1 alpha-2, e.g. "US") and/or read the admin1 and country fields on each ranked result — admin1 is a result field for choosing among matches, not a search input. Returns up to 10 matches ranked by population/relevance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPlace name to search — a bare city, region, or landmark ("Seattle", "Mount Rainier"). Do not fold in a region or country qualifier ("Baoding", not "Baoding Hebei"); use the country input to disambiguate. Weather tools require coordinates — use the lat/lon from this result.
countNoMax results to return (1–10). Default 5. Return more when disambiguating common names like "Springfield" or "Portland".
countryNoISO 3166-1 alpha-2 country code (e.g. "US", "FR") to disambiguate places that share a name. Omit for a global search.
languageNoLanguage for matching and returning place names (ISO 639-1, e.g., "en", "de", "zh"). The API matches name against the localized index for this language, so set it to match the script of name — e.g. language "zh" for "上海", "ru" for "Москва". Default "en"; a query in a recognized non-Latin script (CJK, Hangul, Cyrillic, Arabic, Greek, Hebrew, Thai, Devanagari) that misses under "en" is retried once with the language inferred from its script.en

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNumber of results returned
errorNoPresent when the call failed. Absent on success.
resultsNoRanked matches (most relevant first). Never empty — when nothing matches, the tool fails with no_results instead of returning an empty array.

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and idempotentHint, so the baseline is lower. The description adds behavioral details like ranking by population/relevance, the localized index matching, and a retry mechanism for non-Latin scripts. This goes beyond the annotation and clarifies how the search behaves.

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 front-loaded with the core purpose, then provides usage guidance and parameter details. It is somewhat verbose, repeating schema descriptions, but remains well-structured and not excessive given the complexity of language handling and disambiguation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description includes the purpose, usage context, parameter nuances, and return behavior (ranked coordinate matches, up to 10 results). Since an output schema exists, it doesn't need to detail the return structure, but it still gives sufficient context for an agent to decide when and how to call it.

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?

Schema coverage is 100% and each parameter has a description, so baseline is 3. However, the description adds meaningful guidance beyond the schema, such as 'never fold a qualifier into the name' and the language retry logic for non-Latin scripts. This extra context helps the agent use parameters more effectively.

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 resolves a place name to ranked coordinate matches with specific fields (country, region, elevation, timezone, population). It explicitly positions itself as a prerequisite for name-based queries, distinguishing it from sibling weather tools that take coordinates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says this is a required prerequisite for name-based queries, and that all weather tools take latitude/longitude. It provides concrete usage rules: use a bare place name, never fold in qualifiers, and use the country parameter for disambiguation. This leaves no ambiguity about when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All open-meteo-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Each weather data tool (forecast, historical, marine, air_quality, ensemble, flood, climate) targets a distinct domain and data source, so they are largely unambiguous. However, openmeteo_get_forecast with past_days and openmeteo_get_historical overlap for recent dates, though the descriptions explicitly clarify which to use when, slightly muddying the boundary.

Naming Consistency5/5

Tool names follow a consistent openmeteo_<verb>_<object> pattern with clear actions (get, search, describe, query) and objects (forecast, historical, marine, air_quality, ensemble, flood, climate, elevation, locations, dataframe). This is highly predictable and uniform across all 11 tools.

Tool Count5/5

With 11 tools, the server covers a comprehensive set of weather data categories (forecast, historical, marine, air quality, ensemble, flood, climate, elevation) plus location search and dataframe utilities. This is well-scoped for a data-heavy weather API without being bloated, and each tool serves a distinct purpose.

Completeness5/5

The tool surface covers all major weather data needs: forecasts, historical reanalysis, marine conditions, air quality, ensemble forecasts, flood discharge, climate projections, and elevation. Location search is a proper prerequisite for coordinate-based queries, and dataframe query/describe handle large result sets, filling any gaps for data analysis workflows.

Resources