Skip to main content
Glama

Update handoff note

update_handoff_note
Destructive

Replace the handoff note on the Work being implemented, so another session can continue it: what is done, what remains, files touched, and whether changes are uncommitted. begin_work returns it to whoever resumes the Work; finish_work clears it. Pass an empty note to clear it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYesThe Handoff note text.
workIdYesWork being implemented.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true; the description is consistent with that, reinforcing 'Replace'. It adds genuinely useful behavior beyond the annotations: the note's expected content categories and that an empty string clears it, plus the interaction with begin_work/finish_work.

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 verb+resource, then purpose, then related-tool behavior. Three compact sentences; the only mild redundancy is restating the clearing behavior twice (empty note, finish_work).

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?

No output schema, but the annotations carry the safety profile and the schema carries parameter constraints (maxLength, required). The description fills the remaining gaps: note content and clearing semantics. Adequate for a two-parameter mutation tool.

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: it defines what the note should contain (done, remaining, files touched, uncommitted status) and the empty-note-as-clear semantics – behavior not captured by the schema's terse parameter 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?

States a specific verb (Replace) and resource (the handoff note on the Work being implemented), plus the purpose (so another session can continue it). An agent can distinguish this from update_work or finish_work 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 Guidelines4/5

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

Explains the use context (continuation across sessions) and names related tools: begin_work returns the note, finish_work clears it, and passing an empty note clears it directly. No explicit 'when not to use' exclusions, so it falls just short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources