Loading ToolBench
MCP server providing time intelligence, persistent memory and complete traceability for AI coding agents
The Chronos Protocol server provides 9 tools with reasonable schema coverage and descriptions, but exhibits several quality gaps that prevent it from reaching a higher tier. Tool names follow verb-noun conventions appropriately (get_*, create_*, update_*, end_*, check_*). All parameters have type declarations and descriptions, which is a strength. However, output schemas are not explicitly documented in the visible source, the server definition shows only input schemas. Error handling descriptions are absent, forcing LLMs to guess what happens on failure. Parameter constraints (enums, min/max, format strings) are minimal. The tool set itself is well-scoped (time utilities + activity logging + reminders), but lacks the rich context and recovery guidance needed for production-grade agent interactions.
Check for reminders that are due within the specified number of minutes
Convert time from one timezone to another at a specified time
Create a time-based reminder for a future time with a message and optional related task ID
End an activity log entry and record the completion status
Retrieve activity logs with optional filtering by type, scope, date range, and limit
Get the current time in a specified timezone
Get the elapsed time for an ongoing or completed activity
Start a new activity log entry with activity type, task scope, and optional description
Output schemas not documented in visible source code. LLMs cannot plan downstream operations or extract required fields without knowing what each tool returns.
Descriptions are minimal (58-70 chars average). Current descriptions lack context for tool selection and usage constraints.
No error handling guidance in tool descriptions. Tools like end_activity_log and update_activity_log lack recovery hints (e.g., 'If activity_id not found, call get_activity_logs() to retrieve valid IDs'). Agents cannot self-correct on failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Update an existing activity log with new values for description, result, notes, or other fields
Parameter constraints missing for timezone and time parameters. No enum declarations for valid timezone values, no format specifications for time strings (HH:MM vs ISO 8601), no min/max for 'minutes_ahead' in check_time_reminders.
get_activity_logs 'filters' parameter is typed as 'object' with vague description 'Filter criteria including activityType, limit, and other parameters'. LLMs cannot determine valid filter fields, types, or operators. Should use explicit named parameters (activity_type, limit, date_range) or an enum-constrained schema.
update_activity_log 'updates' parameter is typed as 'object' with no schema for allowed fields. LLMs cannot know whether to pass {result, notes, description}, {status, priority}, or unstructured mutations. Should enumerate allowed update fields.
No idempotency guarantees documented. If an LLM retries end_activity_log with the same activity_id, will it fail gracefully or create a duplicate completion record? Agents need idempotency hints to plan safely.
Timezone parameter in get_current_time accepts free-form string with no validation. Description says 'system', 'UTC', 'America/New_York' are examples but does not state if IANA tzdata is required, what happens on invalid input, or list available values.