Loading ToolBench
A Model Context Protocol connector for the Godspeed Task Management API
Mixed quality across 11 tools. Naming follows verb_noun convention and is generally clear (listTasks, getTask, createTask, etc.). All tool descriptions are present and substantive (20-60 chars typically). Input schemas are fully defined with Zod validation. However, output schemas are not documented, responses are JSON.stringify'd without declared structure. Parameter descriptions are adequate but lack actionable format constraints (e.g., date formats are documented as 'format: date-time' in schema but descriptions don't reinforce). Error handling is minimal: all tools catch errors and return text responses, but do not classify errors as retryable/user-fixable/fatal or guide LLM recovery. One tool (getTaskLists) has a vestigial parameter 'random_string' that is required in schema but ignored in implementation, a clear design flaw. Overall, the server is functional but lacks production-grade polish around error guidance, response documentation, and schema clarity.
Create multiple tasks in bulk (up to 60 tasks)
Mark a task as complete
Create a new task
Create a new task list by duplicating an empty template list
Delete a task by ID
Duplicate a list and all its tasks
Get a task by ID
No output schemas documented. All tools return JSON.stringify'd results without declaring the structure of returned objects (field names, types, nested properties). LLMs cannot reliably extract or chain on results without documented schemas.
getTaskLists tool has a required parameter 'random_string' (z.string()) that is defined in the schema but completely ignored in the handler, the function takes no params and calls godspeedApi.getTaskLists(). This is a logic error that will confuse LLMs and waste token budget on a useless parameter.
Error handling is generic and non-actionable. All tools catch errors and return 'Error: <message>' as plain text. No error categorization (retryable vs. user-fixable vs. fatal). LLMs receive no guidance on what to do next after a failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get all task lists
List tasks with optional filters
Mark a task as incomplete
Update an existing task
Destructive operations (deleteTask, updateTask with is_complete=true, duplicateList) lack any confirmation or dry-run mechanism. Agents can permanently delete or modify user data without safeguards.
Date/time parameter descriptions do not enforce ISO 8601 format or explain edge cases (e.g., how timeless_due_at differs from due_at, ambiguous timezone handling). Format constraints exist in schema (z.date()) but descriptions lack actionable guidance for LLMs.
Tool descriptions are adequate but brief. They state WHAT but not WHEN to use (e.g., when to choose createTask vs. bulkCreateTask, or listTasks vs. getTask). Missing dependency hints ('Call getTaskLists first to see available list_ids').