Skip to main content
Glama
anaknegeri

agent-session

by anaknegeri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

task.update

Idempotent

Change a task's title or status by ID, log a task-updated event, and return the updated task; omitted fields stay unchanged and an auto-checkpoint may be written.

Instructions

Change a task's title and/or status by ID and log a task.updated event; an omitted field stays as it is. Returns the updated task and may write an auto-checkpoint. Errors on an unknown ID or an invalid status. For the current task without its ID, context.update with task_title or task_status does the same.

Input Schema

NameRequiredDescriptionDefault
titleNoNew title; omit to keep the current one
statusNoin_progress|completed|blocked|cancelled; omit to keep the current one
task_idYesID of the task to change, from task.get or task.create

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.9
    • changedInput schema / properties / status / description
      Previous value: -"in_progress|completed|blocked|cancelled"New value: +"in_progress|completed|blocked|cancelled; omit to keep the current one"
    • changedInput schema / properties / task_id / description
      Previous value: -"Task ID"New value: +"ID of the task to change, from task.get or task.create"
    • changedInput schema / properties / title / description
      Previous value: -"New title"New value: +"New title; omit to keep the current one"
  2. First observedv0.1.8

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only supply idempotentHint=true, so the description carries the rest and does so: it discloses the task.updated event write, the auto-checkpoint side effect, the partial-update semantics ('an omitted field stays as it is'), the return value, and the two error cases. This is well beyond what the annotation states and consistent with it.

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?

Two compact sentences, verb and resource front-loaded, with the alternative-path guidance at the end where it is least needed for first-pass comprehension. No filler clauses.

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?

For a 3-parameter mutation with no output schema, the description covers the mutation scope, partial-update behavior, return value, side effects, and failure modes. An agent has everything required to invoke it correctly and anticipate the results.

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 100% and each property already documents its meaning, including the omit-to-keep behavior. The description's 'an omitted field stays as it is' restates rather than extends the schema, and it adds no format guidance for title or status. Baseline 3 for a fully documented 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?

States a specific verb and resource ('Change a task's title and/or status by ID') plus the side effect ('log a task.updated event'). It also explicitly distinguishes itself from the sibling context.update for the current-task case, so an agent can choose without opening either schema.

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?

Names the alternative path explicitly: when the target is the current task and no ID is available, use context.update with task_title or task_status. It also states failure conditions (unknown ID, invalid status), leaving nothing to inference about when the call will succeed.

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