Skip to main content
Glama

GEML — a plain-text document format built to be edited in place, one section at a time

Replace one block

geml_set
DestructiveIdempotent

Replace ONE block and leave every other byte untouched — prefer this to rewriting a file. For content that does not exist yet use geml_add; to remove a block, geml_delete. The replacement is validated before it is written: if it would break the document, nothing is written and the diagnostics come back — fix the body rather than resending it. Removing content is not refused: if the replacement drops blocks, the write goes through and the result names each one, so check it after shortening a section; geml_revert puts one back. part replaces the whole block (default), its head line, a section's intro, or its body. In a Markdown file a heading's anchor is its text, as on GitHub: new heading text gives the heading a new address, and the document's links to the old one follow in the same write. GEML content written over a Markdown heading or prose is converted to Markdown, as in geml_add; a GEML block already in the file stays GEML. An id that matches no block, or several, is refused. Returns {ok, file, diagnostics, revision}, with notes when the write did something to say out loud (a block it dropped, an address it changed); a refusal is ok: false with a hint, and the file is unchanged. This server is STATELESS: the document travels in source and a write comes back as document for you to save; it holds no other documents, so a cross-document reference such as [[other.geml#id]] cannot be resolved here and is reported as unresolvable-document.

Input Schema

NameRequiredDescriptionDefault
idYesWhich block to replace: an id (with or without `#`), a `@<hex>` content address from `geml_list` for a block with no id, or `L27`/`L27-58` for the smallest block holding those lines. Must match exactly one block
bodyYesThe replacement text
nameNoThe document's file name, e.g. notes/spec.geml or README.md — it decides whether the text is read as GEML or as Markdown (a `.md` name), and it is how the document is called in messages. Default: document.geml.
partNoWhat to replace (default: whole). `intro` replaces a section's opening — everything under the heading up to its first subheading — and leaves every subsection byte-identical, which is what makes a read-edit-write cycle on a long section safe. An empty intro (a subheading follows the heading immediately) is written into, so this also adds an opening where there was none.
sourceYesThe document's full text. This server keeps no files: what you send is the document.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, but the description adds substantial behavioral context beyond them: validation happens before the write and a breaking replacement writes nothing, removals are NOT refused (dropped blocks are named in the result), the return shape {ok, file, diagnostics, revision} with optional notes, refusal semantics (ok:false, hint, file unchanged), and the stateless-server constraint that makes [[other.geml#id]] unresolvable. No contradiction with the mutation/destructive annotations.

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 action and sibling routing before the details, so an agent gets the essentials in the first sentence. It is dense and long (~10 sentences), and a few clauses (e.g. the Markdown anchor-and-links aside) could be tightened, but each sentence carries distinct operational information rather than filler.

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 5-param mutation tool with no output schema, the description supplies what's missing: the return payload fields, the refusal shape, the notes mechanism, and the statelessness model that governs how `source`/`document` travel. Nothing an agent needs to call it correctly appears to be omitted.

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 already 100%, so the baseline is 3, but the description meaningfully extends it: it enumerates what `part` targets (whole/head/intro/body) and explains the safety property of `intro` (subsections stay byte-identical), plus the refuse-if-not-exactly-one rule for `id` and how `name` selects GEML vs Markdown parsing. This goes beyond restingating the schema text.

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 first clause states a specific verb and resource (replace ONE block) plus scope (leave every other byte untouched), and immediately differentiates from siblings by naming geml_add for new content and geml_delete for removal. An agent can distinguish this from every other geml_* tool 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 Guidelines5/5

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

Explicit routing: 'prefer this to rewriting a file', use geml_add for nonexistent content, geml_delete to remove, geml_revert to restore a dropped block. It also gives an actionable failure policy — 'fix the body rather than resending it' — which is precisely the guidance an agent needs after a rejected write.

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.