Skip to main content
Glama

Edit Document

patch-document
Destructive

Applies one or more edit operations, in order, to an existing ODocs.co document; people who have it open see each edit in real time. Returns { id, version, ok }, plus a warning when the author name was changed. Two kinds of operation: text-anchored (insert-after / insert-before / replace-text / delete-text), where the server finds the given exact text and resolves it to a position, so no character offsets are needed; and position-based (insert / delete / replace) at an exact character offset. expectedVersion enables conflict detection: if the document changed since that version, the patch is refused with 409 and nothing is applied. Operations are not atomic: they apply one at a time to the live document and are not rolled back. When one fails, the operations before it stay applied (and visible), and the 400 body reports appliedOps: N, the number applied; sending the whole batch again applies those a second time. On an anchor failure the body can also carry nearestMatchOffset and nearestMatchSnippet; they appear only when the anchor matches the document except for whitespace (usually a different newline count), so their absence means the text is not in the document. Anchor matching is exact. LINE BREAKS: each "\n" is a paragraph break, except inside a code block (an insert strictly inside one, or a replace within one, stays in it; at its very start / end a "\n" is a paragraph break). A delete or replace across one JOINS the paragraphs (the first keeps its formatting, except that a range starting at a line start keeps the later line's paragraph); a replace with as many lines as it spans rewrites each line in place, and deleting a whole line with its "\n" joins nothing; identical whole lines at the start / end of find and replace are left out ("2\naf" → "2\nA\nB\naf" only inserts "A\nB\n"). After a join the document can differ from what a position computed before it assumed: list items after a plain paragraph can't join it (one "\n" stays), and a code block's lines joined into a paragraph become hard breaks the plain text doesn't show. While someone has the document open, a patch that would join paragraphs is refused as a whole (409 join_blocked_live_editors, nothing applied); edits within a line and rewrites of whole lines are not affected.

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": {
      "id": "<id>",
      "operations": "<operations>"
    },
    "name": "patch-document"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesDocument ID
authorNoName shown on your edits and comments (e.g. "Claude via Greg"), with a robot mark as an agent. Invisible and text-direction characters are removed, line breaks and control characters become spaces, and it is cut to 256 characters. A name that resembles ODocs.co or Octaria (including look-alike spellings) is shown as "Agent (Anonymous)". When any of that happens the result has a `warning` field saying what changed.
operationsYesOperations, applied in order. Text-anchored ops (insert-after / insert-before / replace-text / delete-text) name exact text that the server resolves to a position; position-based ops (insert / delete / replace) take character offsets.
expectedVersionNoThe document version from your last read. If the document has changed since, the patch is refused with 409 and nothing is applied (conflict detection).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The annotations only say readOnlyHint=false, destructiveHint=true, openWorldHint=true. The description adds far more: operations are not atomic, not rolled back, partial application is reported via appliedOps: N, resending the batch double-applies, 409 on version conflict with nothing applied, nearestMatchOffset/nearestMatchSnippet appear only on whitespace-only anchor mismatch, and live-editor joins are blocked wholesale. This is exactly the extra behavioral context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentences are well front-loaded and the substantive content mostly earns its place because these are genuine edge cases. However, the LINE BREAKS block is a dense, unbroken wall of prose with nested caveats (joins, hard breaks, list items, whole-line rewrites) that would be far more usable as structured bullets, making it harder than necessary to extract the operative rules.

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 destructive, non-atomic mutation tool with no output schema, the description covers what an agent needs: return shape { id, version, ok } plus warning, version-conflict semantics, partial-failure recovery, and the line-break/join behavior that determines whether a patch is safe. Nothing material is missing for correct invocation.

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 real meaning: it clarifies that anchors are matched exactly and resolved server-side (so occurrences and offsets behave differently than raw indices), that each '\n' is a paragraph break with code-block exceptions, and that identical leading/trailing lines are trimmed from replace-text. Those are interpretations of the operation parameters that the schema does not express.

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?

Opens with a specific verb and resource: 'Applies one or more edit operations, in order, to an existing ODocs.co document.' It immediately distinguishes itself from create-document and get-document by scoping to editing an existing document, and names the two operation families so an agent knows what kind of work this tool does.

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?

It gives strong within-tool guidance: choose text-anchored ops when you can quote exact text (no offsets needed) versus position-based ops at exact character offsets, and use expectedVersion for conflict detection. It also states the when-not conditions for live-editor joining (409 join_blocked_live_editors). What it lacks is any routing to sibling tools, so it stops 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