Rapier - Markdown Editor & Art

Edit Rapier

edit

Destructive

Use this to change a document the person is working on in Rapier: the change shows at once, marked as yours, and undoes alone. 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

Name	Required	Description
`note`	No
`agent`	No	Your display name on acts; never grants authority.
`label`	No	Short description of this edit in history.
`fields`	No	Note fields, with note and without changes.
`changes`	No
`turn_id`	No	Groups acts for undo {turn_id}.
`document`	Yes
`filename`	No
`revision`	Yes	From your latest read or open; a Note's is its sha256.
`operation_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Well beyond the annotations, it discloses that edits apply atomically as a single undoable act, appear immediately and are attributed to the agent, and that a revision conflict returns current context requiring a re-decision. It also warns that painting requires an open editor plus operation_id. It does not cover failure modes for oversized changes or what a successful 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?

Purpose is front-loaded and every sentence carries information, but the phrasing is packed and elliptical ("a rapier-draw diagram stays live for the person, who drags its boxes and retypes its labels"), and several clauses are crammed into single semicolon-chained sentences that slow parsing.

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 destructive, non-idempotent, 10-parameter tool with nested schemas and no output schema, the description covers the critical risks: atomicity, undoability, conflict/revision semantics, and the special editor requirement for painting. Gaps remain around the fields object, turn_id grouping, and the general return value, but the essential call-correctly information is present.

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, the description usefully explains revision (from latest read/open, or sha256 for a Note), operation_id (painting), filename (rename), and the shape of changes (old/new literal text, whole-document replacement). However, label, turn_id, fields, and document are not clarified, so half the parameters remain opaque.

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 opening sentence names a specific verb and resource ("change a document the person is working on in Rapier") and then enumerates the three concrete modes: exact-text changes, rename via filename, and Note-field updates via note. An agent can distinguish this from open/read/undo without opening 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 Guidelines4/5

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

It establishes the context of use and the preconditions ("a revision from your latest read or open", "painting needs an open editor"), which routes the agent to read/open first. It stops short of explicitly naming a sibling alternative or stating when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Rapier - Markdown Editor & Art tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.