meteoswiss-mcp

Server Quality Checklist

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

Latest release: v0.6.1
Disambiguation5/5
Each tool targets a distinct meteorological resource: station metadata, current obs, forecasts, climate normals, warnings, and an aggregated school-specific check. There is no overlap or ambiguity between them.
Naming Consistency5/5
All six tools follow a consistent 'meteo_' prefix plus a clear noun or composite noun (stations, current, forecast, school_check, climate_normals, warnings). The pattern is uniform and predictable.
Tool Count5/5
Six tools provide a well-scoped coverage of weather data and domain-specific analysis for an MCP server focused on Swiss meteorology. No tool feels redundant and none are missing to justify a larger set.
Completeness4/5
The server covers the core weather workflows: station lookup, current conditions, forecasts, climatological normals, and warnings. A minor gap is the lack of historical actual observations (e.g., past dates), but the provided climate normals and current/forecast data cover typical planning needs.
Average 4.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 48 commits in the last 12 weeks
- Last stable release on August 2, 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds that the tool is not idempotent and provides live data, plus a fallback behavior on upstream failure. This adds value beyond annotations.
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 uses structured XML-like tags for use case, notes, and example, making it easy to parse. It is not overly long but includes some redundancy (e.g., repeating '10-Minuten-Werte' in notes and example). Still well-organized.
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?
The description covers the use case, important behavioral notes, and provides an example. The tool has an output schema, so return values are documented elsewhere. Missing details like exact number of observations or error handling, but overall sufficient for a simple data retrieval tool.
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 descriptions for station and response_format. The tool description provides an example mapping a station code to a location, adding minimal extra meaning. With schema coverage indicated as 0%, the description does not fully compensate but the schema itself has some descriptions.
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 it retrieves current 10-minute weather measurements from a SwissMetNet station, listing measurement types (temperature, precipitation, etc.). It distinguishes from sibling tools (forecast, climate normals, etc.) by focusing on current observations.
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 includes a use case tag and important notes (granularity, data source, idempotency) that provide context. However, it does not explicitly state when not to use this tool or contrast with siblings, though the sibling names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds behavioral context: it explains internal steps (geocoding, forecast, threshold check) and sources (SUVA/BAG). It doesn't contradict annotations.
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 structured with tags (use_case, important_notes, example) which aids readability. It is somewhat lengthy but every section serves a purpose. Could be slightly more concise.
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?
Given the tool's complexity (multi-step aggregation with thresholds), the description covers the key aspects: what it does, thresholds, date behavior, and examples. It assumes output schema exists, which is acceptable.
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?
While the schema descriptions provide good coverage (contradicting the 0% metric), the tool description adds value through examples and threshold context, clarifying how parameters influence results.
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 it aggregates geocoding, 7-day forecast, and threshold check into a traffic light rating for outdoor school events. It explicitly distinguishes itself from meteo_forecast by saying it replaces the combination of forecast plus manual evaluation.
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 specifies when to use this tool (for school outdoor events) and mentions it replaces meteo_forecast plus manual evaluation. However, it does not explicitly list when not to use each sibling tool, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds context that data is static and no network roundtrip is needed, reinforcing the annotations without contradiction.
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 well-structured with use_case, important_notes, and example sections. It is concise with no superfluous content.
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?
Given the tool's simplicity, the description covers all necessary aspects: purpose, period, embedded stations, fallback, idempotence, and examples. It is complete.
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 input schema already provides descriptions for parameters (station with examples, response_format as enum). The tool description adds examples and contextual notes (e.g., embedded stations), which supplement the schema.
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 provides monthly 30-year climate normals for a MeteoSwiss station, including temperature, precipitation, and sunshine hours. It distinguishes itself from sibling tools like meteo_current and meteo_forecast by being a static reference for 'typical weather'.
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 provides explicit use cases such as school planning, event budgeting, and comparison with current measurements. It also includes important notes about the period, embedded stations, and fallback behavior, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds behavioral details: live backend, no nationwide endpoint, aggregation logic, warning scale, and environment variable override. Provides substantial context beyond annotations.
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?
Well-structured with <use_case>, <important_notes>, <example>, Args, Returns. Front-loaded with purpose. Slightly lengthy but each section earns its place. Could trim some notes.
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?
Covers usage, parameters, behavior, examples, and environment variable. Output schema exists for ResponseFormat. Complete for a live-data aggregation tool with multiple filtering options.
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 has descriptions for each parameter, but the description reinforces meaning: plz for precise location, canton for filtering, language, response_format. Adds value beyond schema (e.g., 'Präziser als canton'). Coverage signal 0% may be inaccurate, but description compensates.
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 it retrieves active official MeteoSwiss weather warnings live, and distinguishes from sibling tools (meteo_stations, meteo_current, etc.) which focus on other weather data.
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 <use_case> section explains when to use it (live warnings, nationwide, per canton, or per PLZ). Examples show different parameter combos. Sibling tool names imply alternatives, but no explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds curated selection, school/urban focus, data source, and license beyond annotations. No contradictions with readOnlyHint=true, destructiveHint=false.
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?
Well-structured with sections (use_case, important_notes, example, args, returns). Every sentence adds value without being verbose.
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?
Comprehensive coverage of what the tool does, how to use it, and what it returns, given the output schema and annotations.
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?
Despite 0% schema coverage, description explains both parameters (canton and response_format) with examples and default behavior, adding meaning.
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?
Clearly states it lists SwissMetNet stations to find station abbreviations for meteo_current or meteo_climate_normals. Distinguishes from siblings by naming them directly.
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?
Explicitly says use to find station abbreviations for related tools. Provides example with canton filtering. Does not state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral context: the hybrid model source (ICON for first 5 days, best_match beyond), geocoding with fuzzy fallback, hourly data limitation to 48 hours, and direct-link fallback on upstream failure. It also discloses that responses include provenance fields (`modell`/`modell_details`). No contradiction with annotations.
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 well-organized with clear sections (use_case, important_notes, example, args, returns). Every section contributes value—purpose, behavioral nuances, invocation examples, and parameter explanations—without redundancy or padding. It is 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all critical aspects: model provenance, geocoding fallback, hourly data range, failure handling, and response format. With an output schema present, the concise Returns statement suffices. The tool's complexity is fully addressed, leaving no significant gaps for an agent to misuse it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the top-level schema parameter has no description (0% coverage), the description explicitly enumerates each field under 'Args' and adds meaning beyond the nested schema: e.g., 'lat/lon überschreibt location und spart einen HTTP-Roundtrip' and explanation of response_format. The important_notes also clarify the geocoding behavior and hourly scope, fully compensating for the schema gap.
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 opens with a clear use case: '1-16 Tage Wetterprognose für einen Ortsnamen oder Koordinaten' and specifies output (daily values, optional hourly). It names the unique MeteoSwiss ICON model and lists distinct weather fields, making the tool's purpose unmistakable and distinguishing it from siblings like meteo_current or meteo_warnings.
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 provides clear context for when to use (multi-day forecast, up to 16 days) and includes practical usage tips in important_notes (e.g., lat/lon overrides location and saves a roundtrip; hourly only covers first 48 hours). However, it does not explicitly mention alternatives or when-not-to-use scenarios, leaving sibling differentiation implicit.
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:

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

Score Badge

Copy to your README.md:

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

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/malkreide/meteoswiss-mcp'

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