Done Bear

Manage Task Checklist

checklist

Destructive

Change the checklist on a task. action: "add" appends items, unchecked, after the existing ones: pass every title for a multi-item list in one call (titles keeps the given order, while parallel single adds land in arrival order). action: "edit" renames an item and/or checks it (completed: true) or unchecks it (completed: false). action: "remove" deletes one. Read the list, with each item's id and state, from task_show.

Input Schema

TableJSON Schema

Name	Required	Description
`item`	No	Checklist item UUID or prefix (>= 4 chars). Required to edit or remove
`task`	Yes	Workspace-scoped task number, encoded as a string
`title`	No	One item title to add, or the new title on an edit
`action`	Yes	What to do to the checklist
`titles`	No	Several item titles to add, kept in the given order (use instead of `title`)
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`completed`	No	Check (true) or uncheck (false) the item, on an edit
`workspace`	No	Workspace id, slug, or name
`idempotency_key`	No	Stable key that makes retries safe: repeated calls with the same key create only one record and return the same id.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`count`	Yes
`items`	Yes	The items the call created or changed
`action`	Yes
`taskId`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

AddedSep 4, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes beyond the annotations by disclosing that additions append unchecked after existing items, that `titles` preserves order while parallel single adds land in arrival order, and that edit can rename and toggle `completed`. All disclosures are consistent with destructiveHint=true and readOnlyHint=false; no contradiction found.

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?

A single dense paragraph that front-loads the purpose and then walks through each action with inline code formatting. Every clause earns its place, though the ordering parenthetical in the second sentence packs multiple caveats into one breath.

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?

Given 100% schema coverage and an output schema for return values, the description covers the essential operational surface: all three actions, the item-identification workflow via task_show, and ordering semantics. Minor gaps remain around error behavior (e.g., unknown item prefix) but nothing an agent needs to invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description adds genuine value on top: it ties `action` values to parameter relevance (item required only for edit/remove, completed meaningful only on edit) and clarifies the title/titles substitution. This cross-parameter meaning is not recoverable from the individual schema descriptions.

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?

Opens with a precise verb+resource statement ('Change the checklist on a task') and enumerates three concrete operations (add, edit, remove) with their exact effects. This clearly distinguishes it from sibling task-level tools like task_add and task_edit, which operate on tasks rather than checklist items.

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?

Provides explicit operational guidance: use a single call with `titles` to preserve order for multi-item adds versus parallel single adds, and read items and their ids via task_show before editing or removing. It does not explicitly name excluded alternatives, but the task_show pointer and action-mode breakdown make the intended workflow clear.

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

All Done Bear tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools map to clearly distinct resources and actions: task lifecycle verbs, sub-resource tools (attachment, checklist, comment), and search are easy to tell apart. The only mild overlaps are search vs task_list's built-in search parameter and get_context vs task_list for recent tasks, but the descriptions give enough guidance to avoid frequent misselection.

Naming Consistency3/5

Task operations consistently follow a task_verb pattern, but other tools use bare resource nouns (attachment, checklist, comment, project), plus get_context, guide, label_create, and search break the pattern further. The names are readable, but the convention is mixed rather than uniform.

Tool Count5/5

At 15 tools, the set sits at the upper end of the well-scoped range but each tool has a distinct responsibility: task lifecycle, search, sub-resources, project/label management, context, and guidance. None feel redundant, and the count matches the breadth of the task-management domain.

Completeness3/5

Core task workflows are well covered: create, read, update, complete, reopen, archive, list, and search, plus comments, checklists, and attachments. Notable gaps remain: labels only support creation, archived tasks have no explicit restore path, and projects cannot be deleted or archived.

Resources

Need Help?