The time tools themselves are the ordinary pair, done properly: IANA zones, optional arguments with sensible defaults, and both the source and target zone echoed in the answer. What sets it apart is the HTTP mode — an origin allowlist that starts empty, wildcard subdomains supported, and `*` rejected outright once auth is on.
A small Go MCP server for time. It answers what time it is in a given timezone and converts a time from one zone to another, using the IANA time zone database, so the model reads a clock instead of guessing.
- The current time in a named timezone, or the system timezone when none is given — `get_current_time`
- A time converted between two zones, with an optional `time` in 24-hour `HH:MM` form and a defaulted source zone — `convert_time`
- Any IANA zone as an argument: `Europe/Warsaw`, `America/New_York`, `Asia/Tokyo`, `Australia/Sydney`, `Africa/Cairo`
- An HTTP transport alongside stdio — `go run . --transport=http` — with `GET /health`, `GET /capabilities`, and MCP at `TIME_HTTP_PATH` (default `/mcp`)
A Go toolchain: build with `go build -o ./bin/mcp-time .` and point the client at the binary. Nothing to authorize on the default stdio path. HTTP mode adds its own settings: `TIME_HTTP_ADDRESS` (default `:8080`), CORS off unless `TIME_HTTP_CORS_ENABLED` is set with an explicit `TIME_HTTP_CORS_ORIGINS` allowlist, and `TIME_AUTH_ENABLED` with a `TIME_AUTH_SECRET_KEY` of at least 32 characters when you want JWT on the endpoint.