Loading ToolBench
Multi-platform work activity synchronization with Harvest time tracking, Linear issue integration, and Slack standup automation
The server exposes 3 tools with clear verb-based naming (add_time_entry, list_recent_entries, get_today_total). Tool descriptions are present but lack depth, they do not explain WHEN to use each tool, what prerequisites exist, or what the response structure contains. Input schemas are visible and properly typed, but descriptions for parameters are inconsistent in quality. The 'add_time_entry' tool accepts natural language input, which is user-friendly, but the schema lacks explicit guidance on acceptable date formats and edge cases. Error handling is absent from the visible code, no guidance for LLMs on what to do if a project lookup fails or the API returns 401/403. Output schemas are not documented in the code. The server lacks pagination support despite potentially returning lists of time entries. Overall, the tools are functional but fall short of production-grade quality for agent orchestration.
Add a time entry to Harvest. Supports natural language like "meet with Austin for 30m" or "2h development on API"
Get total hours logged today
List recent time entries from Harvest
Tool descriptions lack context and depth. 'List recent time entries from Harvest' (19 chars) is below the 34-char baseline minimum for discovery. Descriptions do not explain when to use each tool, what data structure is returned, or what prerequisites exist (e.g., Harvest API credentials must be configured).
Output schemas are not documented in the source code. LLMs have no way to know what fields list_recent_entries returns (e.g., does it return [id, date, hours, notes, project, task]? Is there pagination metadata?). This forces LLMs to guess and risks mis-parsing responses.
No error handling or recovery guidance. If Harvest API returns 401 (invalid token), 404 (project not found), or 429 (rate limit), the LLM receives a raw error with no actionable next step. Error responses should guide the LLM: e.g., 'Project not found. Try calling list_projects() first to see available projects.' or 'Invalid date format. Use YYYY-MM-DD or relative dates: today, yesterday.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
list_recent_entries accepts a 'days' parameter but has no pagination support (no limit, offset, or cursor). If an agent calls this tool across many days, it could return hundreds of entries, bloating the context window and degrading reasoning quality. Add limit/offset parameters and document result count constraints.
add_time_entry merges multiple concerns: parsing natural language, inferring project/task from description, and creating a time entry. While the implementation is clever, the tool's result should explicitly confirm what was inferred (project_id, task_id, parsed_hours, final_date). LLMs need to verify the interpretation was correct before assuming the entry was logged correctly.
Parameter descriptions are sparse or missing. 'description' in add_time_entry is well-described ('Natural language description...'), but 'project' and 'date' lack detail. For 'date', the description should explicitly list accepted formats: 'YYYY-MM-DD, or relative dates: today, yesterday, tomorrow.' Without this, LLMs may pass invalid formats (e.g., 'Jan 15' or '01/15/2024') that the parser handles gracefully but don't match the intent.
The 'project' parameter in add_time_entry is optional and documented as 'optional, will be inferred from description.' This dependency is unclear, if the description is 'Fixed bug in API project', does the tool infer 'API project', or do both exist and cause ambiguity? The LLM needs explicit guidance: 'If omitted, the tool infers the project from keywords in the description. If inference fails, provide the project name explicitly.'