Loading ToolBench
This MCP server exposes two timezone utility tools with clear naming and well-structured JSON schemas. However, critical gaps in output documentation, parameter validation guidance, and error recovery information prevent a higher score. Both tools have proper input schemas with descriptions, but lack documented output schemas and error handling patterns. The descriptions are functional but brevity leaves room for better LLM guidance on when/how to use each tool. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear readonly semantics.
タイムゾーン間で時刻を変換
特定のタイムゾーンでの現在時刻を取得
Output schema not documented. Both tools return JSON via text wrapper, but LLM cannot see what fields are present (timezone_offset? iso_string? human_readable_time?). This forces the LLM to guess at result structure.
Tool descriptions are too brief (28 and 18 chars respectively). These descriptions lack context on WHEN to use each tool, WHY they differ, and WHAT information is returned. For example, 'get_current_time' should clarify whether it includes offset, DST rules, or just a formatted time string.
Parameter descriptions include example timezone values ('America/New_York', 'Europe/London'). Proper IANA timezone validation should be enforced server-side with error messages like 'Invalid timezone: got "America/New_York_123", must be a valid IANA zone (e.g. America/New_York, Europe/London, Asia/Tokyo)'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 48 | 2026-07-28+ | v2 |
No error recovery guidance. When timezone validation fails (caught via DateInvalidTimeZoneException in constructor), the generic error 'mcp-server-timeクエリの処理中にエラーが発生しました: ...' gives the LLM no direction. Should return 'Invalid timezone: "invalid_zone_here". Valid IANA timezones: America/New_York, Europe/London, Asia/Tokyo, etc.' per pattern:recovery-guide.
Tool annotations missing. Both tools are readonly (no side effects) and idempotent (same inputs always produce same output). The source code indicates risk: READ_ONLY, but the tool definition struct has no readOnlyHint or idempotentHint fields per current MCP spec (2026-07-28). LLMs cannot infer these properties without explicit annotations.
Parameter 'time' in convert_time has no explicit format constraint. Description states '24時間形式（HH:MM）' but there is no JSON Schema pattern or enum to enforce this. If user passes '25:99' or '12/30' or '12:30 PM', the tool will likely fail with unclear error. Should add a regex pattern like '^([0-1][0-9]|2[0-3]):[0-5][0-9]$' to the schema.
No alternative parameter handling. When user says 'convert time in my local timezone', the tool description suggests the LLM should omit timezone params, but the schema marks all params as required. Per pattern:tool, smart defaults should reduce cognitive load. If 'source_timezone' can default to server's local_tz (calculated in constructor), it should be optional.