Skip to main content
Glama

add_tasks

Append multiple checkbox tasks to PLAN.md in one write, applying shared done/agent flags to every item, reducing repetitive task creation.

Instructions

Append several checkbox tasks in one write. Prefer this over repeated add_task. Shared done/agent apply to every item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doneNoMark every added task done (default false).
agentNoOptional agent id tag written as [agent: id] on touched lines.
tasksYesTask texts to append, in order.
versionYes
plan_pathNoOptional path to PLAN.md (relative to cwd or absolute). Default: walk up from cwd to nearest PLAN.md.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It adds useful context by saying this is a single write and that done/agent apply to every item, but it does not disclose side effects, permissions, return behavior, or how 'checkbox tasks' are formatted. Some behavioral transparency is present, but gaps remain.

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?

Three short sentences, each earning its place: the core action, the selection guidance, and the shared-parameter behavior. It is front-loaded and free of filler.

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

Completeness3/5

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

The description covers purpose and usage well and the schema covers most parameters, but the required 'version' field is entirely undocumented in both schema and description. With no output schema and no annotations, this is a noticeable gap for an agent that must provide a valid version value.

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 80%, so the schema already documents most parameters. The description reinforces that done/agent are shared across all tasks, but this largely restates what the schema says. The required 'version' parameter still has no description and is not explained in the tool description.

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 identifies the action ('Append'), the resource ('checkbox tasks'), and the batching mode ('in one write'). It also differentiates from the sibling add_task by explicitly preferring this tool over repeated add_task calls.

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 explicitly states when to use this tool: for appending several tasks at once, and names the alternative ('repeated add_task') that it is preferred over. This gives an agent clear selection guidance without needing to open the schema.

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