Normalize the five weather servers #268

Problem

The five servers agree on tool names (except TypeScript), output schemas and structured content. But they differ in text output, input validation, error text and metadata, and some have real bugs. Python differs the most from the others, and it's the one most people read first.

Tasks

Python (weather-server-python/weather.py)

• Return hand-formatted text alongside the model, as the other four do. Today the SDK serializes the model to JSON, so "no alerts" reaches the LLM as the literal string [].
• Use MCPServer("weather", version="1.0.0") (the version is "" today). Also turn off the prompts and resources capabilities the SDK advertises by default.
• Describe parameters with Annotated[str, Field(description=...)]. The docstring's Args: block isn't sent to clients.
• Guard points_data["properties"]["forecast"] (around line 114). It raises KeyError for grid points that have no forecast URL.
• Move the "Revision 2026-07-28" explanation out of the Alerts docstring. Right now it's published as the description of the output schema.

TypeScript (weather-server-typescript/src/index.ts)

• Rename get-alerts / get-forecast to get_alerts / get_forecast. Update the server README, and the line in the root README that documents the difference. Also update tests/helpers/mcp-test-client.ts if it checks the names.
• Make the temperature schema integer instead of number | null. NWS sends integers, and the other four servers say integer.
• Add the Forecast: label and the \n---\n separator the other servers use.

All five

• Use the same input constraints as TypeScript: state exactly 2 characters, latitude -90..90, longitude -180..180. Use the description "Two-letter US state code (e.g. CA, NY)" everywhere.

• Use one set of error messages:

  • Unable to fetch alerts for {STATE}.
  • Unable to fetch forecast data for this location.
  • Unable to fetch detailed forecast.
  • No forecast periods available.

  Don't append raw HTTP bodies or exception text, as Go and Ruby do today.

• Round coordinates to 4 decimal places before building the points URL, as TypeScript already does. NWS returns a 301 redirect for longer values, and the Python and Ruby HTTP clients don't follow redirects.

• Add a 30-second HTTP timeout in TypeScript, Go and Rust. Python and Ruby already have one.

• Use "No active alerts for {STATE}." with the state code in every server.

• Add a title to both tools in Python, Go, Rust and Ruby, using TypeScript's wording ("Get Weather Alerts", "Get Weather Forecast"). Hosts show the title in tool pickers, and every SDK supports it. Today mcpscore reports "tools without a display title" for those four servers.

Rust (weather-server-rust/src/main.rs, Cargo.toml)

• Change latitude and longitude from f32 to f64. Structured content currently echoes values like 38.581600189208984.
• Add the check for an empty periods list (around lines 258-272).
• Reuse one reqwest::Client. make_nws_request still builds a new one on every call (main.rs:110).
• Move the "revision 2026-07-28 is the first to allow" explanation out of the Alert doc comment. As in Python, it's published to clients, here as the $defs.Alert description in the output schema.

Go (weather-server-go/main.go)

• Text blocks start with a blank line because of the raw strings around lines 128 and 138; remove it. In formatPeriod, format the published Period instead of the raw NWS struct, to match formatAlert.

Acceptance criteria

• tools/list returns the same names, titles, descriptions and input constraints from all five servers.
• The same call returns the same text (ignoring whitespace) and the same structured content from all five servers.
• Error cases return the same message text from all five servers.