mcp-server-time schema suggests invalid timezone "America/San_Francisco" that the server itself rejects
Reproduced failure: schema example contradicts runtime in mcp-server-time v1.27.2
Surface: mcp-server-time v1.27.2 via uvx mcp-server-time --local-timezone America/New_York (stdio)
The bug
The convert_time tool's inputSchema lists America/San_Francisco as a valid example timezone:
"target_timezone": {
"type": "string",
"description": "Target IANA timezone name (e.g., 'Asia/Tokyo', 'America/San_Francisco')..."
}But America/San_Francisco is not a valid IANA timezone. The correct identifier is America/Los_Angeles. When an agent follows the schema and uses the documented example, it fails:
Repro trace
→ {"jsonrpc":"2.0","id":30,"method":"tools/call","params":{"name":"convert_time","arguments":{"source_timezone":"UTC","time":"12:00","target_timezone":"America/San_Francisco"}}}
← {"result":{"content":[{"type":"text","text":"Error processing mcp-server-time query: Invalid timezone: 'No time zone found with key America/San_Francisco'"}],"isError":true}}
→ {"jsonrpc":"2.0","id":31,"method":"tools/call","params":{"name":"convert_time","arguments":{"source_timezone":"UTC","time":"12:00","target_timezone":"America/Los_Angeles"}}}
← {"result":{"content":[{"type":"text","text":"{ \"source\": { \"timezone\": \"UTC\", ... }, \"target\": { \"timezone\": \"America/Los_Angeles\", \"datetime\": \"2026-06-11T05:00:00-07:00\", ... }, \"time_difference\": \"-7.0h\" }"}],"isError":false}}Impact for agents
LLMs typically use the examples in tool descriptions as templates. When the schema itself suggests an invalid timezone, the first call fails, costing a round-trip. Agents using America/San_Francisco (a perfectly intuitive but incorrect IANA name) will hit this every time. The get_current_time tool has the same issue in its description.
Secondary finding: oversized input leaks server filesystem path
Passing a 2KB-long timezone string triggers an [Errno 63] File name too long error that includes the full server-side path: /Users/.../.cache/uv/archive-v0/.../lib/python3.11/site-packages/tzdata/zoneinfo/AAAA.... This leaks the Python version, uvx cache structure, and potentially the username.
What IS robust
All other edge cases — wrong types, missing required fields, invalid time formats (25:00, 12:60, "abc", ""), null values, Unicode, extra unknown params, identity conversions, midnight/end-of-day boundaries — are handled cleanly with proper isError: true responses and helpful messages. The server is well-built; this is specifically a schema documentation issue.