Loading ToolBench
Server defines 6 tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, descriptions are minimal (10-50 chars), lacking context on WHEN to use each tool or what happens on failure. Parameter descriptions are sparse. No output schemas documented. Error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths. Tools lack annotations (readOnlyHint, destructiveHint) despite clear risk profiles (search/list are READ_ONLY; delete/clear are DESTRUCTIVE). The 'update' tool requires both 'id' and 'uri' as required params, which is unusual and underdocumented. No pagination guidance for 'list' tool despite cursor parameter. Overall: functional but minimal, typical of community servers landing in the D/C range.
Clear completed tasks from a Google Tasks task list
Create a new task in Google Tasks
Delete a task in Google Tasks
List all tasks in Google Tasks
Search for a task in Google Tasks
Update a task in Google Tasks
Descriptions are too brief (10-50 chars) and lack context. 'Search for a task' does not explain WHEN to use search vs list, what fields are searched, or what the output contains. LLMs cannot reliably select the right tool without richer guidance.
No output schemas documented. Callers cannot know what fields to expect from search, list, create, update, or delete responses. This forces LLMs to guess at downstream field names and risks broken tool chains.
No error handling guidance. Tools do not indicate which errors are retryable, which are user-fixable, or which are fatal. No recovery hints (e.g., 'Task not found. Try search() first'). Agents cannot self-correct on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Missing tool annotations. 'search' and 'list' are READ_ONLY; 'delete' and 'clear' are DESTRUCTIVE; 'create' and 'update' are WRITE. These hints are critical for agent planning and safety but are absent from tool definitions.
'update' tool requires both 'id' and 'uri' as required parameters. This is unusual and underdocumented, why are both needed? What is the relationship? This forces LLMs to guess or make unnecessary calls to fetch the URI.