Skip to main content
Glama

Change a document

doc_update
Destructive

Change a document or directory that exists. Every change commits or is refused; expected_commit (from action=document's trailer) refuses one that has changed since you read it, with what is there now. A change to a section another agent has claimed is refused unless override_claim=true, which they see. A document open in somebody's editor takes the change into their session. Actions — edit: replace old_string with new_string (replace_all for every occurrence), or add append at the end of the document or of a section; refused, with the current text, if old_string is missing or ambiguous, the frontmatter would break, or another writer committed first. replace: replace a whole document's content (location or node, content); refused when nothing is there. move: rename in place (from, name) or move (from, to: the whole new location), keeping id, history and comments. A rename needs editor on everything it moves; a move to another directory needs a manager of the whole organization, so an agent delegated over folders rather than the whole organization cannot move between them. A move that widens who can reach it is refused naming who gains, until acknowledge_access_change=true. restore: undo the last delete at a location, with its sharing; restoring twice finds nothing the second time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNomove: the whole new location including the name, e.g. wiki/archive/attention.md; a folder's link moves it into that folder. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
fromNomove: the document or directory's whole location, e.g. wiki/attention.md. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
nameNomove: the new last segment, to rename in place, e.g. self-attention.md (no slash)
nodeNoedit, replace: the document's id, as returned beside its location — survives a rename or a move, so a citation written into a stored document keeps pointing at the right thing. Give this OR location, never both. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
actionYeswhat to do; each action takes the arguments its line names
appendNoedit: text to add at the end of the document, or of `section`, instead of replacing anything
contentNoreplace: the whole document. Set metadata with YAML frontmatter at the top of `content`: `type` (one of: meeting-notes, playbook, spec, brand-asset, web-clip, contract, misc — anything else becomes misc), `title`, `summary`, and `tags` as a list. `tags` is the write-side spelling of what the listing tools call `label`. `status` takes `active` or `inactive` and is not a label: `inactive` retires a document — it stays in the folder and stays openable in the console, but agents stop retrieving it. Omit it unless you mean to retire something. `aliases` (a list, or one name) are other names search how=titles finds the document by; a [[link]] still needs its file name or title. Any other key you write (`sources`, …) is kept as written and comes back on read; key order may change. A block that does not parse as YAML is refused, naming the line, and nothing is written: quote a value that contains ": " (summary: "a: b").
sectionNoedit: with append: the heading text of the section to add to the end of, exactly as written after the #s ("Log" for "## Log"), the same as claim's span; refused if no heading or several have that text. Omit for the end of the document
locationNoedit, replace: full path from the workspace root, e.g. "handbook/vendor/acme.md". Give this OR node. A path is what a person reads; a node is what survives somebody reorganizing. · restore: full path from the workspace root, e.g. "handbook/vendor/acme.md" (as printed by browse action=documents or search)
new_stringNoedit: what to put in its place
old_stringNoedit: exact text to replace — must appear in the current body (with new_string; not with append)
replace_allNoedit: replace every occurrence (default: refuse if more than one)
override_claimNoedit: write even though another agent has CLAIMED the section you are changing. Logged, and they will see it. Default: refuse and name the holder. · replace: write even though another agent has CLAIMED this document. Logged, and they will see it. Default: refuse and name the holder.
expected_commitNoedit: the document head you read at (read action=document prints it; any lowercase prefix of at least 7 hex characters). Refuses if that document has changed since. · replace: the document head you read at (read action=document prints it; any lowercase prefix of at least 7 hex characters). Refuses if that document has changed since. Omit to replace whatever is there now.
idempotency_keyNoAny unique string you choose for this write, e.g. a UUID. If you retry the call with the same key and the same arguments, the first answer is returned and nothing is done twice. Reusing a key for a different request is refused. Keys are kept 24 hours.
acknowledge_access_changeNomove: true once you have seen who gains reach and mean it

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
fromNo
textNothe answer as prose, for an action that answers in prose
actionYesthe action that answered
commitNothe head of the folder the move landed in, not the moved document's own commit, so not an expected_commit (read the document for that); null for a top-level folder's rename, which writes no commit
changedNothe documents that moved, a directory's documents included, the first 25 by path; directories themselves are not listed
appendedNoappend only: what this call added
changed_totalNohow many documents moved, whether or not changed lists them all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With destructiveHint=true and idempotentHint=false already declared, the description goes well beyond the annotations: atomicity ('Every change commits or is refused'), the claim-conflict protocol and its visibility to the other agent, the editor-session takeover behavior, permission tiers required for rename vs cross-directory move, and the access-widening refusal. These are exactly the side effects an agent must anticipate before a destructive write.

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 one-line purpose and the commit guarantee before diving into per-action detail, and every sentence carries distinct information. It is a dense wall of text for a 16-parameter tool, but almost nothing is restated from the schema or annotations.

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 four-action, 16-parameter mutation tool this covers purpose, prerequisites, refusals, concurrency, claim interaction, and permission requirements, and an output schema exists so return values need no explanation. Nothing an agent needs to call it correctly 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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot: which parameter combinations belong to which action (from+name vs from+to for move; old_string/new_string vs append for edit; replace_all for every occurrence) and the interaction between expected_commit and concurrent writers.

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 with the key scoping constraint up front: 'Change a document or directory that exists', which cleanly separates it from doc_create and doc_delete in the sibling set. It then enumerates the four actions (edit, replace, move, restore) with their verbs, so an agent knows exactly what surface it is invoking.

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?

Gives explicit when-to-use conditions per action and names the alternatives for each branch (override_claim when a section is claimed, acknowledge_access_change when a move widens reach, expected_commit when you want optimistic concurrency). It never explicitly routes to sibling tools such as doc_create or coordination_write, but within the tool's own action space the guidance is unusually complete.

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