Skip to main content
Glama
lorenzwalthert

Swiss Meteo MCP

by lorenzwalthert
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Server Quality Checklist

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

  • Latest release: v0.1.0

  • Disambiguation2/5

    The tools have unclear boundaries and overlapping purposes. 'add-note' and 'delete-all-notes' are related to note management, while 'get-temperature' is a weather API tool, creating a split domain. Within the note tools, there is a gap between adding and deleting all notes, but they are distinct from the weather tool, though the server name suggests a weather focus, making the note tools ambiguous in context.

    Naming Consistency3/5

    The naming shows mixed conventions. 'add-note' and 'delete-all-notes' use kebab-case with verb-object patterns, while 'get-temperature' also uses kebab-case but is more descriptive. There is no consistent pattern across all tools, as the note tools imply a different domain than the weather tool, leading to readability issues.

    Tool Count2/5

    With only 3 tools, the count is too few for the apparent scope. The server name 'Swiss Meteo MCP' suggests a weather-related service, but only one tool ('get-temperature') directly supports this, while the other two are for note management, creating an incomplete and mismatched set for the domain.

    Completeness1/5

    The tool surface is severely incomplete for the stated purpose. Based on the server name, weather-related operations are expected, but only 'get-temperature' is provided, missing other essential weather data (e.g., forecasts, humidity). The note tools are unrelated and lack full CRUD coverage (e.g., no update or individual delete), leading to significant gaps that will cause agent failures.

  • Average 2.6/5 across 3 of 3 tools scored. Lowest: 1.7/5.

    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

  • Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.

    If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.

    MCP servers without a LICENSE cannot be installed.

  • 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

  • Behavior1/5

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

    No annotations are provided, so the description carries full burden for behavioral disclosure. 'Add a new note' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions needed, whether the operation is idempotent, what happens on failure, rate limits, or what the tool returns. This is inadequate for a mutation tool with zero annotation coverage.

    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 maximally concise with just three words. While this represents under-specification rather than ideal conciseness, from a pure structural perspective, every word earns its place and there's zero waste or redundancy.

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

    Completeness1/5

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

    The description is completely inadequate given the context. This is a mutation tool (implied by 'add') with no annotations, no output schema, and 2 undocumented required parameters. The description fails to provide necessary information about what the tool does, how to use it properly, what it returns, or how it relates to sibling tools.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, meaning neither parameter ('name' and 'content') has any documentation in the schema. The description provides no information about these parameters - it doesn't mention them at all, explain what they represent, their formats, constraints, or examples. For a tool with 2 required parameters, this leaves critical information undocumented.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose2/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description 'Add a new note' is a tautology that restates the tool name 'add-note' without adding meaningful specificity. It mentions the verb 'add' and resource 'note', but doesn't distinguish what type of note, where it's added, or how it differs from sibling tools like 'delete-all-notes' or 'get-temperature'.

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

    Usage Guidelines1/5

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

    No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or when not to use it. With sibling tools like 'delete-all-notes' that perform destructive operations, this lack of guidance could lead to incorrect tool selection.

    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 states the tool uses 'SwissMeteo APIs' but doesn't disclose behavioral traits like rate limits, authentication needs, response format, or error handling. This is a significant gap for a tool with no annotation coverage.

    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 with zero waste. Every word earns its place, making it appropriately sized and well-structured.

    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 return values, error cases, or API-specific behaviors, which are crucial for a tool with external dependencies like SwissMeteo APIs.

    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 input schema already documents the 'location' parameter. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, meeting the baseline for high schema coverage.

    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 ('current temperature for a location'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools (add-note, delete-all-notes), which are unrelated weather tools, so it doesn't need sibling differentiation but could mention it's a weather-specific tool.

    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 mentions 'SwissMeteo APIs' but doesn't specify scenarios, prerequisites, or exclusions, leaving usage context 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 for behavioral disclosure. While 'Delete all notes' clearly indicates a destructive operation, it lacks crucial details like whether this action is reversible, requires specific permissions, affects other data, or has rate limits. The description doesn't provide adequate behavioral context for a destructive operation.

    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 functionality without any wasted words. It's appropriately sized for a zero-parameter destructive operation and is 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 destructive tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical behavioral aspects like confirmation requirements, error conditions, or what happens after deletion. The description should provide more context given the tool's potentially significant impact.

    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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this tool configuration.

    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 ('Delete') and target resource ('all notes from the server'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'add-note' or 'get-temperature', 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 alternatives, prerequisites, or exclusions. It simply states what the tool does without context about appropriate usage scenarios.

    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

swiss_meteo_mcp MCP server

Copy to your README.md:

Score Badge

swiss_meteo_mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/lorenzwalthert/swiss_meteo_mcp'

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