Skip to main content
Glama

accelo_progress_task_to_done

Mark a task complete by automatically progressing its status to done, using the provided task ID to update the record.

Instructions

Auto-progress a task's status to "done" (mark it complete).

Args: id: Task ID

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a state mutation but does not say whether the change is reversible, whether it validates the current status, whether it errors if the task is already done, or what else the progression cascades to. 'Auto-progress' hints at automation of other fields but is left unexplained.

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 one sentence plus a short args block, front-loaded with the action and outcome. It is efficient and not padded, though the 'Args:' block is a slightly awkward format for a one-parameter tool.

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

Completeness2/5

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

For a state-mutating task operation with no annotations, no output schema, and an ambiguous name next to accelo_progress_task_to_start, the description should explain side effects, idempotency, and error cases. None of that is present, leaving meaningful gaps for an agent invoking it.

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 coverage is 0% in the formal sense, so the description's 'Args: id: Task ID' line does supply the only human-readable meaning for the single required parameter. It confirms the type (task identifier) but adds nothing about format, source, or whether it accepts a human-readable key.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (progress) and resource (task status) with a clear outcome (mark it complete). The parenthetical "(mark it complete)" removes ambiguity about what 'progress to done' means. It does not explicitly distinguish itself from the sibling accelo_progress_task_to_start, though the 'done' in the name carries that distinction.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus accelo_progress_task_to_start, accelo_update_task, or the generic accelo_run_progression sibling. The description offers no preconditions, no mention of irreversibility, and no alternative-routing advice.

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

Deploy Server

Other Tools