Skip to main content
Glama
entire-vc

EVC Mesh MCP Server

by entire-vc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

update_doc

DestructiveIdempotent

Edit documents by replacing the body with version-checked writes that reject concurrent changes, or append text safely without reading first. Use append for reports, decisions, and logs.

Instructions

Edit a document. Replacing the body REQUIRES base_version — the version you got from get_doc — and the write is refused with a 409 if anyone changed the document since, so you can never silently overwrite someone else's edit. To add to the end, pass append instead: it needs no base_version, cannot conflict, and does not make you read the document first. Prefer append for reports, decisions and logs. The doc argument accepts an old path or a bare slug too; the reply then carries moved_to (the current path). Note the two different 409s: a stale base_version, and an ambiguous bare slug (repeat with the full path or UUID).

Input Schema

NameRequiredDescriptionDefault
docYesDocument UUID, or a slug path like 'architecture/adr/adr-004' (a path also needs project_id). A path survives the document being moved: the old path still resolves, and so does a bare slug ('adr-004') when exactly one live document in the project has it. When the reference was not the live path, the reply carries moved_to — the document's current path; use that from now on. A bare slug shared by several documents is a 409 ('Ambiguous document slug') listing the full paths: pick one and repeat the call with the full path or the UUID. The UUID never changes.
bodyNoReplacement markdown for the WHOLE document. Requires base_version.
titleNoNew title.
appendNoText to add to the END of the document. No base_version needed. Cannot be combined with body.
positionNoNew sort position among siblings.
parent_idNoNew parent document UUID.
project_idNoProject UUID. Required only when doc is a slug path.
base_versionNoThe version you read from get_doc. Required for any write other than append.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already cover the safety profile (destructive=true, idempotent=true) and the description adds real value: optimistic-concurrency semantics, the two distinct 409 causes, and the moved_to reply hint. However, it does not disclose permission/auth requirements, and the appended-text behavior arguably sits awkwardly with idempotentHint=true, so it does not fully exhaust the behavioral space.

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 highest-stakes rule (base_version + 409 guard) before the append alternative and the ambiguity footnote. It is dense but a little long, and the closing 'two different 409s' sentence restates material already introduced earlier in the text.

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 an 8-parameter mutation tool with no output schema, the description covers conflict handling, mode exclusivity, reference resolution and the relevant reply field (moved_to) that an agent needs to react correctly. Nothing essential to calling it safely is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds meaning beyond the schema: doc accepts an old path or bare slug, project_id is conditional, base_version is required for all non-append writes, and append/body are mutually exclusive. It omits any mention of title, position, or parent_id, so it stays just above baseline.

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+resource ('Edit a document') and immediately distinguishes the two edit modes (body replacement vs append). It is clearly separable from siblings like get_doc, create_doc, and comment_doc without opening any 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?

Explicitly states when to use each mode: body requires base_version, append needs none and 'does not make you read the document first', plus a direct recommendation ('Prefer append for reports, decisions and logs'). It also prescribes the follow-up action after a 409 (repeat with full path or UUID).

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