# Reported issues for dida365

Pod holds 10 of 10 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [dida365](/mcp/dida365).

## Most discussed

### API returns misleading success when completing non-existent taskId

## Description

When attempting to complete a task with a non-existent `taskId`, the API returns a success response even though no task was actually completed. This misleading behavior can cause users to believe their operation succeeded when it actually had no effect.

## Steps to Reproduce

1. Call the `complete_task` tool with a non-existent `taskId`
2. Observe that the API returns a success response
3. Verify that no task status was actually changed

## Expected Behavior

The API should retu

[Read the thread](https://github.com/evalor/Dida365MCP/issues/17) · 2025-11-26 · open · 1 comment

### API silently redirects tasks to Inbox when invalid projectId is provided

## Description

When creating a task with a non-existent `projectId`, the API silently creates the task in the Inbox instead of returning an error. This behavior can lead to user confusion as tasks may end up in unexpected locations without any warning.

## Steps to Reproduce

1. Call the `create_task` tool with an invalid/non-existent `projectId`
2. Observe that the API returns a success response
3. Check where the task was actually created

## Expected Behavior

The API should either:
- Return

[Read the thread](https://github.com/evalor/Dida365MCP/issues/16) · 2025-11-26 · open · 1 comment

### feat: Add Simplified Chinese terminology mapping to improve LLM understanding for Chinese users

## Problem Description

The current MCP server tool descriptions use English terminology only. This causes LLMs to potentially fail when mapping Simplified Chinese user requests to the correct tool calls.

## Specific Issues

Dida365 uses different terminology in its Chinese interface compared to the English version (TickTick):

| English Term | Chinese Term | Description |
|-------------|--------------|-------------|
| Inbox | 收集箱 | Default location for uncategorized tasks |
| Project | 清单 | Co

[Read the thread](https://github.com/evalor/Dida365MCP/issues/9) · 2025-11-25 · closed · 1 comment

### Add project scope restriction to limit AI access to specific projects

## Summary

Users may have numerous projects in their Dida365/TickTick account, but they may want to restrict AI access to only specific projects for security and privacy reasons. We need to provide a configuration option that allows users to specify allowed `projectId`(s) to limit the AI's access scope.

## Motivation

- **Security**: Users may have sensitive projects they don't want AI to access or modify
- **Safety**: Prevent accidental modifications to important projects when using YOLO mode

[Read the thread](https://github.com/evalor/Dida365MCP/issues/7) · 2025-11-25 · open · 1 comment

### Improve and standardize tool descriptions for better AI tool selection

## Summary

The current MCP tool descriptions lack consistent, high-quality prompts that help AI models select the appropriate tool for user requests. Well-crafted tool descriptions are essential for reducing tool confusion and improving the overall user experience.

## Problem

- Tool descriptions are not optimized for AI comprehension
- Inconsistent description patterns across different tools
- AI may struggle to differentiate between similar tools (e.g., `get_project` vs `get_project_data`)
-

[Read the thread](https://github.com/evalor/Dida365MCP/issues/6) · 2025-11-25 · closed · 1 comment

### Bug: get_project_data and list_tasks fail due to missing .passthrough() in outputSchema

### Bug Description

`get_project_data` and `list_tasks` tools always return "Tool execution failed" in Claude Desktop, even though the MCP server successfully fetches and returns the correct data from the Dida365 API. `get_task` works fine.

### Root Cause

The `outputSchema` in `get_project_data` and `list_tasks` uses `z.object({...})` **without** `.passthrough()`, while `get_task` correctly uses `.passthrough()`. 

The Dida365 API returns fields not defined in the schema (e.g., `etag`, `tags`

[Read the thread](https://github.com/evalor/Dida365MCP/issues/20) · 2026-03-10 · open · external user · 0 comments

### Bug: sortBy createdTime does not work correctly

## Description

When using `list_tasks` with `sortBy: "createdTime"` and `sortOrder: "desc"`, tasks are not sorted by creation time correctly. The oldest tasks appear first instead of the newest.

## Steps to Reproduce

1. Call `list_tasks` with the following parameters:
```json
{
  "sortBy": "createdTime",
  "sortOrder": "desc",
  "limit": 5
}
```

2. Decode the ObjectID timestamps of the returned tasks

3. Observe that tasks are sorted oldest-first, not newest-first as expected

## Expected Be

[Read the thread](https://github.com/evalor/Dida365MCP/issues/19) · 2026-01-26 · open · external user · 0 comments

### Add MCP Resource for iCalendar TRIGGER and RRULE Format Reference

## Summary

Add an MCP Resource to help LLMs understand the iCalendar (RFC 5545) format for `reminders` (TRIGGER) and `repeatFlag` (RRULE) parameters used in task creation and updates.

## Background

Dida365/TickTick uses iCalendar (RFC 5545) standard formats for:
- **Reminders**: Uses `TRIGGER` format (e.g., `TRIGGER:PT0S`, `TRIGGER:-PT30M`)
- **Repeat Rules**: Uses `RRULE` format (e.g., `RRULE:FREQ=DAILY;INTERVAL=1`)

Currently, LLMs may not know how to correctly fill in these parameters when

[Read the thread](https://github.com/evalor/Dida365MCP/issues/12) · 2025-11-25 · closed · 0 comments

## Most recent

### Improve OAuth Authorization Flow UX: Allow Repeated Tool Calls and Provide Authorization URL in Pending State

## Problem Description

During the OAuth authorization process, there are several UX issues that prevent LLMs from correctly guiding users through authorization:

### Issue 1: `get_auth_url` Cannot Be Called Repeatedly

**Current Behavior:**
When authorization is in progress (callback server running), calling `get_auth_url` throws an error:
```
Authorization already in progress. Please complete or cancel the current authorization.
```

**Expected Behavior:**
The tool should be idempotent. If the

[Read the thread](https://github.com/evalor/Dida365MCP/issues/11) · 2025-11-25 · closed · 0 comments

### Token Reuse Causes Client Credential Mismatch

## Summary
When a user changes `DIDA365_CLIENT_ID` and `DIDA365_CLIENT_SECRET` (e.g. updates `.env` with a new OAuth application), the locally stored `tokens.json` is still reused because it does not record which client it belongs to. This results in:
- Continuing to operate under the previous OAuth client context while expecting the new one
- Potential permission scope mismatch if the new client has different grants
- Inability to safely switch between multiple client configurations

## Affecte

[Read the thread](https://github.com/evalor/Dida365MCP/issues/1) · 2025-11-24 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/evalor/Dida365MCP/issues).