Skip to main content
Glama

Change a thread's title or properties

update_thread
DestructiveIdempotent

Change a Thread's title, status or description; only the properties you send change (move_thread, archive_thread and trash_thread do the rest). Needs Can edit and organize. expected_revision is not compared: the last change to each property wins. A Thread in Trash answers entity_deleted, an archived one thread_archived (unarchive_thread first). Answers a receipt with the new revision, thread_status (a status deleted meanwhile lands on its replacement) and url; the same operation_id answers it again instead of changing twice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation_id": "<operation_id>",
      "thread_id": "<thread_id>",
      "expected_revision": "<expected_revision>",
      "properties": "<properties>"
    },
    "name": "update_thread"
  }
}

Input Schema

NameRequiredDescriptionDefault
thread_idYesA Thread's id, from list_threads, search or a read.
propertiesYesOnly what changes: title (1–200 characters); status (an id from list_statuses); description (plain text under the title, up to 500 characters, line breaks allowed; "" clears it). An older link ({"href": "https://…", "label": "…" or null}) is added to the description as its last line.
operation_idYesA new UUID for each write. After a lost answer, send the identical call with the same one, or check get_operation before writing again.
expected_revisionYesIts revision from list_threads, get_thread, list_folders or get_note (not a content_revision); not compared.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / expected_revision / description
      Previous value: -"The revision you last read for it."New value: +"Its revision from list_threads, get_thread, list_folders or get_note (not a content_revision); not compared."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=true, so the description's job is to add context — and it does: it names the required permission ('Can edit and organize'), discloses the lost-update concurrency model ('expected_revision is not compared: the last change to each property wins'), lists specific error outcomes (entity_deleted, thread_archived), and explains operation_id replay. It stops short of describing partial-failure behavior or what a cleared status does beyond the one parenthetical.

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 mutation scope and the sibling routing are front-loaded and every clause carries information; nothing is filler. It is dense to the point of being run-on, with three parentheticals stacked in one paragraph, which costs a little readability.

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 mutation tool with no output schema and a nested properties object, the description covers the permission requirement, concurrency model, error paths, idempotency, and the shape of the returned receipt (new revision, thread_status, url). Nothing an agent needs in order to call it safely 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 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: that expected_revision is effectively advisory, that a status deleted meanwhile resolves to its replacement, and that replaying an operation_id returns the receipt instead of re-applying. Those are semantics beyond field-level docs, though the per-field details (length limits, link handling) remain schema-only.

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 plus the exact fields it touches ('Change a Thread's title, status or description') and immediately names the siblings that handle the other operations (move_thread, archive_thread, trash_thread). An agent can distinguish this from adjacent tools without opening any 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?

It says when this tool applies ('only the properties you send change'), routes the other cases to the named alternatives, and adds a prerequisite for a specific state ('an archived one thread_archived (unarchive_thread first)'). Explicit when-to-use, when-not, and prerequisite in two sentences.

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.