Skip to main content
Glama

mnemosyne_todo_add

Add tasks to a named to-do list in the human's backlog, optionally grouped under steps, in execution order. Use it after a conversation settles what to do, so every agreed action becomes a visible, concrete task.

Instructions

Put tasks into the human's To-do backlog (the To-do widget on their canvas) — in order, optionally under named steps. Use it when a conversation has settled WHAT to do: "make tasks out of everything we said we would do". Name the list ("list") — call once without it to be told the lists that exist on a LIST_NOT_FOUND answer — or pass create_list: true to make a new one. Never assume a default list. The host routes the write through the widget's own store, so what you file is exactly what the human sees. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. To read the backlog back or change what is in it, see mnemosyne_todo_list, mnemosyne_todo_update and mnemosyne_todo_lists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
listNoDisplayed name of the destination list (case-insensitive), e.g. "En cours", "WIP", or a list the human created. Omitted = the first original list. Unknown name + create_list false = refused with the names that exist.
colorNoHex colour (#rrggbb) for a list being created. Optional; the host picks the next swatch otherwise.
tasksYesThe tasks, in execution order. Each item is a string, or {"text": string, "group": string} where group is the STEP the task belongs to (e.g. "Step 1 · Mockup"); tasks with the same group are shown under one header in the list. One concrete, actionable line each; 300 characters max.
create_listNoCreate the list named in "list" when it does not exist. Default false: an agent must not invent lists in someone's backlog without saying so.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.10.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does substantial work: it explains that writes route through the widget's own store, that what is filed is exactly what the human sees, and that behavior differs between dev installs with a daemon and npm installs without one. It omits permissions, idempotency, and success-response shape, but for a write tool it is unusually transparent.

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 dense but efficiently front-loaded with the action, the trigger, and the key list-handling rule; environment details and sibling routing are placed later where they belong. It earns its length, though the LIST_NOT_FOUND sentence is tangled and could be tightened.

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?

For a tool with no output schema, the description covers why/when to use it, how to discover or create lists, persistence through the widget store, environment requirements, and alternatives for related operations. It does not explicitly describe the success return value or downstream effects on existing tasks, which is a modest gap, but the overall context is strong.

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%, and the schema already documents each parameter in detail, including list default/error behavior, hex color, task group semantics, the 300-character limit, and create_list's default. The description adds operational framing rather than new parameter meaning, and its LIST_NOT_FOUND wording slightly muddies the list-omission semantics, so the 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 opens with a specific verb and resource: 'Put tasks into the human's To-do backlog,' adding ordering and grouping semantics. It also distinguishes itself from siblings by pointing to mnemosyne_todo_list, mnemosyne_todo_update, and mnemosyne_todo_lists for read/change operations, so an agent can tell them apart without inspecting schemas.

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?

It gives an explicit trigger ('when a conversation has settled WHAT to do') and warns never to assume a default list, plus points to sibling tools for reading or changing the backlog. However, the sentence about calling without `list` to get a LIST_NOT_FOUND answer is convoluted and sits awkwardly against the schema's statement that omitting `list` selects the first original list, so the guidance is not perfectly crisp.

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