Skip to main content
Glama
lorenzwalthert

Swiss Meteo MCP

by lorenzwalthert
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

swiss_meteo_mcp

This is an experimental project to learn about MCP + GitHub Copilot, using the latter to create the MCP server code and then access it through the Chat funciton of copilot. I also managed to use the MCP server through Amazon Q chat (see further below).

Journey

  • I prompted the goal as stated above for an initial pass.

  • After uvicorn was used wrongly in the .vscode/mcp.json config, which is for http endpoints, not for stdio ones, debugging back and forth with copilot fixed the issue and I had a running MCP server scaffolded (that were unrelated to swiss meteo):

  • Availabilities:

    • prompt to summarise text, which could either be detailed or brief (/mcp.swiss-meteo-mcp.summarize-notes ).

    • tool to add a note (#add-note).

    • resource to list notes, not accessible explicitly (just implicitly) through copilot chat.

  • One can see below that it works as expected, with autocompletion, after the server was started:

alt text

alt text

  • I wanted to add a tool to get the current weather from swiss meteo (hence the name of the package), but there is no official API I found out with copilot chat.

  • I then asked for a few alternatives and decided to go with wttr.io and let copilot implement it.

  • I also factored out some functionality so I could let copilot write a simple unit test that worked.

  • So my own new tool is #get-temperature

Lessons Learned

Related MCP server: MCP Travel Weather Server

in general

  • Building an MPC server seems a standard task. GitHub Copilot managed kind of well, but not flawless.

  • Integration of mcp servers is working well with copilot it seems.

  • Invocation of tools and resources is possible implicitly or explicitly. When used, it is communicated transparently in the copilot chat.

  • MCP servers can run locally (with like uv run or container isolation) or remotely.

  • MCP prompts are really just parametrised snippets.

  • resources are read-only info.

  • tools are supposed to have side effects.

GitHub Copilot

  • can also write git commit messages (not so impressive)

  • used 20% of free code suggestions in one day (and might be used for retraining).

Amazon Q

  • Can discover MCP server in .vscode/mcp.json in own project, start it when a relevant question is asked in the Q chat and use the tool to answer the question, but using Python source package not MCP tool over stdio.

  • to use the mcp server outside the source repo, we had to put the mcp.json file into the amazon q global directory at ~/.aws/amazonq/mcp/mcp.json and rename the servers: key to mcpServers: for Q to recognise it:

{
  "mcpServers": {
    "swiss-meteo-mcp3": {
      "type": "stdio",
      # not portable, most mcp servers use uvx run [pypiname.module@latest] to install on fly and run
      "command": "/Users/lorenz/git/swiss_meteo_mcp/.venv/bin/python", 
      "args": [
        "-m",
        "swiss_meteo_mcp.server"
      ]
    }
  }
}

alt text

Other

  • drag and drop screenshot into VS Code editor works well

Available Tools

3 tools
add-noteC

Add a new note

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
contentYes

TDQS

C2.8/5.0
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 says 'Add a new note' and provides no details on side effects, permissions, return values, or error behavior.

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 a single short sentence with no wasted words, making it concise and front-loaded. However, it is under-specified for the tool's complexity, though this is largely a completeness issue rather than a conciseness issue.

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, output schema, and parameter descriptions, a five-word description is insufficient for an agent to invoke the tool correctly. The meaning of the parameters and expected return behavior remain ambiguous.

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?

The input schema has zero description coverage for the two required parameters ('name' and 'content'), and the description does not explain their meaning or format. The agent cannot infer what 'name' or 'content' represent.

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 ('Add') and a specific resource ('note'), clearly stating the tool's function. It differentiates itself from the sibling 'get_report', which is a read operation.

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. The description only states the action without any context about when to invoke it or when to choose a sibling tool.

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

delete-all-notesB

Delete all notes from the server.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
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.

get-temperatureC

Get the current temperature for a location using SwissMeteo APIs.

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesThe location to query (e.g., city name or coordinates)

TDQS

C2.9/5.0
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedadd-note
    • First observeddelete-all-notes
    • First observedget-temperature
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.1/5.0

Scored across 3 tools

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.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers