Loading ToolBench
The Clockify MCP server provides 7 tools with visible input schemas and descriptions. However, the quality is inconsistent. All tools have names starting with action verbs (list, get, add) and all have descriptions present. Input schemas are defined for all tools with type information. However, descriptions lack depth and context around when to use each tool vs. alternatives. Parameter descriptions are minimal (often a single phrase like 'Clockify project ID' without format guidance). Output schemas are entirely undocumented, the source shows no return type definitions, field descriptions, or guidance on what the response contains or how to chain tools. Error handling is absent from the visible code, no recovery guidance, no actionable error messages. Several tools are near-duplicates (getTimeEntries vs getUserTimeEntries vs getUserTimeEntriesByName) without clear disambiguation in descriptions. The addTimeEntry tool accepts unvalidated ISO8601 date strings with no validation logic shown. No pagination is visible on list tools despite the likelihood of large result sets in time tracking. Credentials are handled via environment variable (good), but parameter validation is not visible.
Add a time entry to a project.
Get a summary report of hours by user/project for a date range. Optional: userIds, projectIds.
List time entries for the authenticated user. Optional: start, end (ISO8601).
List time entries for a specified user. Optional: start, end (ISO8601).
List time entries for a user by name (case-insensitive, partial match allowed). Optional: start, end (ISO8601).
List all projects for the authenticated user.
No documented output schemas or return types for any tool. LLMs cannot plan downstream calls or extract the correct fields. All 7 tools lack return type documentation.
Three tools query user time entries (getTimeEntries, getUserTimeEntries, getUserTimeEntriesByName) without clear disambiguation in descriptions. LLMs cannot distinguish when to use each variant.
Parameter descriptions are minimal (5-20 chars). E.g., 'Clockify project ID' lacks format, range, or example. Descriptions should explain WHAT the parameter controls and WHY the LLM needs to provide it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
List all users in the workspace.
No pagination, limit, or offset parameters on list tools (listProjects, listUsers). Large result sets will exhaust context windows. Pagination is critical for production tools.
No error handling or recovery guidance visible. If Clockify API returns 401 (invalid key), 404 (not found), or 429 (rate limited), the error handling code is not shown, and no actionable guidance is provided to the LLM.
Tool descriptions do not explain when to use each tool or what business problem it solves. E.g., 'List all projects for the authenticated user', why would an LLM call this? What happens next?
addTimeEntry accepts ISO8601 date strings (start, end) with no validation shown. LLMs may pass invalid formats (e.g., '2024-01-15' instead of '2024-01-15T09:30:00Z'), causing silent failures.
getSummaryReport and getTimeEntries accept optional start/end parameters without making it clear whether they are required, what format they must follow, or what the default is if omitted.