MuseDock documentation reuses blog articles and categories. The docs post type separates guides from the blog and gives them a /docs/slug address. There is no need to install another editorial system.

Create documentation in the CMS or a tenant

1. Open the administration panel of the site that will host the documentation. Use the main CMS panel for the main domain, or the tenant's own panel and categories for a tenant.
2. In Blog → Categories, create a root category with the exact slug docs. Its display name can be “Documentation”.
3. Under that root, create a product such as “My product”, with slug my-product. Under the product, create sections such as “Getting started” and “Configuration”.
4. In Blog → Posts → Create, select the Documentation type, enter the title and content, and assign the category of the relevant section.
5. Save a draft to review it. Publish with public visibility when the guide should appear in public documentation. Check its address and the navigation at /docs/.

Product and section tree

Documentation (slug: docs)
└── My product (slug: my-product)
    ├── Getting started
    │   ├── Introduction [docs article]
    │   └── Installation [docs article]
    └── Configuration
        └── Initial settings [docs article]

Products and sections are categories linked through their parent category; guides are articles assigned to those categories. The category order field (order in the API) controls product and section order. Articles are sorted by title, with priority for the introduction where applicable. This is not a manual page order.

On MuseDock.com, the root contains MuseDock CMS, MuseDock Panel and MuseDock Portal. The documentation landing page shows a card for each product and its sections. The ?product=cms parameter keeps the selected product in navigation; it does not grant access or replace the article type.

Content and automatic table of contents

The article title is already the H1. Use H2 headings for sections and H3 headings for subsections. The “On this page” column is built automatically from these headings. You do not need to create its links manually.

The editor stores HTML. Through MCP, send HTML such as <h2>Requirements</h2><p>Guide content.</p>. For code, use <pre><code>…</code></pre>, escaping the example's special characters. Tables, lists and quotations are also supported.

CMS responsibilities and theme responsibilities

The CMS stores articles, categories, site boundaries and routes. The theme displays product cards, the sidebar, breadcrumbs and the heading index through blog/docs-index and blog/single-docs. The MuseDock and default themes include these views; the renderer can fall back to the default theme when the active theme lacks the view.

Articles of type docs are excluded from the normal blog listing. On desktop, the template displays navigation, content and a heading index. On smaller screens, it adapts navigation and hides the side index to leave room for the text. The final appearance can vary with the theme.

Create and edit documentation through MCP

MCP already reuses the existing editorial tools: list_categories to inspect the structure, create_category with parent_id and order to create its levels, and create_post or update_post with post_type: "docs" to write guides. Use actual category identifiers from the site; do not invent identifiers.

{
  "title": "Installing my product",
  "content": "<h2>Requirements</h2><p>Describe the requirements here.</p>",
  "post_type": "docs",
  "status": "draft",
  "apply": true
}

Add site_id and category_ids using the authorized site and section values you have looked up. This example saves a draft; it neither publishes nor generates images. You can then publish using the existing tools and the appropriate permissions.

There is no dedicated “create documentation” tool that builds and selects the entire tree for you. Do not use the article-with-cover workflow when you only need a guide: that workflow is designed to generate an image. The MCP policy requiring a cover before publication still applies when enabled; switching to docs does not bypass it.

Documenting MuseDock.com requires an access authorized for the main domain. A Cross Publisher access restricted to tenants does not gain main-site access by creating documentation. Each tenant keeps its own articles and categories.

Approvals and automation

Each access has three separate automatic approval preferences: article creation and editing, publication, scheduling and cover assignment; image generation; and category or tag creation and editing. Permissions, authorized sites, quotas and editorial preferences always remain in force. Enabling automatic approval applies to new requests; existing requests awaiting manual approval do not change automatically.

Comment moderation, translations, media uploads, cross-site copying and news imports do not currently have independent automatic approval switches. They keep their request mechanism and, where authorized, approval through MCP. Pages from the Pages module are not currently exposed by these MCP tools; docs guides are managed as articles.