DiagramZu

update_page

Instructions

Update a Markdown page. EXACTLY ONE body mode, and edits is the one to reach for: each edit replaces an oldText that must appear exactly once in the page, so a change to one paragraph never sends — or silently reverts — the rest of the document. If somebody else edits the page first, YOUR edits are re-applied on top of THEIR text, and the call is refused outright if they changed the very span you are editing. The other mode is baseRevision plus body, which replaces the whole document and needs the revision get_page reported. Changing only metadata (title, folderId, lang) needs neither. Returns the page's new revision and its URL in the app, which only members of this workspace can open. To let somebody outside the workspace read it, a person in the workspace opens the page in DiagramZu and uses its Share button, which mints a public read-only link.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Page UUID
`body`	No	A complete replacement body (≤100,000 chars). Needs `baseRevision`. Prefer `edits` unless you are genuinely rewriting the whole document.
`lang`	No	Change the page's language tag — en, ja, zh-TW, pt-BR. Letters and hyphens only.
`edits`	No	Targeted replacements, applied in order. Each `oldText` must match exactly once in the page as it then stands — zero or several matches refuses the whole call and writes nothing, naming the edit that failed. Do not pass `baseRevision` with this: the server's revision is read and re-read for you.
`space`	No	Which workspace to act in: its id, its slug, or its exact name (case-insensitive). Omit to use this token's default workspace. Call list_spaces to see what this token can reach. A name that matches more than one workspace is refused — pass the id or slug instead.
`title`	No	Rename the page (≤200 chars). Ignored while the body carries front-matter `title` or a leading `#` heading — rename by editing the heading instead.
`folderId`	No	Move the page into this folder (UUID). Use list_folders to look one up.
`baseRevision`	No	The revision the replacement body is based on, from get_page. Required with `body`, forbidden with `edits`. If the page moved on since, the write is refused rather than applied on top.
`versionLabel`	No	Optional label for that snapshot (max 80 chars).
`createVersion`	No	If true, take a named snapshot of the page as it is now BEFORE applying the change, so a human can get the previous text back. Use it when you are rewriting substantially.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.0.8Oct 13, 2026

TDQS

A4.6/5.0

Behavior5/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 so unusually well: it discloses concurrent-edit semantics (your edits re-apply on top of theirs), the refusal condition (they changed the exact span), whole-call atomicity on a failed match, required/forbidden parameter pairings, the return values, and the access constraint that only workspace members can open the URL.

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-loads the most important routing decision (use `edits`) and keeps sentences dense with real information. The closing sentences about sharing are peripheral to invoking the tool correctly, which is the only thing keeping this from a 5.

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 10-parameter mutation tool with no output schema and no annotations, the description covers the missing pieces: it explains the return value (new revision and URL) and the concurrency/refusal model. Nothing an agent needs to call it correctly appears to be absent.

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?

Schema description coverage is 100% and the per-parameter descriptions are already detailed (baseRevision required with body/forbidden with edits, title ignored under front-matter, space name ambiguity). The prose largely restates those relationships, so baseline 3 is appropriate.

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?

States a specific verb and resource ('Update a Markdown page') and immediately distinguishes the two body modes, which is the central decision an agent must make. It is clearly separable from create_page, get_page and update_diagram in the sibling list.

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 says there is EXACTLY ONE body mode, names `edits` as the one to reach for, and gives the condition that selects the alternative (`baseRevision` + `body` for a whole-document rewrite). It also states that metadata-only changes need neither mode, and points at get_page/list_spaces/list_folders for prerequisites.

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

update_page

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools