Skip to main content
Glama
ni-c

wikijs-mcp

by ni-c
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create a page

create_page

Create a new Wiki.js page by supplying a unique path, title, content, and editor format. Select the editor to define how the content is stored, such as markdown or HTML.

Instructions

Creates a page. The path must not already exist in this locale — Wiki.js answers PageDuplicateCreate otherwise, and update_page is what changes an existing one. The editor decides how content is interpreted, so markdown source needs editor="markdown".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPage 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.)
tagsNo
titleYesPage 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.
contentYesFull page body, in the page’s content format.
is_privateNo
descriptionNoShort page description, shown in listings and search results.
is_publishedNoPublish immediately (default true). False creates a draft.

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. 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"
+}
  2. First observedv0.1.2

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already mark this as a non-read-only, non-idempotent operation. The description adds useful behavioral context beyond those flags: duplicate creation returns PageDuplicateCreate, and the editor value determines how content is interpreted. This helps the agent predict failure modes and format requirements, though it does not cover all side effects.

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?

Two sentences convey the essential creation semantics, the duplicate-path failure mode, the alternative tool, and a critical editor/content relationship. There is no filler, and the most important operational constraint is front-loaded.

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?

Despite having 9 parameters, the schema is rich and an output schema exists, so the description need not repeat parameter documentation. It supplies the missing operational knowledge: path uniqueness per locale, routing to update_page, and editor/content coupling. An agent has enough context to invoke create_page correctly.

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 description coverage is 78%, so the schema does most of the work. The description adds meaningful value on top by explaining that the editor parameter controls content interpretation and that markdown source specifically requires editor="markdown", which is not obvious from the enum alone.

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 description states a specific action and resource: 'Creates a page.' It explicitly differentiates from update_page by noting that existing paths trigger PageDuplicateCreate and require update_page, so an agent can distinguish this tool from its closest sibling 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 Guidelines5/5

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

The description gives explicit guidance: use this only when the path does not already exist in the locale, and use update_page for existing pages. It also clarifies that markdown content requires editor="markdown", which is a concrete selection criterion.

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