Skip to main content
Glama

todo_complete

Mark a todo as done or reopen it, then retrieve the todo IDs that this change unblocks, keeping project workflow in sync.

Instructions

Mark a todo complete (or reopen with completed=false). Returns todo ids that this completion newly unblocked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
todo_idYes
completedNoDefaults to true.
project_idNoDifferent project override. Use ONLY when the user explicitly asks for another project by name; otherwise stay in the current scope, even when results are empty.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
todo_idYes
completedYes
project_idYes
newly_unblockedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states the mutation effect, the reopen path, and that the tool returns todo ids newly unblocked. It does not cover idempotency or permissions, but the core side effects and return behavior are transparent enough for a simple toggle tool.

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?

One tight sentence with no filler. The primary action is front-loaded, and the key qualifier (completed=false) and return value are included immediately. Every part 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?

Given the low parameter complexity, an output schema, and strong schema descriptions, the description is sufficient. It explains the action, the main parameter behavior, and the meaningful return. No critical information needed to invoke the tool correctly is missing.

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 67%, so the schema already documents project_id well. The description adds semantic meaning to completed by explaining that false means reopen, which goes beyond the schema's 'Defaults to true.' todo_id is implicit in the main action, and project_id is fully covered by the schema.

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: 'Mark a todo complete', and adds the reopen behavior when completed=false. This clearly identifies the tool's purpose and distinguishes it from generic todo_update or todo_archive. An agent can tell what this tool does without opening the schema.

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?

The intended use is implied: call this when a todo should be marked complete or reopened. However, it does not explicitly say when to prefer todo_complete over siblings like todo_update, nor does it mention exclusions or alternatives. The guidance is adequate but relies on inference.

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