Reduce provided task data to reduce size of total data

[joro75]

Adds the _filter_unneeded_properties function, which removes all properties of tasks, that are not very useful, when a list of tasks is being retrieved.
This reduces the size of the total content that is passed from the MCP server to the MCP client, and thus very probably also reduces the data that is transmitted to the LLM. Another benefit is that the LLM is not confused with all kind of properties that are listed, but do not have useful information.

Retrieving the full information of a task is still possible by using the ticktick_get_by_id function which still provides all the available properties and all information for a specific task.

[jen6]

I’m not sure that those fields aren’t useful.
Could you please comment on the As-Is and To-Be states of the response changed by this PR? @joro75

[joro75]

I'm using the ticktick_mcp in combination with a LLM (have been tested with Azure-OpenAI and with Gemini-2.5), in my own web-client. I discovered that there are two disadvantages in providing a lot of unneeded data of tasks to the LLM:

1. The LLM is being confused by all the unrelated data
2. The LLM is using a lot of input tokens (and longer processing time) to interpret the task information.
   Especially with a large amount of task in TickTick, and a continued chat-session this is causing a lot of problems.

That is why I have implemented this PR to remove all unneeded information from the task information. Also fields that are logical and do not have any usefull information are also removed.

A single task information with all the information could be:

{
    "id": "6887681d52503f72c3bff098",
    "projectId": "inbox112795927",
    "sortOrder": 552608910540800,
    "title": "<<task-title>>",
    "content": "<<some-content>>",
    "desc": "",
    "startDate": "2025-07-27T22:00:00.000+0000",
    "dueDate": "2025-07-27T22:00:00.000+0000",
    "timeZone": "Europe/Amsterdam",
    "isFloating": false,
    "isAllDay": true,
    "reminders": [],
    "repeatFirstDate": "2025-07-27T22:00:00.000+0000",
    "repeatFlag": "",
    "exDate": [],
    "repeatTaskId": "6887681d52503e88c3bff098",
    "priority": 0,
    "status": 0,
    "items": [],
    "progress": 0,
    "modifiedTime": "2025-07-28T17:29:52.000+0000",
    "etag": "4esoju2h",
    "deleted": 0,
    "createdTime": "2025-07-28T12:07:57.000+0000",
    "creator": 112795927,
    "repeatFrom": "2",
    "attachments": [],
    "commentCount": 0,
    "focusSummaries": [],
    "columnId": "654a9a1638d6c937da0592b8",
    "kind": "TEXT",
    "imgMode": 0
}

while the same reduced information of the same task is:

{
    "id": "6887681d52503f72c3bff098",
    "projectId": "inbox112795927",
    "title": "<<task-title>>",
    "content": "<<some-content>>",
    "startDate": "2025-07-27T22:00:00.000+0000",
    "dueDate": "2025-07-27T22:00:00.000+0000",
    "timeZone": "Europe/Amsterdam",
    "isAllDay": true,
    "repeatFirstDate": "2025-07-27T22:00:00.000+0000"
}

All still important and relevant information is included.

[jen6]

It's still useful even if the value is 0. Does it have to be removed?

[joro75]

Leaving the 0-values in, is not adding any additional information, but it is causing larger responses (bigger JSON objects), and with 100's of tasks being returned this is causing problems when the LLM only is interpreting the first part of the response. That is why all unnecesary data is being stripped, it is faster, the input-token-limit of the LLM is not reached, and the the LLM is less confused with the unnecessary data.