Loading ToolBench
MCP server for date and time operations, providing tools to get current date/time and convert datetime strings to Unix timestamps
Two simple tools with basic schemas and descriptions. Both tools have clear verb-noun naming (get_now, convert_to_timestamp) and non-empty descriptions. Input schemas are present with Zod validation and enum constraints. However, descriptions are minimal (under 100 chars), lack context about when to use each tool, and do not explain dependencies or error recovery. Output schemas are not documented, LLMs cannot predict response structure. Error handling returns generic isError flags without actionable guidance. No parameter descriptions explain format constraints beyond what Zod validates. Overall: functional but below production baseline.
Converts a datetime string in YYYY-MM-DD hh:mm:ss format with a timezone to a Unix timestamp.
Use this tool to get the current date and time.
Output schemas not documented. LLMs cannot predict response structure (text string vs object). Responses return {content: [{type, text}], isError} but this is never declared in tool definitions.
Error handling provides no recovery guidance. Errors return isError=true with empty text field, giving LLMs no actionable next step. Should include error reason and suggest alternatives (e.g., 'Invalid timezone. Supported: Asia/Tokyo, UTC, America/New_York, Europe/London, Australia/Sydney').
Parameter descriptions lack format constraints. 'datetime' parameter has regex validation in code but description only says 'YYYY-MM-DD hh:mm:ss format', does not state this is required, no mention of timezone dependency. 'timezone' enum is not explained in description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Tool descriptions lack context about when to use each tool. 'get_now' vs 'convert_to_timestamp', when should an LLM pick one over the other? No guidance on dependencies or typical workflows.
Timezone support is hardcoded to 5 values (Asia/Tokyo, UTC, America/New_York, Europe/London, Australia/Sydney). Tool description does not list supported timezones, forcing LLMs to guess or fail. Should document: 'Supported timezones: Asia/Tokyo, UTC, America/New_York, Europe/London, Australia/Sydney'.