Skip to main content
Glama

context.update

Set a single session field to update the current task, rename the session, or write a checkpoint with the next action for AI coding agents.

Instructions

Set one session field. task_title and task_status change the current task (errors when there is none); session_title renames the session; next_action writes a new checkpoint carrying that next action. Returns the affected task, session or checkpoint. To change a task by ID use task.update; to set next_action together with an event or decision use session.record.

Input Schema

NameRequiredDescriptionDefault
fieldYestask_title|task_status|next_action|session_title
valueYesNew value; for task_status one of in_progress, completed, blocked, cancelled

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.9
    • changedInput schema / properties / value / description
      Previous value: -"New value"New value: +"New value; for task_status one of in_progress, completed, blocked, cancelled"
  2. First observedv0.1.8

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses side effects ("next_action writes a new checkpoint carrying that next action"), error behavior when no task exists, and what is returned ("the affected task, session or checkpoint"). It stops short of covering permission requirements or what happens on an invalid field/value.

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?

Front-loaded with the core action, then field semantics, then routing alternatives; every clause carries information. It is dense to the point of being a run-on in the middle, but nothing is wasted.

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?

For a 2-parameter, non-destructive-by-default tool with no output schema, the description covers purpose, field meanings, failure mode, return value, and alternatives — enough to call it correctly. Only permission/validation specifics and partial-update semantics are unaddressed.

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 baseline is 3, but the description adds real meaning beyond the enum list: it explains what each field value does and which values require an existing task. The allowed task_status values remain only in 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?

States a specific verb and resource ("Set one session field") and then enumerates each allowed field with its distinct effect, so an agent knows exactly what the tool mutates. It also names the sibling tools it is not (task.update, session.record), distinguishing it without opening a 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?

Explicitly routes the agent: "To change a task by ID use task.update; to set next_action together with an event or decision use session.record." It also states a precondition failure mode ("errors when there is none" for task_title/task_status), giving when-to-use and when-not in one paragraph.

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