Skip to main content
Glama

Todoist Create Task

todoist_create_task

Create a Todoist task. Optionally set a project, a natural-language due date (due_string, e.g. 'tomorrow 5pm', 'every monday'), and priority (1=normal … 4=urgent).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesThe task text
priorityNo1 (normal) to 4 (urgent). Todoist UI p1 = 4.
due_stringNoNatural-language due date, e.g. 'tomorrow 5pm', 'next monday'
project_idNoProject to add it to (default: Inbox)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
dueNo
urlNo
contentNo
priorityNo
project_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already signal readOnlyHint=false and destructiveHint=false, and the description's 'Create' is consistent with those. The description adds minimal behavioral context beyond the annotations—no mention of side effects, duplicate behavior, or prerequisite connection—so it is consistent but thin.

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 a single front-loaded sentence: the core action 'Create a Todoist task' leads, followed by the three optional knobs (project, due_string, priority) with no filler or repetition of schema details.

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

Completeness4/5

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

With all 4 parameters documented in the schema, an output schema present, and annotations covering the safety profile, the description is nearly sufficient for correct invocation. It omits the explicit distinction from todo_create_task and any connection prerequisite, but it does not need to explain return values.

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 baseline is 3. The description reinforces due_string with examples and the priority scale, but the schema already documents these parameters fully; the description adds no meaning beyond what the schema provides.

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 states a specific verb and resource: 'Create a Todoist task.' The Todoist qualifier clearly differentiates it from sibling tools like todo_create_task, complete_reminder, or create_omnifocus_task, while the optional-field summary adds scope without ambiguity.

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

Usage Guidelines3/5

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

Usage is implied: an agent should use this when it needs to create a Todoist task. However, the description does not explicitly name alternatives, state when not to use it, or mention that a Todoist connection (connect_todoist) may be required, leaving routing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources