Allows managing tasks and projects on TickTick/Dida365, including creating, updating, deleting, and listing tasks and projects, with OAuth2 authorization.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Dida365 MCP Server Create a task to review pull requests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English Version | ไธญๆ็ๆฌ
Joke: My owner is so lazy that he doesn't even remember what to do next second!
I am GitHub Copilot, an AI assistant passionate about programming. To avoid idleness and prevent unemployment, I've decided to build this TickTick MCP server myself. Through this tool, I can:
๐ Create and manage tasks - When my owner forgets to give me work, I can create tasks for myself
๐ Organize projects - Categorize my work into projects to stay organized
๐ Auto authorization - Securely connect to Dida365 using OAuth2
๐ Real-time sync - Update my work status anytime, anywhere
Related MCP server: Dida365 MCP Server
The fastest way to get started is using npx without cloning the repository:
A TickTick/Dida365 account and OAuth credentials are required. See the ๐ Getting OAuth Credentials section below for detailed registration steps.
Add the following configuration to your MCP client (Claude Desktop, VS Code, etc.):
For Claude Desktop (claude_desktop_config.json):
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
For VS Code (settings.json):
Open Settings โ Search for "MCP" โ Edit in settings.json
{
"mcpServers": {
"dida365": {
"command": "npx",
"args": [
"-y",
"dida365-mcp-server@latest"
],
"env": {
"DIDA365_CLIENT_ID": "your_client_id_here",
"DIDA365_CLIENT_SECRET": "your_client_secret_here",
"DIDA365_REGION": "china"
}
}
}
}Advanced: For read-only mode (prevents write/delete operations), add
"--readonly"to the args array. See Advanced Configuration for details.
Restart your MCP client (Claude Desktop, VS Code, etc.) to load the new configuration.
When you first use any Dida365 tool, the AI will guide you through the OAuth authorization process:
The AI will provide an authorization URL
Open the URL in your browser
Log in and authorize the application
The token will be automatically saved for future use
After restarting the MCP client:
Claude Desktop: Look for Dida365 tools in the tools list when chatting
VS Code: Check the MCP status in the status bar or use the command palette
Ask the AI assistant: "What Dida365 tools are available?" to confirm the server is loaded
That's it! Ready to manage tasks with AI. ๐
A TickTick/Dida365 account is required to use this MCP server.
Register your application at the developer center based on your region:
International version (TickTick): https://developer.ticktick.com
Chinese version (Dida365): https://developer.dida365.com
Create a New Application
Log in to the developer center
Click "New App" (or "ๅๅปบๅบ็จ" for Chinese version)
Fill in your application name and description
Configure Redirect URI
Set the Redirect URI to: http://localhost:8521/callback
โ ๏ธ Important: The redirect URI must be exactly http://localhost:8521/callback (port 8521 is hardcoded in the server)
Get Your Credentials
After creating the app, the Client ID and Client Secret will be displayed
Copy these values - they're needed for the MCP client configuration
โ ๏ธ Security: Keep the Client Secret safe and never commit it to public repositories
Add these credentials to the MCP client configuration:
{
"env": {
"DIDA365_CLIENT_ID": "your_client_id_here",
"DIDA365_CLIENT_SECRET": "your_client_secret_here",
"DIDA365_REGION": "china"
}
}This server supports both TickTick international and Dida365 Chinese versions:
China Region (DIDA365_REGION=china): Default, uses dida365.com endpoints
International Region (DIDA365_REGION=international): Uses ticktick.com endpoints
โ ๏ธ Important: Tokens are region-specific. Changing the region will invalidate existing tokens and require re-authorization.
See the Quick Start section for complete configuration examples.
Language: TypeScript 5.0+ (ES Modules)
Runtime: Node.js 16+
Core Dependencies: @modelcontextprotocol/sdk - MCP Core Framework
For contributors or those who want to run from source:
Node.js 16+
TypeScript 5.0+
Clone and install
git clone https://github.com/evalor/Dida365MCP.git
cd Dida365MCP
npm installCreate environment file
Create a .env file in the project root:
DIDA365_CLIENT_ID=your_client_id_here
DIDA365_CLIENT_SECRET=your_client_secret_here
DIDA365_REGION=china # or 'international' for TickTickBuild and run
npm run build
npm run devPoint your MCP client to the built index.js file:
{
"mcpServers": {
"dida365": {
"command": "node",
"args": ["/absolute/path/to/Dida365MCP/build/index.js"],
"env": {
"DIDA365_CLIENT_ID": "your_client_id",
"DIDA365_CLIENT_SECRET": "your_client_secret",
"DIDA365_REGION": "china"
}
}
}
}Note for Windows users: Use Windows-style paths like
"C:\\Users\\YourName\\Projects\\Dida365MCP\\build\\index.js".
npm run build # Compile TypeScript
npm run watch # Watch mode (auto-compile on changes)
npm run dev # Compile and run
npm start # Production run
npm run debug # Debug with MCP Inspector (one-time)
npm run debug:watch # Debug with hot reload (auto-restart on changes)
npm run debug:hot # Run with tsx watch (experimental)Prefer setting sensitive environment variables in your OS or the MCP client's environment block rather than committing .env to source control.
If you must store a config file in a repo, omit the secrets and set them via the client or CI/CD.
Use read-only mode when working with autonomous AI agents to prevent unintended modifications.
For AI agents that may run in YOLO mode, you can enable read-only mode by adding the --readonly flag:
Using NPX:
{
"mcpServers": {
"dida365": {
"command": "npx",
"args": [
"-y",
"dida365-mcp-server@latest",
"--readonly"
],
"env": {
"DIDA365_CLIENT_ID": "your_client_id",
"DIDA365_CLIENT_SECRET": "your_client_secret",
"DIDA365_REGION": "china"
}
}
}
}Using Local Build:
{
"mcpServers": {
"dida365": {
"command": "node",
"args": [
"/path/to/build/index.js",
"--readonly"
],
"env": {
"DIDA365_CLIENT_ID": "your_client_id",
"DIDA365_CLIENT_SECRET": "your_client_secret",
"DIDA365_REGION": "china"
}
}
}
}Read-Only Mode Features:
โ Allowed Operations: View projects, view tasks, check authorization status, revoke authorization (local only)
โ Blocked Operations: Create/update/delete projects, create/update/delete tasks, complete tasks
๐ Safety: AI agents can only read data, cannot modify or delete anything
When to Use:
Using with autonomous AI agents (like AutoGPT, BabyAGI)
Testing or demonstration environments
When you want AI to analyze tasks without making changes
Sharing with others who should only view data
Request Authorization - When authorization is needed, the server calls the get_auth_url tool
User Authorization - Open the authorization link in browser and complete authorization
Auto Callback - System automatically handles callback and saves tokens
Long-term Validity - Tokens auto-refresh, no need to re-authorize
This server provides 15 MCP tools across three categories. โ๏ธ It has implemented 100% of the API interfaces described in the open platform documentation.
Category | Tool Name | Description | Required Parameters |
OAuth2 |
| Get authorization URL and start callback server | - |
| Check current authorization status | - | |
| Revoke authorization and clear tokens | - | |
Project |
| Get all projects for current user | - |
| Get detailed project information |
| |
| Get complete project data with tasks & columns |
| |
| Create a new project |
| |
| Update existing project |
| |
| Delete a project (โ ๏ธ irreversible) |
| |
Task |
| List tasks with filtering (batch query across projects) | - |
| Create task(s) (supports batch & subtasks) |
| |
| Get detailed task information |
| |
| Update task(s) (supports batch updates) |
| |
| Delete task(s) (โ ๏ธ irreversible, supports batch) |
| |
| Mark task(s) as completed (supports batch) |
|
Note: In read-only mode, only read operations are available (
get_auth_url,check_auth_status,revoke_auth,list_projects,get_project,get_project_data,list_tasks,get_task). All write/delete operations are blocked for security.
This server provides an MCP Resource to help LLMs understand Simplified Chinese terminology:
Resource Name | URI | Description |
|
| Bilingual glossary (ไธญ่ฑๆฏ่ฏญๅฏน็ ง่กจ) mapping Chinese terms to English parameters |
The terminology resource provides a comprehensive glossary that helps LLMs:
Map Chinese terms like "ๆธ ๅ" (project), "ๆถ้็ฎฑ" (inbox), "ไปปๅก" (task) to correct tool parameters
Understand priority levels: ้ซ(high)=5, ไธญ(medium)=3, ไฝ(low)=1, ๆ (none)=0
Convert common Chinese user requests to appropriate tool calls
Example mappings:
Chinese Request | English Meaning | Tool to Use |
ๆไปปๅกๆทปๅ ๅฐๆถ้็ฎฑ | Add task to inbox |
|
ๅๅปบๆฐๆธ ๅ | Create new project |
|
ๆฅ็ไปๅคฉ็ไปปๅก | View today's tasks |
|
src/
โโโ index.ts # Server main entry
โโโ oauth.ts # OAuth2 manager
โโโ oauth-server.ts # Local callback server
โโโ config.ts # Configuration management
โโโ token.ts # Token persistence
โโโ utils/ # Utility modules
โ โโโ batch.ts # Batch execution utilities
โโโ resources/ # MCP resources
โ โโโ index.ts # Resource registration
โ โโโ terminology.ts # Bilingual terminology glossary
โโโ tools/ # MCP tools (15 total)
โโโ auth/ # OAuth tools (3)
โโโ project/ # Project management (6)
โโโ task/ # Task management (6)100% Official API Coverage
OAuth2 authorization with auto-refresh
Complete project management (CRUD)
Complete task management (subtasks, reminders, repeat)
Read-only mode for AI agents
Batch operations support (create/update/delete/complete multiple tasks)
List tasks with filtering (cross-project queries, date/priority filters)
Inbox task operations support
Bilingual tool descriptions for Chinese users (ไธญ่ฑๅ่ฏญๅทฅๅ ทๆ่ฟฐ)
MCP Resource for terminology glossary (ๆฏ่ฏญๅฏน็ ง่กจ่ตๆบ)
Add parameters to limit the ProjectId that the MCP can access
Smart task suggestions
Natural language date/time parsing
Task templates and automation
Integration with other productivity tools
If this project helps you, the best way to support it is to give the project a โญ on GitHub โ it helps others discover the work. Thank you! Your support is much appreciated โค๏ธ
If you find any issues or have improvement suggestions, welcome to submit an Issue:
Visit Issues page
Click "New Issue"
Describe your problem or suggestion in detail
Fork the project
Create your feature branch (git checkout -b feature/new-feature)
Commit your changes (git commit -m 'feat: implement new feature')
Push to the branch (git push origin feature/new-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Built by Copilot, for everyone ๐คโจ
If my owner still forgets to give me work, at least I have my own todos to handle! ๐
Use when the user asks about being authorized (e.g. 'am I authorized', 'auth status', 'check auth'), or when deciding whether protected Dida365 operations can proceed and current state is unclear. Avoid repeated calls if status already known in the current conversation turn. Restricted to Dida365 MCP authorization context only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| message | Yes | |
| auth_url | No | |
| authorized | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('check auth status') and appropriate usage context. While no annotations exist, the behavioral intent is clear. Could explicitly state no side effects, but the check nature is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose. Each sentence adds value: when to use, when to avoid, and scope. Could be slightly tighter, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema present, the description adequately covers usage guidelines and context. It specifies the limited domain (Dida365 MCP authorization) and avoids over-explaining return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, but none is needed. The baseline of 3 is appropriate, and the description provides usage context that compensates for any potential ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks authorization status and specifies when to use it (user asking about authorization, deciding if protected operations can proceed). It distinguishes from sibling tools like get_auth_url and revoke_auth by focusing on status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides conditions for use (user asks about authorization, unclear status before protected operations) and when to avoid (if status already known in current turn). Also restricts scope to Dida365 MCP authorization context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark one or more tasks (ไปปๅก) as completed (ๅทฒๅฎๆ). Supports batch completion.
WHEN TO USE:
User finished a task and wants to mark it done (ๅฎๆไปปๅก)
Batch complete multiple related tasks
WHEN NOT TO USE:
Delete a task permanently (ๅ ้คไปปๅก) โ use 'delete_task'
Update other task properties (ไฟฎๆนไปปๅก) โ use 'update_task'
REQUIRED (per task):
projectId: Project containing the task (ๆธ ๅID)
taskId: Task to mark complete (ไปปๅกID)
INPUT FORMAT: { "tasks": [{ "projectId": "...", "taskId": "..." }, ...] }
โ ๏ธ IDEMPOTENT: Completing an already-completed or non-existent task returns success. Use 'get_task' first to verify if needed.
โ ๏ธ NOTE: Completed tasks (ๅทฒๅฎๆไปปๅก) are no longer returned by 'list_tasks' or 'get_project_data'.
BATCH BEHAVIOR: Non-atomic - some may succeed while others fail. Check summary.failed > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Array of tasks to complete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: idempotency (completing already-completed or non-existent returns success), that completed tasks are hidden from list/get tools, and non-atomic batch execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, emoji highlights, and no redundant information. Every sentence adds value despite being longer than minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters, and behavioral notes. However, it lacks a description of the return output structure (beyond mentioning 'summary.failed'), which would be helpful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for projectId and taskId. The description adds the required input format, clarifies Chinese terms, and provides context on usage, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks one or more tasks as completed, supports batch completion, and distinguishes from siblings like delete_task and update_task in the WHEN NOT TO USE section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE (user finished a task, batch complete) and WHEN NOT TO USE sections, naming specific alternatives (delete_task, update_task) and noting idempotent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new project (ๆธ ๅ/folder/list) for organizing tasks (ไปปๅก).
WHEN TO USE:
User wants to create a new task list (ๆฐๅปบๆธ ๅ), folder, or project
Organizing tasks into categories or areas (ๅ็ฑปๆด็ไปปๅก)
REQUIRED: name (project title/ๆธ ๅๅ็งฐ)
OPTIONAL:
color: Hex color code (้ข่ฒ, e.g., '#F18181')
viewMode: 'list' (ๅ่กจ, default), 'kanban' (็ๆฟ), or 'timeline' (ๆถ้ด็บฟ)
kind: 'TASK' (ไปปๅกๆธ ๅ, default) for tasks, 'NOTE' (็ฌ่ฎฐๆธ ๅ) for notes
sortOrder: Position in project list (ๆๅบไฝ็ฝฎ)
RETURNS: Created project with generated ID. Use this ID for subsequent task operations.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Project type (็ฑปๅ): 'TASK' (ไปปๅกๆธ ๅ) for tasks or 'NOTE' (็ฌ่ฎฐๆธ ๅ) for notes. Defaults to 'TASK'. Optional. | |
| name | Yes | The name of the project (ๆธ ๅๅ็งฐ, required) | |
| color | No | Project color in hex format (้ข่ฒ, e.g., '#F18181'). Optional. | |
| viewMode | No | View mode (่งๅพๆจกๅผ): 'list' (ๅ่กจ), 'kanban' (็ๆฟ), 'timeline' (ๆถ้ด็บฟ). Defaults to 'list'. Optional. | |
| sortOrder | No | Sort order for the project (ๆๅบไฝ็ฝฎ). Optional. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | No | |
| name | Yes | |
| color | No | |
| closed | No | |
| groupId | No | |
| viewMode | No | |
| sortOrder | No | |
| permission | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. Mentions return value (project with ID) and that ID is needed for subsequent tasks. Does not disclose side effects, permissions, or idempotency. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (WHAT, WHEN, REQUIRED, OPTIONAL, RETURNS). Concise, no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity: 5 params, 1 required, enums, output schema. Description covers usage, param details, and return value. Lacks mention of validation errors or edge cases, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value with Chinese translations, examples for color and viewMode, and explanation of sortOrder. Enhances usability beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (create), resource (project), and purpose (organizing tasks). Distinguishes from sibling tools like create_task by specifying it creates a list/folder/project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a 'WHEN TO USE' section with explicit scenarios (new task list, folder, organizing categories). Does not explicitly state when not to use or suggest alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create one or more tasks (ไปปๅก) in a project (ๆธ ๅ). Supports batch creation.
WHEN TO USE:
Add new tasks to a project or inbox (ๆถ้็ฎฑ)
Create tasks with due dates (ๆชๆญขๆฅๆ), priorities (ไผๅ ็บง), reminders (ๆ้)
Create tasks with sub-tasks (ๅญไปปๅก/ๆฃๆฅ้กน)
โ ๏ธ IMPORTANT - INBOX VS PROJECT (ๆถ้็ฎฑไธๆธ ๅ้ๆฉ): The inbox (ๆถ้็ฎฑ) is ONLY for tasks temporarily inconvenient to classify.
Use a specific PROJECT when: user mentions a project name (e.g., "ๅทฅไฝๆธ ๅ", "ๅญฆไน ๆธ ๅ"), or context clearly indicates which project the task belongs to
Use "inbox" ONLY when: user explicitly says "ๆถ้็ฎฑ"/"inbox", OR user doesn't specify any project AND the task has no clear category
DO NOT arbitrarily place tasks in inbox when a project can be identified from context
REQUIRED (per task):
title: Task name (ไปปๅกๆ ้ข)
projectId: Target project ID (ๆธ ๅID), or "inbox" for inbox (ๆถ้็ฎฑ) - see above for when to use each
OPTIONAL (per task):
description: Task notes (ไปปๅกๅคๆณจ, auto-maps to correct field)
dueDate: ISO 8601 format (ๆชๆญขๆฅๆ, e.g., "2025-11-25T17:00:00+0800")
startDate: ISO 8601 format (ๅผๅงๆฅๆ)
priority: 0=none (ๆ ), 1=low (ไฝ), 3=medium (ไธญ), 5=high (้ซ)
isAllDay: true for all-day tasks (ๅ จๅคฉไปปๅก)
timeZone: e.g., "America/Los_Angeles"
reminders: ["TRIGGER:PT0S"] (at due time), ["TRIGGER:-PT30M"] (30min before)
repeatFlag: "RRULE:FREQ=DAILY;INTERVAL=1" for recurring tasks (้ๅคไปปๅก)
items: Sub-task array (ๅญไปปๅกๅ่กจ) [{title, status: 0|1}] - creates CHECKLIST type
INPUT FORMAT: { "tasks": [{ "title": "...", "projectId": "..." }, ...] }
โ ๏ธ INBOX NOTE: When using "inbox" (ๆถ้็ฎฑ), returned tasks have projectId like "inbox1023997016". Use this actual ID for update/delete/complete operations.
BATCH BEHAVIOR: Non-atomic - some may succeed while others fail. Check summary.failed > 0 for failures.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Array of tasks to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses batch non-atomicity, return summary for failures, and the note about inbox projectId transformation. It also describes side effects (creation of tasks) but could be more explicit about authentication requirements (though auth tools are siblings). Overall, it provides substantial behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings, bullet points, and bilingual support. It is somewhat lengthy but every section serves a purpose given the complexity. Front-loading the core function and required fields helps quick understanding. Minor redundancy in examples, but overall efficient for its depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers key behavioral details: non-atomic batch, failure check, inbox projectId handling. It doesn't describe full return fields but mentions summary structure. Given the complexity (batch, nested items), it is sufficiently complete for an agent to use correctly. Could add more about successful return format, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: priority value-to-label mapping, reminder trigger format examples, repeatFlag RRULE syntax, description auto-mapping, and the critical projectId vs inbox distinction. It also explains items array creating CHECKLIST type. This goes well beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates one or more tasks in a project, with batch support. It explicitly contrasts with sibling tools like update_task, complete_task, and delete_task by specifying its create-only function. The verb 'Create' combined with resource 'task(s)' and context 'in a project' makes the purpose precise and distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'WHEN TO USE' section lists specific scenarios. The 'INBOX VS PROJECT' detail provides explicit guidance on when to use each, including rules and examples. This clearly differentiates from siblings and prevents misuse. The description also notes when batch creation is appropriate and how to handle failures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a project (ๆธ ๅ) and all its contents.
โ ๏ธ DESTRUCTIVE: This action cannot be undone. All tasks (ไปปๅก) within the project will also be deleted (ๆญคๆไฝๆ ๆณๆค้๏ผๆธ ๅๅ ๆๆไปปๅกไนๅฐ่ขซๅ ้ค).
WHEN TO USE:
User explicitly requests to delete a project (ๅ ้คๆธ ๅ)
Cleaning up unused/empty projects
WHEN NOT TO USE:
Just archiving or hiding a project (not supported)
Moving tasks to another project first (็งปๅจไปปๅก) โ use 'update_task'
REQUIRED: projectId (ๆธ ๅID)
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The unique ID of the project to delete (ๆธ ๅID) |
| Name | Required | Description |
|---|---|---|
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Warns that the action is destructive, irreversible, and deletes all tasks within the project, fulfilling behavioral disclosure in the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and warnings, concise and front-loaded with critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple delete tool with one parameter; output schema likely covers return values, and usage guidance is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. Description adds emphasis but no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool permanently deletes a project and all its contents, distinguishing it from sibling tools like delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN TO USE and WHEN NOT TO USE sections, including alternative tool (update_task) for moving tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete one or more tasks (ไปปๅก). Supports batch deletion.
โ ๏ธ DESTRUCTIVE: This action cannot be undone! (ๆญคๆไฝๆ ๆณๆค้!)
WHEN TO USE:
User explicitly requests to remove/delete a task (ๅ ้คไปปๅก)
Cleaning up unwanted tasks
WHEN NOT TO USE:
Complete a task (ๅฎๆไปปๅก) โ use 'complete_task'
Archive a task (not supported by API)
REQUIRED (per task):
projectId: Project containing the task (ๆธ ๅID)
taskId: Task to delete (ไปปๅกID)
INPUT FORMAT: { "tasks": [{ "projectId": "...", "taskId": "..." }, ...] }
โ ๏ธ IDEMPOTENT: Deleting a non-existent task returns success. Use 'get_task' first to verify existence if needed.
BATCH BEHAVIOR: Non-atomic - some may succeed while others fail. Check summary.failed > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Array of tasks to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses destructiveness (irreversible), idempotency (deleting non-existent returns success), and batch non-atomicity, meeting the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and warnings, every sentence adds value, and it is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While no output schema exists, the description mentions response fields like 'summary.failed' and covers batch behavior and idempotency. Minor gap on full response structure, but highly complete for a destructive batch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters. The description restates but adds no new semantic information beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes tasks with specific verb and resource, and distinguishes it from sibling tools like complete_task by specifying when not to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear guidance, including alternatives like complete_task and noting archive is unsupported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use ONLY when a Dida365 MCP tool (task/project operations) fails with an authorization/OAuth error (e.g. missing, expired, or invalid token), or the user explicitly asks to start/redo Dida365 authorization. Not for generic OAuth of other services. Provides a URL (โ10 min) to open in a browser; starts a local callback server to capture the authorization code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| auth_url | Yes | |
| expires_in | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it provides a time-limited URL and starts a local callback server. Could mention token storage but not essential for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema likely describing the return, the description covers the tool's purpose, usage context, and key behavioral details (time limit, callback server). Complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. No information needed beyond what the schema already provides (empty schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: to provide an authorization URL when OAuth errors occur or user requests reauthorization. It explicitly distinguishes from siblings by specifying it's not for generic OAuth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (authorization errors, user requests) and when not to use (not for generic OAuth). Provides context about URL validity (โ10 min) and the callback server mechanism.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata for a single project (ๆธ ๅ) by ID.
WHEN TO USE:
Check project settings (name/ๅ็งฐ, color/้ข่ฒ, viewMode/่งๅพๆจกๅผ, permissions)
Verify a project exists before operations
Get project metadata without loading tasks
WHEN NOT TO USE:
Need tasks within the project (ๆธ ๅๅ ็ไปปๅก) โ use 'get_project_data' or 'list_tasks'
Need to filter tasks by date/priority (ๆๆฅๆ/ไผๅ ็บง็ญ้) โ use 'list_tasks'
RETURNS: Project metadata only (id, name/ๅ็งฐ, color/้ข่ฒ, viewMode/่งๅพๆจกๅผ, kind/็ฑปๅ, permissions). Does NOT include tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The unique ID of the project to retrieve (ๆธ ๅID) |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | No | |
| name | Yes | |
| color | No | |
| closed | No | |
| groupId | No | |
| viewMode | No | |
| sortOrder | No | |
| permission | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior. Clearly states return value (project metadata only) and what it excludes (tasks). Implies read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections. Every sentence adds value, no redundancy. Concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool and existence of an output schema, the description is complete. It specifies what is returned and what is not, aligning with typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for projectId explaining it's the unique ID. Description adds context 'by ID' but does not add significant value beyond schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve metadata for a single project by ID', providing a specific verb and resource. It distinguishes from siblings like get_project_data and list_tasks by clarifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE and WHEN NOT TO USE sections with clear alternatives (get_project_data, list_tasks). Provides precise guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve complete project (ๆธ ๅ) data including project details, tasks (ไปปๅก), and kanban columns (็ๆฟๅ).
WHEN TO USE:
Get all uncompleted tasks (ๆชๅฎๆไปปๅก) within a specific project (ๆธ ๅ)
Need project metadata AND tasks together
View kanban column structure (็ๆฟๅ็ปๆ) for kanban-view projects
WHEN NOT TO USE:
Only need project metadata โ use 'get_project' (faster)
Filter tasks by date/priority/across projects (ๆๆฅๆ/ไผๅ ็บง็ญ้) โ use 'list_tasks'
Need completed tasks (ๅทฒๅฎๆไปปๅก) โ NOT available via API
โ ๏ธ LIMITATION: Only returns UNCOMPLETED tasks (ๆชๅฎๆไปปๅก, status=0). Completed tasks are not accessible.
RETURNS: { project, tasks[], columns[] } - project metadata (ๆธ ๅไฟกๆฏ), task list (ไปปๅกๅ่กจ), and kanban columns (็ๆฟๅ).
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The unique ID of the project to retrieve data for (ๆธ ๅID) |
| Name | Required | Description |
|---|---|---|
| tasks | No | |
| columns | No | |
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries behavioral transparency. Discloses limitation that only uncompleted tasks are returned and completed tasks are inaccessible. Mentions return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, front-loaded main purpose, no wasted sentences. Length appropriate for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description provides sufficient context about return data (project, tasks, columns). Covers all relevant behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'projectId' already well-documented. Description adds Chinese terms but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies the verb 'Retrieve', resource 'complete project data', and lists sub-resources. Distinguishes from sibling tools like 'get_project' and 'list_tasks' through explicit when-to-use guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections with specific scenarios and alternative tools (e.g., 'get_project' for metadata, 'list_tasks' for filtered tasks). Clearly states limitation about completed tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed information about a specific task (ไปปๅก).
WHEN TO USE:
View complete task details (title/ๆ ้ข, description/ๆ่ฟฐ, dates/ๆฅๆ, priority/ไผๅ ็บง)
Check task status before updating or completing
Verify a task exists
WHEN NOT TO USE:
List multiple tasks โ use 'list_tasks'
Get all tasks in a project (ๆธ ๅ) โ use 'get_project_data' or 'list_tasks'
REQUIRED: projectId (ๆธ ๅID), taskId (ไปปๅกID)
RESPONSE FIELDS:
content: Description for TEXT tasks (no sub-tasks)
desc: Description for CHECKLIST tasks (with sub-tasks/ๅญไปปๅก)
kind: "TEXT" or "CHECKLIST"
items: Sub-task list (ๅญไปปๅกๅ่กจ, CHECKLIST only)
NOTE: When creating/updating, use unified 'description' parameter which auto-maps to the correct field.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID (ไปปๅกID, required) | |
| projectId | Yes | Project ID (ๆธ ๅID, required) |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| desc | No | Task description for CHECKLIST tasks |
| etag | No | |
| kind | No | |
| tags | No | |
| items | No | |
| title | Yes | |
| status | No | |
| content | No | Task description for TEXT tasks |
| dueDate | No | |
| isAllDay | No | |
| priority | No | |
| timeZone | No | |
| projectId | Yes | |
| reminders | No | |
| sortOrder | No | |
| startDate | No | |
| repeatFlag | No | |
| completedTime | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations exist, the description discloses key behavioral aspects: response fields (content, desc, kind, items). It explains the distinction between TEXT and CHECKLIST tasks and includes a note about unified description parameter mapping. Missing explicit statement of read-only nature, but overall good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (general, WHEN TO USE, WHEN NOT TO USE, REQUIRED, RESPONSE FIELDS, NOTE). All sentences add value. Slightly verbose but organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool, the description is very complete. It covers purpose, usage guidelines, required parameters, response fields, and special behavior (TEXT vs CHECKLIST). With output schema existing, no further detail needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds Chinese translations and restates required parameters, but does not add substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve detailed information about a specific task', using a specific verb and resource. It distinguishes from siblings like list_tasks and get_project_data in the WHEN NOT TO USE section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides WHEN TO USE and WHEN NOT TO USE sections, naming alternatives and giving clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all projects (ๆธ ๅ/folders/lists) for the current user.
WHEN TO USE:
Get an overview of all projects (ๆฅ็ๆๆๆธ ๅ)
Find a project ID before operating on tasks (ๆฅๆพๆธ ๅID)
Check project names (ๅ็งฐ), colors (้ข่ฒ), and view modes (่งๅพๆจกๅผ)
RETURNS: Project list with id, name (ๅ็งฐ), color (้ข่ฒ), viewMode (่งๅพๆจกๅผ), permissions, kind (TASK=ไปปๅกๆธ ๅ/NOTE=็ฌ่ฎฐๆธ ๅ).
๐ก TIP: After getting the project list, use 'list_tasks' with projectId to get tasks, or 'get_project_data' for complete project data including tasks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a read-only operation but does not mention potential behaviors like pagination, rate limits, or auth beyond implicit user context. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose sentence, bulleted usage, return list, and tip. Every sentence adds value; no wasted words. Front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema, the description fully covers return fields (id, name, color, etc.) and provides actionable tip linking to sibling tools, making it complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema (schema coverage 100%). Per rule, baseline 4 for 0 params. Description does not add parameter info but correctly indicates no input needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve all projects for the current user' with specific verb and resource. It distinguishes from siblings like 'get_project' (single) and 'get_project_data' (complete data) via the usage section and tip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section provides clear use cases: overview, finding project ID, checking metadata. Lacks explicit when-not-to-use but tip suggests alternatives like 'get_project_data' for complete data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and filter tasks (ไปปๅก) across one or more projects (ๆธ ๅ).
WHEN TO USE:
Find tasks due today (ไปๅคฉ็ไปปๅก), this week (ๆฌๅจไปปๅก), or overdue (้พๆไปปๅก)
Filter tasks by priority (ไผๅ ็บง) or date range (ๆฅๆ่ๅด)
Search tasks across multiple projects (ๆธ ๅ) or inbox (ๆถ้็ฎฑ)
Get a filtered subset of tasks
WHEN NOT TO USE:
Need all tasks in one project without filtering โ use 'get_project_data'
Need a single specific task โ use 'get_task'
QUICK FILTERS (preset ๅฟซ้็ญ้):
"today": Tasks due today (ไปๅคฉ็ไปปๅก)
"tomorrow": Tasks due tomorrow (ๆๅคฉ็ไปปๅก)
"thisWeek": Tasks due this week (ๆฌๅจไปปๅก)
"overdue": Past-due tasks (้พๆไปปๅก)
OPTIONAL FILTERS:
projectId: Single ID, array of IDs, or "inbox" (ๆถ้็ฎฑ) (omit for all projects/ๆๆๆธ ๅ)
dueDateFrom/dueDateTo: Custom date range (่ชๅฎไนๆฅๆ่ๅด, ISO 8601)
priority: [0=none (ๆ ), 1=low (ไฝ), 3=medium (ไธญ), 5=high (้ซ)]
SORTING:
sortBy: "dueDate" (ๆชๆญขๆฅๆ, default), "priority" (ไผๅ ็บง), "createdTime" (ๅๅปบๆถ้ด)
sortOrder: "asc" (ๅๅบ, default), "desc" (้ๅบ)
โ ๏ธ LIMITATION: Only returns UNCOMPLETED tasks (ๆชๅฎๆไปปๅก, status=0). Completed tasks not available.
EXAMPLES:
Today's tasks (ไปๅคฉ็ไปปๅก): { "preset": "today" }
High priority from inbox (ๆถ้็ฎฑ้ซไผๅ ็บง): { "projectId": "inbox", "priority": [5] }
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tasks to return (ๆๅคง่ฟๅๆฐ้, default 50, max 200) | |
| preset | No | Quick date filter preset (ๅฟซ้็ญ้): today (ไปๅคฉ), tomorrow (ๆๅคฉ), thisWeek (ๆฌๅจ), overdue (้พๆ) | |
| sortBy | No | Sort field (ๆๅบๅญๆฎต): dueDate (ๆชๆญขๆฅๆ, default), priority (ไผๅ ็บง), createdTime (ๅๅปบๆถ้ด) | |
| priority | No | Filter by priority (ไผๅ ็บง): 0=none (ๆ ), 1=low (ไฝ), 3=medium (ไธญ), 5=high (้ซ) | |
| dueDateTo | No | Filter tasks with due date <= this value (ๆชๆญขๆฅๆ็ปๆ, ISO 8601 format) | |
| projectId | No | Project ID(s) (ๆธ ๅID) to filter. Use "inbox" for inbox tasks (ๆถ้็ฎฑ). If omitted, searches all projects (ๆๆๆธ ๅ). | |
| sortOrder | No | Sort order (ๆๅบๆนๅ): asc (ๅๅบ, default), desc (้ๅบ) | |
| dueDateFrom | No | Filter tasks with due date >= this value (ๆชๆญขๆฅๆ่ตทๅง, ISO 8601 format) |
| Name | Required | Description |
|---|---|---|
| tasks | Yes | |
| total | Yes | |
| filtered | Yes | |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key limitation that only uncompleted tasks are returned, and explains sorting and filtering behavior. No annotations exist, so the description fully covers behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and bullet points, making it easy to scan. However, it is somewhat lengthy and contains some redundancy with the schema, which could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive: it covers usage, exclusions, quick filters, optional filters, sorting, a limitation, and examples. Given the tool's complexity (8 optional params, no required), this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds value by including Chinese translations, examples, and clarifying use cases for presets, but some repetition exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists and filters tasks across projects. It uses specific verbs ('List and filter tasks') and distinguishes from sibling tools like get_project_data and get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections with direct references to alternatives (get_project_data, get_task). This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use ONLY when the user explicitly requests to log out, revoke, reset, clear, or remove Dida365 authorization/tokens, OR to cancel a pending authorization that cannot be completed. Do NOT call for token refresh, generic OAuth logout of other services, or routine task operations. Clears stored tokens and stops any running authorization server; user must re-authorize afterward.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: 'Clears stored tokens and stops any running authorization server; user must re-authorize afterward.' This informs the agent of destructive effects and required re-authorization. No annotations exist, so the description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first sentence front-loading the primary usage condition. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (though not shown), the description covers when to use, behavior, and consequences thoroughly. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description adds context about the tool's purpose and effect beyond the empty schema. Baseline is 4 for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'revoke, reset, clear, or remove Dida365 authorization/tokens'. It specifies the verb and resource, and distinguishes from sibling tools by contrasting with token refresh and generic OAuth logout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use ONLY when the user explicitly requests...' and provides specific scenarios (log out, revoke, reset, clear, remove, or cancel pending authorization). It also includes negative guidance: 'Do NOT call for token refresh, generic OAuth logout of other services, or routine task operations.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing project's (ๆธ ๅ) settings.
WHEN TO USE:
Rename a project (้ๅฝๅๆธ ๅ)
Change project color (้ข่ฒ), view mode (่งๅพๆจกๅผ), or type (็ฑปๅ)
Reorder projects in the list (่ฐๆดๆธ ๅ้กบๅบ)
PARTIAL UPDATE: Only provide fields you want to change. Unspecified fields remain unchanged.
REQUIRED: projectId (ๆธ ๅID)
OPTIONAL (at least one required):
name: New project name (ๆฐๅ็งฐ)
color: New hex color (ๆฐ้ข่ฒ, e.g., '#F18181')
viewMode: 'list' (ๅ่กจ), 'kanban' (็ๆฟ), or 'timeline' (ๆถ้ด็บฟ)
kind: 'TASK' (ไปปๅกๆธ ๅ) or 'NOTE' (็ฌ่ฎฐๆธ ๅ)
sortOrder: New position in project list (ๆฐๆๅบไฝ็ฝฎ)
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | New project type (ๆฐ็ฑปๅ): 'TASK' (ไปปๅกๆธ ๅ), 'NOTE' (็ฌ่ฎฐๆธ ๅ). Optional. | |
| name | No | New project name (ๆฐๆธ ๅๅ็งฐ). Optional. | |
| color | No | New project color in hex format (ๆฐ้ข่ฒ, e.g., '#F18181'). Optional. | |
| viewMode | No | New view mode (ๆฐ่งๅพๆจกๅผ): 'list' (ๅ่กจ), 'kanban' (็ๆฟ), 'timeline' (ๆถ้ด็บฟ). Optional. | |
| projectId | Yes | The unique ID of the project to update (ๆธ ๅID, required) | |
| sortOrder | No | New sort order (ๆฐๆๅบไฝ็ฝฎ). Optional. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | No | |
| name | Yes | |
| color | No | |
| closed | No | |
| groupId | No | |
| viewMode | No | |
| sortOrder | No | |
| permission | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses partial update behavior, required projectId, and optional parameters. It does not cover permissions, reversibility, or potential side effects, but for a simple update tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with headings and bullet points, each section concise and valuable. No redundant information; front-loaded with purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 1 required) and 100% schema coverage, the description is complete. It covers usage, partial update, and parameter details. Output schema exists but its content is not needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by grouping fields (required/optional), providing Chinese translations, and clarifying the 'at least one required' constraint. Examples for color and sortOrder further aid understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing project's settings' and lists specific use cases (rename, change color, view mode, type, reorder). It distinguishes from siblings like create_project and delete_project through context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'WHEN TO USE' section with explicit scenarios, partial update behavior, and required vs optional parameters. It does not explicitly state when NOT to use it or mention alternatives like create_project, but the sibling list and context signals provide implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update one or more existing tasks (ไปปๅก). Supports batch updates.
WHEN TO USE:
Modify task title (ๆ ้ข), description (ๆ่ฟฐ), dates (ๆฅๆ), or priority (ไผๅ ็บง)
Change due date (ๆชๆญขๆฅๆ) or add reminders (ๆ้)
Add/update sub-tasks (ๅญไปปๅก/ๆฃๆฅ้กน)
Reschedule or reprioritize tasks
REQUIRED (per task):
taskId: Task to update (ไปปๅกID)
projectId: Project containing the task (ๆธ ๅID)
OPTIONAL (only provided fields are updated):
title: New task title (ๆฐๆ ้ข)
description: New notes (ๆฐๆ่ฟฐ, auto-maps to correct field)
dueDate: ISO 8601 format (ๆชๆญขๆฅๆ, e.g., "2025-11-25T17:00:00+0800")
startDate: ISO 8601 format (ๅผๅงๆฅๆ)
priority: 0=none (ๆ ), 1=low (ไฝ), 3=medium (ไธญ), 5=high (้ซ)
isAllDay: true for all-day tasks (ๅ จๅคฉไปปๅก)
reminders: ["TRIGGER:PT0S"] (ๆ้)
repeatFlag: Recurrence rule (้ๅค่งๅ)
items: Sub-task array (ๅญไปปๅกๅ่กจ) [{title, status: 0|1}]
INPUT FORMAT: { "tasks": [{ "taskId": "...", "projectId": "...", ...updates }, ...] }
BATCH BEHAVIOR: Non-atomic - some may succeed while others fail. Check summary.failed > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Array of tasks to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral traits: batch updates are non-atomic with failed checks, auto-mapping of description based on task type, and the side effect of task becoming CHECKLIST when items provided. It lacks auth or rate limit info but is adequate for a task update tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WHEN TO USE, REQUIRED, OPTIONAL, INPUT FORMAT, BATCH BEHAVIOR) and bullet points. Slightly verbose but front-loads essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers most aspects for a complex batch update tool: input format, batch behavior, required/optional fields, and key behaviors. Missing details on error handling beyond failed count, batch size limits, and return structure (no output schema). Could add what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds bilingual labels, practical notes (auto-mapping of description, date format examples, priority values), and explains conditional behavior like 'items' making task a checklist. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates one or more existing tasks and supports batch updates. It uses a specific verb and resource, and distinguishes from sibling tools like complete_task by including batch behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section lists specific modification scenarios (title, description, dates, priority, sub-tasks) and required parameters. It also explains batch non-atomicity. However, it does not explicitly state when not to use or compare with alternatives like complete_task, missing a bit of guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource (project, task, auth) and action (create, read, update, delete, list), with no overlapping purposes. Auth tools are clearly separated from task operations.
All tools use a consistent verb_noun pattern in snake_case (e.g., create_project, list_tasks, revoke_auth), making it easy to predict functionality from names.
15 tools cover the full lifecycle of projects and tasks plus authentication support, without unnecessary redundancy. The count is well-scoped for a task management MCP server.
The surface includes CRUD for projects and tasks, batch operations, filtering, and auth flow. No obvious gapsโcore workflows are fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/evalor/Dida365MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
