Skip to main content
Glama

edit_org_doc

Change part of a document, leaving the rest untouched. Refuses rather than guessing: if the text you are replacing is missing, appears more than once without replace_all, the edit would remove the frontmatter block or leave it unparseable, or the document moved since expected_commit, nothing is written and you are told what is there now. If another writer commits between this call's read and its write, the edit is REFUSED rather than applied on top of theirs — re-read and re-apply. The confirmation carries a console link to the document you changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeNothe 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.
shareNothe share id, when this location was shared with you from another workspace — list_org_folders prints it. Omit for your own folders.
tokenNoBearer token identifying the principal. Usually omitted — supplied by the transport (HTTP Authorization header or the server's AGENTLEFS_TOKEN env). Only pass this to override.
locationNofull 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.
new_stringYeswhat to put in its place
old_stringYesexact text to replace — must appear in the current body
replace_allNoreplace every occurrence (default: refuse if more than one)
expected_commitNothe document head you read at (read_org_doc prints it). Refuses if that document has moved since.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations at all, the description carries the full burden, and it delivers extensively: refusal-over-guessing, five concrete refusal conditions, optimistic-concurrency refusal, recovery advice, and the console link in the confirmation. This is exemplary disclosure of failure behavior for a mutation tool.

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 description is front-loaded with purpose and every sentence earns its place, covering purpose, refusal conditions, concurrency, and output in roughly 85 words. The second sentence is a dense run-on listing five refusal triggers, which slightly hurts readability.

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 complex 8-parameter mutation tool with no annotations and no output schema, the description covers the essential ground: scope, failure modes, concurrency behavior, remediation, and what the confirmation contains. It omits permission/authorization context, but the schema's token parameter partially covers that.

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% and the schema itself documents parameters well, giving baseline 3. The description adds genuine value by explaining the concurrency enforcement behind expected_commit and the multi-occurrence failure mode that motivates replace_all, going beyond the schema's one-line 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?

"Change part of a document, leaving the rest untouched" names a specific verb and resource and the scope qualifier distinguishes it from the whole-document write_org_doc sibling. The front-loaded purpose makes the tool's role unambiguous even before reading the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description gives clear behavioral rules (pass replace_all for repeated text, re-read and re-apply on stale expected_commit) but never explicitly says when to prefer this over write_org_doc or delete_org_doc. Usage context is implied rather than stated, with no exclusions or alternative routing.

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