TickTick MCP Server - Enhanced Version with Chinese Support. Provides task and project management capabilities for TickTick through the Model Context Protocol.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server has 17 tools with reasonable naming (all verb-prefixed) and basic schemas. However, several critical gaps reduce quality significantly: (1) parameter descriptions are sparse or missing for optional fields, (2) output schemas are not documented anywhere in the provided source, (3) error handling is absent, no recovery guidance for agents, (4) most tool descriptions are under 50 characters and lack 'when to use' context, (5) no input validation hints (e.g., date format constraints, priority ranges), (6) tools lack clarity on stateful side effects. The server sits in the 'C/D' band, definitions are present but underdeveloped for LLM agent planning.
Output schemas are completely undocumented. The source code provides tool names, input schemas, and short descriptions, but there is no specification of what each tool returns. LLMs cannot plan downstream calls or extract required fields without knowing return structure.
Tool descriptions are too short and lack context. Most are 20 - 40 characters (e.g., 'Get all projects from TickTick'). They do not explain WHEN to use the tool, what makes it different from similar tools, or any prerequisites. LLMs cannot disambiguate between get_tasks and get_project_tasks without better descriptions.
Expand every tool description to 50 - 150 characters following the pattern: 'What it does. When to use it. Key output.' Example: 'Get all tasks from TickTick. Use to retrieve active tasks or filter by priority/date. Returns a list of task objects with id, title, due_date, priority, and project_id.'
Document the output schema for every tool. Include field names, types (string, integer, array, object), and meaning. Example output for get_tasks: {"tasks": [{"task_id": "string", "title": "string", "due_date": "string (ISO 8601)", "priority": "integer (0-3)", "completed": "boolean", "project_id": "string"}], "total_count": "integer"}
Add parameter validation hints to descriptions. For 'priority' integer, state '(0=low, 1=medium, 2=high, 3=urgent)'. For date strings, state 'ISO 8601 format (YYYY-MM-DD)'. For 'query' in search_tasks, state 'Free-form text; supports partial matches'.
Add pagination parameters to list tools (get_projects, get_tasks, get_project_tasks): page_number (default 1), page_size (default 20, max 100). Update descriptions to warn: 'Returns paginated results; default limit 20 items. Pass page_number and page_size to retrieve more.'
Add error response documentation to every tool. Example: 'Errors: 401 Unauthorized → Call auth_login first. 404 Not Found → Project ID invalid; call get_projects to list valid IDs. 429 Rate Limited → Retry after 60 seconds.'
Implement a dry-run parameter for destructive operations (delete_project, delete_task). Document: 'Set dry_run=true to preview what would be deleted without executing. Defaults to false.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Optional parameters lack descriptions or type hints in most tools. For example, create_task has optional 'color' (actually 'color' is not in schema but create_project has it), and update_task has many optional fields, but no validation rules (e.g., 'priority' is integer but no range stated; 'start_date' and 'due_date' are strings but no format validation shown). LLMs will pass invalid values.
No error handling or recovery guidance. If auth_login fails, get_projects fails, or a project_id is invalid, there are no documented error responses or hints for agents. No 'retryable' vs 'user-fixable' classification. Agents will have no way to self-correct.
No pagination support documented. Tools like get_projects, get_tasks, get_project_tasks return potentially large lists but have no page/offset/limit parameters shown. If an agent has 1000 tasks, returning all could blow the context window. The description also lacks a limit warning.
Destructive operations (delete_project, delete_task) do not mention confirmation or dry-run support. No indication these are irreversible. Agents could accidentally trigger a mass deletion without guard rails.
No scope/permission declarations. Tools do not specify what permissions they require (e.g., 'read:tasks', 'write:project'). This blocks least-privilege agent configuration and audit trail clarity.
all
Add scope declarations as a comment block in each tool's code. Example: '# Requires: read:tasks, write:tasks' for update_task.
Add a 'confirmation' return type for destructive tools. If an agent calls delete_task without explicit confirmation, return {"status": "pending_confirmation", "message": "This will permanently delete task 'Fix bug #123'. Call delete_task again with confirm=true to proceed."} This follows the Multi Round-Trip Requests pattern.
Create a discovery tool (e.g., describe_task_schema) that returns the structure of a task object, including field types, constraints, and valid enum values. Agents can call this once to understand what fields they can query or filter on.
Document which tools are idempotent (safe to retry). E.g., get_tasks is idempotent; create_task is not (retry creates a duplicate). Add a note: 'Idempotent: safe to retry on network failure.' vs 'Non-idempotent: retrying may create duplicates. Include task_id if retrying.'
For auth_login, add description text: 'Required before other tools work. Stores credentials for the session. If you receive a 401 Unauthorized from any tool, the session expired, call auth_login again.' This guides agents through re-authentication.
Add 'include_completed' default value to descriptions. E.g., 'get_tasks(include_completed=false) returns only active tasks. Set include_completed=true to also fetch archived/completed tasks.'