Add schema constraints to time server strings

[bmtriet]

Summary

• add maxLength/pattern schema hints for time server timezone inputs
• add a bounded 24-hour time pattern for convert_time
• cover the advertised input schemas and representative pattern examples in tests

Context

This is a small defensive follow-up for #3537. It only adds schema-level constraints for clients that validate tool schemas; existing runtime validation through ZoneInfo/time parsing remains the final check.

Tests

• cd src/time && uv run pyright
• cd src/time && uv run ruff check src/mcp_server_time/server.py test/time_server_test.py
• cd src/time && uv run pytest

[Ben-Home]

Great addition. Schema constraints like these are exactly what the ecosystem needs more of.

We ran into this problem on the operator side: most MCP servers lack input validation at the schema level, which means agents pass invalid data before the tool even runs. That burns tokens on dead-end round-trips that could have been caught with pattern/max_length hints.

For anyone else building MCP servers for business use, here is what we learned from deploying 21 connectors:

1. Schema annotations are free token savings — adding maxLength/pattern constraints means the client LLM self-corrects before the tool call instead of after a failed attempt. We saw roughly 30-40% fewer retry loops after adding proper schemas.

2. Tool count directly impacts per-session overhead — StackOne measured 105K tokens loading definitions for comprehensive servers. Curating to ~20 relevant tools drops that to ~500 tokens. The difference compounds fast when you run hundreds of sessions daily.

3. Error messages become your second API — operators read tool errors directly. Clear INVALID_PARAMS with actionable suggestions reduces the need for the agent to ask follow-up questions, which means fewer turns and lower cost.

This PR is the right direction.