Skip to main content
Glama

ticktick_filter_tasks

Retrieve tasks by project, priority, tag, status, and due or completion date. Supports compact or full detail, sorting, and handles truncation.

Instructions

Return the tasks matching every supplied filter criterion.

Supports any combination of project, priority, tag, status, and a date window applied to either the due date (open tasks) or the completion timestamp (completed tasks).

Args: detail (str, optional): "compact" (default) or "full". Compact drops the heavy content/desc/checklist items blobs and bulky sync metadata, keeping id, projectId, title, dueDate, startDate, priority, status, isAllDay, timeZone, tags plus a contentPreview (first ~200 chars of content) so keyword search still works. Full returns the raw task objects unchanged. To EDIT a task, fetch the full object with ticktick_get_by_id first, then send every field back via ticktick_update_task -- compact output must never feed an update. filter_criteria (dict | str): A criteria object, or a JSON string that decodes to one. Recognised keys:

    * ``status``: ``"uncompleted"`` (default) or ``"completed"``.
      When ``"completed"`` you should supply
      ``completion_start_date`` and/or ``completion_end_date``;
      without dates the result is an empty list.
    * ``project_id`` (str): Limit to tasks in this project.
    * ``priority`` (int): 0=None, 1=Low, 3=Medium, 5=High.
    * ``tag_label`` (str): Tag name (case-sensitive).
    * ``due_start_date`` / ``due_end_date`` (str): ISO date or
      datetime strings; only used when ``status='uncompleted'``.
    * ``completion_start_date`` / ``completion_end_date`` (str):
      ISO date or datetime strings; only used when
      ``status='completed'``.
    * ``tz`` (str): Default IANA timezone applied to date filters.
    * ``sort_by_priority`` (bool): Sort by descending priority.

Returns: JSON list of matching task objects (compact by default; see detail). Empty list if nothing matches. If a compact result would still exceed the size budget, the soonest-due matches are returned and a final _truncation_note element reports how many were omitted -- nothing is dropped silently. On invalid input or backend failure: {"error": "...", "status": "error"}.

Freshness: Uncompleted queries read local state, synced from the server at most once per throttle window (default 15s, TICKTICK_MCP_SYNC_TTL_SECONDS); a change made elsewhere within that window may not be visible yet -- call ticktick_sync to force a refresh. Completed queries are always fetched live.

Limitations: - TickTick caps get_completed at 100 results; very wide completion windows are truncated server-side. - Filtering happens client-side after the fetch, so additional criteria do not reduce the number of network requests. - Compact output is for browsing only; full content for one task is available via ticktick_get_by_id or detail="full".

Agent Usage Guide: - List open tasks in a project: {"status": "uncompleted", "project_id": "<id>"} - List completed tasks in the last 7 days: { "status": "completed", "project_id": "<id>", "completion_start_date": "2026-05-21", "completion_end_date": "2026-05-28" } - Find high-priority open tasks due this month, sorted: { "priority": 5, "due_start_date": "2026-05-01", "due_end_date": "2026-05-31", "sort_by_priority": true }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filter_criteriaYes
detailNocompact

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses freshness (local state with 15s sync window), truncation behavior with _truncation_note, client-side filtering, server-side cap of 100 for completed tasks, and error format. This fully informs the agent of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with clear sections (Args, Returns, Freshness, Limitations, Agent Usage Guide). Essential information is front-loaded. Some redundancy exists (e.g., examples in both Args and Usage Guide), but overall it is efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (nested filter_criteria), the description covers input, output (including error and truncation), freshness, limitations, and relationships to sibling tools. The existence of an output schema is noted, and the description adds necessary detail beyond it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description thoroughly documents both parameters. filter_criteria lists all recognized keys, defaults, and usage. detail explains compact and full modes, including implications for editing. Examples further clarify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool filters tasks by multiple criteria, lists supported criteria (project, priority, tag, status, date window), and distinguishes from sibling tools like ticktick_get_by_id and ticktick_get_all.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The Agent Usage Guide provides explicit examples and explains when to use compact vs full detail. It warns that compact output must not feed an update and directs to ticktick_get_by_id for editing. Limitations and freshness are also well documented.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/partymola/ticktick-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server