Loading ToolBench
Strong foundation with 21 well-named tools, comprehensive schemas using Zod validation, and consistent descriptions. All tools have explicit registrations with inputSchema and annotations. Tool names follow verb_noun pattern (get_, list_, create_, update_, add_, remove_). Descriptions average ~100 chars, meeting the 10-1024 char baseline. However, some parameter descriptions lack actionable constraints (e.g., 'recurrence rule' without format guidance), and output schemas are not formally documented in the tool definitions. Error handling returns structured ApiError details but lacks recovery guidance. No batch operations despite agents calling add_label/remove_label in loops.
Add a comment to a task or project.
Add a label to a task.
Mark a task as complete.
Create a label.
Create a project. Omit parentId for a top-level project.
Create a reminder for a task.
Create a section in a project. afterId null places it first.
Output schemas not formally documented. Tool descriptions state what is returned (e.g., 'Found N projects') but do not specify the structure of the response object. LLMs cannot plan downstream tool calls without knowing available fields.
Parameter descriptions lack actionable constraints. 'recurrence rule' (create_task, update_task) does not specify format (RFC 5545 RRULE?). 'remindAt' (create_reminder) says 'ISO 8601 datetime' but does not clarify timezone handling or whether past dates are rejected.
Error responses lack recovery guidance. ApiError returns {message, httpStatus, details} but does not tell the LLM what to do next. E.g., 'Project not found' should suggest 'Call list_projects() to see available projects.'
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2025-06-18+ | v2 |
Create a structured task. dueTime and recurrence require dueDate; recurrenceEndDate requires recurrence and cannot precede dueDate. Reuse idempotencyKey when retrying the same creation.
Get one project and its sections.
Get one task with labels and, when authorized, comments and reminders.
Get the authenticated user, timezone, local date, Inbox, server time and granted scopes.
List all accessible labels.
List all accessible active projects, including Inbox and shared projects.
List accessible tasks with cursor pagination and optional filters. dueBefore and dueAfter are inclusive YYYY-MM-DD dates.
Move or reorder a task. afterId null places it first. A subtask inherits its parent's section.
Parse and create a task from text using #project, @label, p1-p4, dates, times, deadlines in braces, durations and recurrence.
Remove a label from a task.
Mark a task as incomplete.
Rename, recolor, favorite, archive or reparent a project. Inbox cannot be renamed or archived.
Rename or archive a section. Supply exactly the fields to change.
Update task fields. Use move_task for ordering or reparenting and complete_task/reopen_task for status.
No batch operations for label management. Agents calling add_label/remove_label in a loop waste tokens and latency. A single add_labels(taskId, labelIds[]) would be more efficient.
quick_add_task description is vague about parsing directives. States 'Parse and create a task from text using #project, @label, p1-p4, dates, times, deadlines in braces, durations and recurrence' but does not explain syntax (e.g., is it '#project-name' or '#project_id'? What does 'deadlines in braces' mean exactly?).