Loading ToolBench
A time-tracking app built with Next.js and the Model Context Protocol (MCP)
TimeTracker MCP presents a moderately well-structured tool set with clear naming conventions and reasonable schema definitions. All 16 tools follow verb_noun naming patterns (create_, list_, update_, deactivate_, start_, stop_, get_, add_). Descriptions are present for all tools and most parameters, though many are terse. Input schemas are visible and use Zod validation with type constraints. However, output schemas are not documented, parameter descriptions vary significantly in clarity and completeness, and error handling lacks actionable recovery guidance. The tool set shows good composition (separate tools for distinct operations), but lacks depth in parameter validation documentation and post-execution guidance.
Add a manual time entry for completed work
Calculate potential earnings based on time worked and hourly rates
Create a new client
Create a new project for a client
Deactivate a client (soft delete)
Deactivate a project (soft delete)
Get the currently active time entry if any
Output schemas not documented. No tool describes what fields are returned, their types, or how to chain results to downstream tools. list_clients returns unstructured text responses instead of structured JSON. This forces LLMs to parse text and makes composition error-prone.
Error handling returns unstructured text with no recovery guidance. Errors like 'Client not found' lack suggestions for next steps (e.g., 'Try search_clients() to find available clients'). No categorization of retryable vs. fatal errors. LLMs cannot determine appropriate recovery action.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 65 | - | v1 |
Get a summary of time worked grouped by client and project for a date range
List all clients (shared across all users)
List all projects (shared across all users), optionally filtered by client
List time entries with optional filtering by project and date range
Start tracking time for a project
Stop the currently active time tracking
Update an existing client
Update an existing project
Update an existing time entry
Parameter descriptions lack format/constraint details. For example, 'startDate' and 'endDate' specify 'ISO datetime format' but provide no examples or validation rules. 'hourlyRate' accepts 'positive number' with no min/max bounds. LLMs frequently hallucinate invalid values (negative rates, malformed dates) because constraints are underspecified.
Destructive operations (deactivate_client, deactivate_project) lack confirmation or dry-run support. An agent could accidentally deactivate all clients in one call. No idempotency guarantees documented. If an LLM retries on ambiguous failure, duplicate deactivations or state corruption could occur.
No pagination limits or guidance. list_clients, list_projects, list_time_entries lack explicit max_results or per_page parameters. If thousands of records exist, responses could exhaust token budgets. list_time_entries specifies 'limit defaults to 20, max 100' but list_clients and list_projects offer no such limits.
Tool composition assumes userId is injected by the runtime, but this parameter is not visible in tool definitions. If the MCP server is stateless (per current spec), each tool must either accept userId as a parameter or document how it is resolved. Unclear resolution mechanism risks tool selection errors or permission bypass.
Descriptions are frequently generic and short (under 100 chars). E.g., 'Get the currently active time entry if any' (43 chars) lacks context on WHEN to call this tool or WHAT the result enables. When should LLM call it? What happens next?