New MCP Server: OpenWeatherMap

[JoeCardoso13]

Service

• API docs: https://openweathermap.org/api/one-call-3?collection=one_call_api_3.0
• Auth: API key
• Free tier: Yes (1,000 calls/day on One Call 3.0)

Suggested Tools

• get_forecast — Multi-day forecast (up to 8 days) for a given location, with a one-sentence summary
• get_historical_weather — Weather data for a specific past date and location
• compare_weather — Compare current/forecast weather across multiple cities

Suggested Skills

1. weather-briefing — Pull forecasts for one or more locations, highlight notable conditions, and deliver a natural-language summary

Notes

• One Call API 3.0 covers current, forecast, and historical data in a single endpoint family
• Locations can be specified by city name (with geocoding) or lat/lon coordinates

[JoeCardoso13]

Build Report: OpenWeatherMap MCP Server

Repo: JoeCardoso13/mcp-openweathermap
Release: v0.1.0
Tools: geocode, get_forecast, get_historical_weather, compare_weather
Tests: 30/30 passing
Bundles: linux-amd64, linux-arm64, darwin-arm64 — all built and uploaded

---

Automation Issues Found

1. gh repo create --template --clone consistently fails

When creating a repo from template with the --clone flag:

gh repo create <owner>/mcp-<name> \
  --template NimbleBrainInc/mcp-server-template-python --public --clone

The repo is created on GitHub successfully, but the local clone step fails with exit status 128. This happens consistently — not a one-off. The workaround is to run git clone manually afterward, but the build pipeline shouldn't require it.

Possible causes: timing issue (repo not ready for clone immediately after creation), or a WSL2-specific git credential/transport issue. Worth investigating whether --clone can be replaced with a explicit git clone in the skill instructions, or if a short delay resolves it.

2. Template SKILL.md causes test failure before Phase 6

The Python template ships with a generic SKILL.md that references list_items and get_item. The template test test_skill_resource_readable asserts these tool names exist in the skill content. After Phase 3 (implement), the tools have been replaced (e.g., geocode, get_forecast), but SKILL.md isn't updated until Phase 6.

This means Phase 4 (verify) has a guaranteed test failure if the test checks for the real tool names, or a meaningless assertion if it checks for the template tool names.

Suggestion: Either make the template SKILL.md and its test generic (don't assert specific tool names — just check the resource is non-empty and readable), or move skill content creation earlier in the pipeline so it stays in sync with tool implementation.

3. mcpb-pack announce returns HTTP 400 on 2 of 3 runners

During the build-bundle.yml run, 2 of the 3 platform runners logged:

Failed to announce artifact (HTTP 400) - continuing (announce-required=false)

This is expected behavior — the first runner to announce creates the version, and subsequent runners get a 400 because it already exists. The bundles are still uploaded to the GitHub Release regardless. However, the warning is confusing and could lead contributors to think something went wrong.

Suggestion: Either suppress the warning when the 400 is specifically a "version already exists" response, or change the log level to info with a clearer message like "Version already announced by another runner — artifact uploaded successfully."

[JoeCardoso13]

NimbleBrainInc/mpak#39