Skip to main content
Glama
Sign In
ArchScript MCP

ArchScript MCP

by schlummer13
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Edit a document

edit_document

Applies ordered structured edit operations to a software architecture document in one undoable step, supporting element, relation, container, tag, and property changes.

Instructions

Applies structured edit operations in order (one undoable step). Each operation is an object with "op" and its fields: add_element {kind, name, container?} · add_relation {from, to, label?, bidirectional?} · set_property {element, key, value|null} · rename {element, name} · change_id {element, id} · change_kind {element, kind} · set_tags {element, tags[]} · move_to_container {element, container|null} · delete_element {element} · set_relation_label {relation, label|null} · set_relation_property {relation, key, value|null} · set_relation_direction {relation, direction: forward|reverse|both} · delete_relation {relation} · add_container {kind, name, container?} · rename_container {container, name} · delete_container {container} (keeps contents) · set_container_property {container, key, value|null} · set_container_color {container, color|null}. Elements are referenced by id, relations by index (see get_document), containers by key like "cluster:Prod/server:app-01".

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": {
      "operations": "<operations>"
    },
    "name": "edit_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
documentNoDocument id (e.g. doc1), file name or project name. Omit for the frontmost document.
operationsYesEdit operations, applied in order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does deliver real behavioral facts: operations apply in order, the whole call is a single undoable step, and relations are addressed by index while containers use "kind:name" keys. What it omits is critical for a mutation tool — whether a failing operation rolls back the whole batch or leaves partial changes, whether ops are validated up front, and what permissions or side effects exist.

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 core behavior and the atomicity guarantee are front-loaded in the first clause, and the op list is dense but every entry adds distinct information. The one waste is the trailing reference-resolution sentence, which is useful but could be placed more prominently than after a long enumeration.

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 schema-less-of-detail mutation tool with no annotations and no output schema, the description covers the operation vocabulary well but leaves return value (does it return the edited document, ids, or nothing?) and failure/rollback semantics unexplained. Those omissions matter for correct agent invocation of a batch-edit endpoint.

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%, but that is misleading here because `operations.items` is declared as a bare object with no properties; the description is the only place the 18 operation variants and their field names (including `?`-marked optional fields) are defined, which is substantial value beyond the schema. It stops short of specifying per-op required-field rules or a concrete example operation object, so it is strong rather than complete.

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?

"Applies structured edit operations in order (one undoable step)" states a specific verb and resource, and the subsequent op enumeration makes the mutation surface concrete. An agent can immediately distinguish this from read-side siblings like get_document or creation via create_document.

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?

Usage context is implied by the op catalog and by the pointer "see get_document" for resolving ids and relation indices, which effectively signals a read-then-edit workflow. However, there is no explicit when-to-use/when-not guidance versus create_document or set_document_source, and no stated prerequisites such as needing ids from a prior read.

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

Deploy Server

Other Tools