Skip to main content
Glama

Rapier - Markdown Editor & Art

Edit Rapier

edit
Destructive

Apply unique exact-text changes atomically as one undoable act (act is its id string), rename with filename, or set Note fields with note. At a moved numeric revision, literal edits apply if untouched since; whole-document replacement needs the current revision. A conflict returns current context; decide afresh. Drawings, painting, Water, comments and HTML objects use fenced text; a rapier-draw diagram stays live for the person, who drags its boxes and retypes its labels in the document; painting needs an open editor and an operation_id, and its result shows the painting.

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": {
      "document": "<document>",
      "revision": "<revision>"
    },
    "name": "edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNo
agentNoYour display name on acts; never grants authority.
labelNoShort description of this edit in history.
fieldsNoNote fields, with note and without changes.
changesNo
turn_idNoGroups acts for undo {turn_id}.
documentYes
filenameNo
revisionYesFrom your latest read or open; a Note's is its sha256.
operation_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / agent / description
      Added value: +"Your display name on acts; never grants authority."
    • addedInput schema / properties / label / description
      Added value: +"Short description of this edit in history."
  2. Added
  3. Removed
  4. Changed5 schema fields changed
    • changedInput schema / properties / fields / additionalProperties
      Previous value: -trueNew value: +false
    • changedInput schema / properties / fields / description
      Previous value: -"Note controls: tags, pinned, archived, trashed, colour, reminder. See rapier://guide."New value: +"Note fields, with note and without changes."
    • addedInput schema / properties / fields / properties
      Added value: +{
      +  "archived": {
      +    "type": "boolean"
      +  },
      +  "colour": {
      +    "enum": [
      +      "",
      +      "red",
      +      "orange",
      +      "yellow",
      +      "green",
      +      "teal",
      +      "blue",
      +      "purple",
      +      "pink",
      +      "brown"
      +    ],
      +    "type": "string"
      +  },
      +  "pinned": {
      +    "type": "boolean"
      +  },
      +  "reminder": {
      +    "description": "App only; {at} in ms.",
      +    "type": [
      +      "object",
      +      "null"
      +    ]
      +  },
      +  "section": {
      +    "maxLength": 48,
      +    "type": "string"
      +  },
      +  "tags": {
      +    "items": {
      +      "maxLength": 128,
      +      "type": "string"
      +    },
      +    "maxItems": 64,
      +    "type": "array"
      +  },
      +  "trashed": {
      +    "type": "boolean"
      +  }
      +}
    • addedInput schema / properties / revision / description
      Added value: +"From your latest read or open; a Note's is its sha256."
    • addedInput schema / properties / turn_id / description
      Added value: +"Groups acts for undo {turn_id}."
  5. Added
  6. Removed
  7. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds substantive context beyond that: edits are atomic and undoable as one act, conflict handling returns current context so the caller can re-decide, and diagram/painting behavior is described (a rapier-draw diagram stays live for the human, painting requires an open editor). It stops short of describing what the success response contains.

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 primary capability is front-loaded in the first clause, which is good, but the prose is one dense semicolon-chained paragraph with awkward embeddings ('(act is its id string)', 'who drags its boxes and retypes its labels in the document'). The sentence about rapier-draw behavior is long relative to its decision value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, nested-object, destructive mutation tool with no output schema, the description covers the main hazards (atomicity, conflicts, revision staleness, painting prerequisites) but leaves several parameters and the return shape unexplained. It is adequate for an expert caller and thin for anyone else.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 50% schema description coverage across 10 parameters, the description does add meaning to the highest-risk ones: revision semantics when the document has moved, filename as the rename trigger, note as the Note-field trigger, and operation_id as a painting prerequisite. However turn_id, agent, and label are left entirely to the schema, and the 'changes' array's three variants (old/new, after/insert, text) are only gestured at rather than mapped.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names three concrete modes (exact-text changes, rename via filename, Note field updates via note) with specific parameter-bound verbs, plus mentions drawing/painting/comment/HTML content. It does not explicitly contrast against siblings like undo, read, or open, and the parenthetical '(act is its id string)' is opaque rather than clarifying.

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?

It gives real preconditions for the painting path ('needs an open editor and an operation_id') and explains revision-dependent behavior ('literal edits apply if untouched since; whole-document replacement needs the current revision'). But it never says when to pick edit over undo, read, or open, leaving mode selection largely implicit to the caller.

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.