Docstar

create_page

Destructive

Creates a new page as the last child of the page given in the path. Pass the collection's rootParentId (invisible root, from List Collections) to create a top-level page (type 1, parent page/module); pass any other page id to create a subpage (type 3). The type is decided by the parent, not the body. New pages start as draft (state 1); passing state 2 publishes immediately (parent must already be published) and returns publicUrl. Requires READ_WRITE permission. To write the page body afterwards use Update Page Content. Body fields:

name (string, required) - Page title (min 1 char). urlName (string, optional) - URL slug (min 3 chars); made unique among siblings. Derived from name if omitted. contents (string, optional) - Legacy initial HTML/text contents column (editor content is stored in doc-rtc; prefer Update Page Content). state (number, optional) - 0 pending, 1 draft (default), 2 approved/published (publishes right away; parent must be published), 3 rejected. meta (object, optional) - Page metadata object (e.g. {"description":"...","tags":["setup"]}); may include editable boolean. sharingMeta (object, optional) - Sharing settings object, e.g. {"editable":true}. pageType (number, optional) - Accepted (1 or 3) but ignored; the type is derived from the parent page. uniqueTabId (string, optional) - Optional browser tab id used only to suppress the realtime socket echo to the calling tab; agents can omit it. POST https://api.docstar.io/orgs/:orgId/pages/:pageId

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": {
      "orgId": "<orgId>",
      "pageId": "<pageId>"
    },
    "name": "create_page"
  }
}

Input Schema

Name	Required	Description
`name`	No	e.g. Getting Started
`orgId`	Yes	Organization (company) ID of the current workspace
`state`	No	e.g. 1
`pageId`	Yes	12-character id of the PARENT page (rootParentId for a top-level page)
`urlName`	No	e.g. getting-started
`contents`	No	e.g. content in markdown

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: draft-by-default state, immediate publish behavior, publicUrl return, READ_WRITE permission requirement, sibling-unique slug generation, and the note that pageType is accepted but ignored. Annotations cover the safety profile and the description adds the operational details.

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 essential parent/type/publish rules, and the field enumeration is scannable. It does restate schema fields (name, urlName, contents, state) at some length, costing a bit of redundancy, but nothing is filler.

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 creation tool with no output schema, it covers prerequisites, permission needs, default state, publish side effects, and the return value (publicUrl). An agent has everything needed to call it correctly without inspecting other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description documents parameters absent from the schema (meta, sharingMeta, pageType, uniqueTabId) and gives constraints the schema omits, such as min lengths, default state, and the fact that uniqueTabId can be omitted by agents.

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 ('Creates a new page') and immediately clarifies placement semantics: last child of the parent passed in the path, type derived from parent. This distinguishes it cleanly from siblings like create_collection, publish_pages, and update-style tools.

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?

Explicit routing rules: pass rootParentId from List Collections for top-level pages, any other page id for subpages, plus the state=2 publishing prerequisite (parent must be published). It also names the follow-up alternative ('To write the page body afterwards use Update Page Content').

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

All Docstar tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?