Todoist MCP Server

fetch-object

Read-onlyIdempotent

Retrieve full details of a task, project, comment, or section using its ID. Optionally include direct subtasks or sub-projects to check for child items.

Instructions

Fetch a single task, project, comment, or section by its ID. Use this when you have a specific object ID and want to retrieve its full details. Set includeChildren to also get its direct subtasks or sub-projects.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The unique ID of the object to fetch.
`type`	Yes	The type of object to fetch.
`includeChildren`	No	Also return the direct children of the object: subtasks for a task, sub-projects for a project. Returns childCount plus a compact list, flagging each child that has children of its own. Use this to check whether a task hides subtasks instead of a speculative find-tasks lookup. Ignored for comments and sections.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The ID of the fetched object.
`type`	Yes	The type of object fetched.
`object`	Yes	The fetched object data.
`children`	No	Direct children only: subtasks for a task, sub-projects for a project. Completed subtasks and archived sub-projects are excluded.
`childCount`	No	The number of direct children listed in children. Only present when children were requested and the type supports them. 0 means the object definitively has none.
`childrenError`	No	Present when the children lookup failed or returned incomplete information. When no children are listed alongside it, childCount is unknown - do not read its absence as "no children".
`hasMoreChildren`	No	Present when the object has more than 25 direct children and the list was truncated. Page through the rest with find-tasks by parentId for subtasks, or find-projects for sub-projects.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv13.3.1Sep 22, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by noting that includeChildren retrieves direct subtasks or sub-projects, which goes beyond the basic annotations. No contradiction with annotations exists.

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?

The description is three short sentences with no filler. It front-loads the core action, immediately provides the usage context, and then covers the optional parameter. Every sentence earns its place.

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 description is complete for a read-only single-object fetch tool. Combined with rich schema descriptions, annotations, and an output schema, an agent has everything needed to select and invoke the tool correctly without ambiguity.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents id, type, and includeChildren. The description reinforces the parameter usage with 'by its ID' and 'direct subtasks or sub-projects,' but it does not add meaning substantially beyond the schema's existing parameter descriptions. Baseline 3 is appropriate.

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 uses a specific verb ('Fetch') and names the exact resources ('task, project, comment, or section') plus the key selector ('by its ID'). It clearly distinguishes this single-object fetch tool from sibling find/search tools by emphasizing the need for a specific object ID.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool: 'Use this when you have a specific object ID and want to retrieve its full details.' It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to route to this tool instead of a find/search tool.

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