Skip to main content
Glama
ni-c

wikijs-mcp

by ni-c
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update a page

update_page

Update a wiki page by replacing its body or applying exact find-and-replace edits; it detects concurrent changes and refuses to overwrite unless forced.

Instructions

Changes a page. Pass content to replace the whole body, or edits for surgical find-and-replace — each edit’s old_text must appear exactly once, and an ambiguous or missing match is refused rather than applied to the wrong place. Before writing, this checks whether somebody else changed the page since it was read and refuses to clobber them; pass force=true to overwrite deliberately. Metadata fields can be changed on their own, without touching the text.

That refusal is a normal result and not an error: it explains what to do — read the page again with get_page, redo the change on top of what is now there, and write. Note that render_page also bumps the page’s timestamp, so calling it between your read and your write triggers the same refusal even though nobody else touched anything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoPage path without a leading slash and without the locale prefix, e.g. "docs/setup". A browser URL looks like /en/docs/setup — drop the "en/", it is the locale argument. (Not enforced: "ci/", "db/" and "qa/" are perfectly good first segments that happen to look like locale codes.)
tagsNoReplaces the whole tag list, it is not merged.
editsNoFind-and-replace edits. Mutually exclusive with content.
forceNoWrite even though the page changed since you read it. Overwrites the other person’s edit.
titleNoPage title as shown in the wiki.
editorNoStorage format. "markdown" for markdown source, "ckeditor" for rich-text HTML, "code" for raw HTML, "asciidoc" for AsciiDoc.
localeNoLocale code. Defaults to WIKIJS_LOCALE. The locale is part of a page’s identity.
contentNoReplacement body. Mutually exclusive with edits.
page_idNoNumeric Wiki.js id.
is_privateNo
descriptionNoShort page description, shown in listings and search results.
is_publishedNo
expected_updated_atNoThe updatedAt value you saw when you read this page. Normally unnecessary — a previous get_page in this session is remembered automatically — but it makes the concurrent-edit check work without one.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
truncatedNoPresent only when the answer was shortened to fit the budget.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedInput schema / properties / edits / items / properties / new_text / maxLength
      Added value: +5000000
    • addedInput schema / properties / edits / items / properties / old_text / maxLength
      Added value: +5000000
    • changedInput schema / properties / page_id / maximum
      Previous value: -9007199254740991New value: +2147483647
  2. Changed2 schema fields changedv0.2.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": true,
+  "properties": {
+    "truncated": {
+      "additionalProperties": true,
+      "description": "Present only when the answer was shortened to fit the budget.",
+      "properties": {},
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  3. First observedv0.1.2

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint=false annotation by documenting exact-once matching, refusal on ambiguous/missing matches, the concurrent-edit check, the deliberate-force overwrite path, and the subtle render_page timestamp interaction. This gives an agent the behavioral model needed to anticipate refusals and avoid clobbering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and modes, then layers in concurrency safety and error-handling context. Despite its length, each sentence carries distinct operational value and there is no filler or repetition of the schema.

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 13-parameter mutation tool with no required fields, this description covers the important decision axes: how to target text, how to avoid clobbering, what refusal means, and how to recover. With a rich schema (85% coverage) and an output schema present, remaining field details are already available to the agent.

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 already high (85%) and includes detailed field descriptions, but the description adds selection guidance: content replaces the whole body, edits are surgical, metadata can be changed independently. It reinforces the mutually exclusive relationship and the concurrency parameter (force/expected_updated_at) in plain language.

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 'Changes a page' and immediately distinguishes the two update modes (whole-body content replacement vs. surgical find-and-replace edits), which clearly identifies what the tool does. It also mentions metadata-only changes, giving the agent a precise picture of its scope relative to sibling page tools.

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?

The description explicitly tells when to use content vs. edits, and explains the concurrency refusal and the force=true escape hatch. It names get_page as the recovery path, but it does not explicitly contrast update_page with create_page/move_page/delete_page or state when not to use this tool.

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