Loading ToolBench
The server has 5 tools with complete input schemas and basic descriptions, but significant gaps in parameter documentation, output schema formalization, and error guidance. Naming follows verb_noun convention (tf_status, tf_today, tf_report, tf_sessions, tf_send), which is good. However, descriptions lack depth and strategic context. Parameter descriptions are present but minimal. Output schemas are inferred from code but not formally documented. Error handling returns error text but lacks recovery guidance or error classification. The codebase shows reasonable structure with fetch wrapper and Zod validation, but the MCP integration lacks optional features.
Get coding time summary for a date range
Send a manual event/heartbeat to TimeForged
List coding sessions
Check TimeForged daemon status
Get today's coding time summary
Output schemas not formally documented. Code infers response structures (e.g., tf_status returns {status, version, user_count, event_count} and tf_report returns {total_seconds, from, to, projects[], languages[], days[]}), but no explicit schema definition is provided for LLMs to understand expected response fields. LLMs cannot plan downstream tool calls or reliably extract needed data.
Tool descriptions are generic and lack strategic context. 'Check TimeForged daemon status' and 'Get today's coding time summary' tell WHAT but not WHEN to use or dependencies. No hint on when tf_report should be called instead of tf_today, or when to use tf_sessions for deeper analysis. Descriptions should answer: what does it do? When instead of a similar tool? What does it return? (Pattern: tool-description, baseline 194 chars avg, current ~30-50 chars).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Parameter descriptions in tf_report and tf_sessions lack precision. 'Start datetime (ISO 8601)' is adequate but does not specify: required format, whether null defaults to 7 days ago for tf_report, validation constraints, or examples of valid values. Descriptions should include format, range, and allowed values inline.
Error handling is minimal and does not guide recovery. All tools catch errors and return `{content: [{type: 'text', text: 'Error: ' + message}], isError: true}`. Error responses do not classify as retryable/user-fixable/fatal, suggest alternative tools, or provide actionable next steps. Example: 'Failed to reach TimeForged daemon at http://127.0.0.1:6175. Verify TF_SERVER_URL is correct and daemon is running.' guides recovery; current 'Error: HTTP 500: ...' does not.
tf_send description does not clarify that it modifies state. 'Send a manual event/heartbeat to TimeForged' hints at side effects, but does not explicitly state 'This creates a new event record' or 'not idempotent, calling twice logs two events.' Agents need to know which calls are safe to retry.
No pagination or result limits documented. tf_report and tf_sessions may return large result sets (projects[], languages[], days[], sessions[]). Code does not cap results or implement pagination. If a user has months of data, returning thousands of sessions or days could exhaust context window. Descriptions should state 'Returns up to 100 days' or similar.
Parameter descriptions lack examples of valid input. tf_report 'from' says 'Start datetime (ISO 8601)' but does not show format: is '2024-01-15' valid? '2024-01-15T00:00:00Z'? What if user says 'last week'? Guidelines recommend stating format precisely: 'ISO 8601 format, e.g., 2024-01-15T09:30:00Z'.