Loading ToolBench
Model Context Protocol (MCP) server for TickTick task management
Server has 6 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with type definitions. However, descriptions lack actionable context for LLM selection, parameter descriptions are minimal, and output schemas are undocumented. No error handling guidance, no pagination support for list operations, and no tool annotations. The server follows verb_noun naming convention correctly but descriptions do not explain WHEN to use each tool or what the LLM should expect in responses.
Create a new task in TickTick.
Get details about a specific project.
Get all tasks in a specific project.
Get all projects from TickTick.
Get details about a specific task.
Update an existing task in TickTick.
Tool descriptions are too short (10-50 chars) and lack actionable context. 'Get all projects from TickTick' does not explain when to call this vs get_project, what structure is returned, or how to use results downstream. LLMs cannot reliably select tools without 50-200 char descriptions explaining WHAT, WHEN, and WHAT-TO-EXPECT.
Output schemas are not documented. Tools return formatted strings (e.g., format_task, format_project) but LLMs have no schema to understand what fields are present, how to extract data for downstream calls, or what to expect. Responses should declare structured output with typed fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
No pagination support. get_projects and get_project_tasks return all results as formatted strings with no limit, offset, or cursor. If a user has 500 projects, the response will be massive and blow the context window. Tools should accept limit/offset parameters and return total counts.
Error handling does not guide recovery. Code returns generic error strings like 'Error retrieving projects: {str(e)}' with no actionable next steps. LLMs cannot determine if the error is retryable, user-fixable (e.g., expired token), or fatal. Errors should categorize the issue and suggest recovery actions.
No tool annotations. Tools like create_task and update_task (WRITE operations) lack destructiveHint or idempotentHint annotations. Agents cannot determine which tools are safe to retry and which have irreversible side effects. create_task should be marked destructive; update_task should declare idempotency.