Skip to main content
Glama

ticktick_filter_tasks

Filter TickTick tasks by project, priority, tag, status, and due or completion date, returning only tasks that match all criteria.

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.
      Accepts the project's name as well as its ID
      (case-insensitive, trimmed). Two projects sharing a
      name is an error, not a guess.
    * ``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
detailNocompact
filter_criteriaYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations to fall back on, the description carries the full burden and does so excellently. It discloses freshness semantics (local state vs. live completed queries), truncation behavior with an explicit _truncation_note, server-side caps, client-side filtering implications, and the danger of feeding compact output into an update.

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

Conciseness5/5

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

Although long, the description is exceptionally well structured with clear sections (Args, Returns, Freshness, Limitations, Agent Usage Guide). Every sentence delivers actionable information; the front-loaded summary sentence is immediately followed by organized detail, making it easy to scan.

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?

The tool is complex (multi-criteria filtering, date windows, status-dependent behavior), and the description is fully complete: return formats, error schema, truncation semantics, staleness handling, and realistic examples. The presence of an output schema is noted, but the description adds beyond it by explaining the compact vs. full distinction and the conditions affecting results.

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 provides zero descriptions for parameters, but the description compensates with exhaustive semantics: detail choices and their implications, all filter_criteria keys, types, defaults, accepted values (including priority mapping), date field applicability, case sensitivity, timezone defaults, and error conditions like ambiguous project names.

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 opens with a clear verb+resource: 'Return the tasks matching every supplied filter criterion.' It immediately distinguishes this from sibling tools (e.g., ticktick_get_all, ticktick_get_by_id, ticktick_get_tasks_from_project) by emphasizing filtering across multiple criteria rather than simple retrieval.

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 description provides an explicit 'Agent Usage Guide' with concrete JSON examples for open tasks, completed tasks in a date window, and high-priority tasks. It also names alternatives, such as using ticktick_get_by_id + ticktick_update_task for editing and ticktick_sync for forced refresh, and states when not to use compact output.

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