Pushing content via MCP

Reading a wiki is the easy part. Pushing structured content into one is where the actual workflow lives — and where the difference between "a wiki you maintain" and "a wiki you fight with" gets decided.

This page covers the write path: from your AI tool's prompt to a published wiki page.

What you can write

WikiAIG exposes these write tools through MCP:

• create_page — make a new page in a wiki
• update_page — replace a page's content by slug
• append_to_page — add content to an existing page without rewriting
• delete_page — remove a page (rare; almost never the right move)
• create_wiki — make a new wiki in your account

Pages have a kind — overview, concept, entity, comparison, source, index. The kind isn't decorative. It tells the model reading the wiki what shape of knowledge to expect: an overview lays the map, a concept defines a thing, a comparison weighs options, a source attributes a claim. Pick the kind that matches the page's job, not the page's topic.

The basic write loop

From inside Claude Code, Cursor, or any other connected MCP tool:

"Create a new page in my architecture wiki titled Authentication flow. Make it a concept page. The content should be: [paste or describe]."

The tool calls create_page under the hood with something like:

{
  "wiki_slug": "architecture",
  "page": {
    "slug": "authentication-flow",
    "title": "Authentication flow",
    "kind": "concept",
    "content_type": "markdown",
    "content": "# Authentication flow\n\n..."
  }
}

The slug auto-generates from the title if you don't specify it. The page is private by default — visibility flips at the wiki level, not per-page.

Markdown vs HTML

Two content types are supported:

• markdown — the default. Best for prose, code, tables, anything you'd write in a docs site.
• html — for pages where layout matters: visualizations, comparison cards, structured reference. HTML pages render in a sandboxed iframe with a strict CSP. No JavaScript, no remote assets, no inline event handlers. See [HTML hosting — capabilities, constraints, examples](html-hosting) for what works.

Mix freely within a wiki. The overview can be markdown, a single dense reference page can be HTML, the comparison page can be either depending on whether it benefits from layout.

The workflows that actually work

After watching people use this, three patterns stand out.

1. "Codify what we just figured out." Mid-debugging session, you and the model just worked out why production is on fire. Instead of letting that knowledge evaporate into chat history, ask the model to write it up as an entity or concept page and push it. Six months from now, the next debugging session starts from that page instead of from scratch.

2. "Mirror the source of truth." Your real docs live in a repo. The model reads them, structures them into a wiki, pushes the wiki. The wiki isn't the source — the repo is — but it's the shape your AI tools can actually use. Re-run the import on every release.

3. "Decide once, ground forever." Architectural decisions, naming conventions, design principles. You write them as concept pages, push them once, and every future agent session grounds on them. The cost of inconsistency drops to near-zero because every tool reads the same source.

What not to do

• Don't sync your entire docs site. A wiki should be smaller and more opinionated than your docs. If you find yourself pushing 200 pages, you're using the wrong tool — point the agent at your docs URL instead.
• Don't push content the model generated without reading it. The model will happily make up plausible-sounding pages about things it doesn't know. Review before push. Your name is on the wiki.
• Don't write everything as a single overview page. The structure is the value. A wiki with 8 typed pages out-performs one giant markdown dump every time.

Versioning and rollback

Every page edit creates a version. You can see history via the page's settings menu in the web UI, and revert from there.

Where to next

→ [HTML hosting — capabilities, constraints, examples](html-hosting) — what you can do when markdown isn't enough.

→ [Why structured wikis make better AI grounding than raw markdown dumps](structured-wikis-vs-markdown-dumps) — the visual showcase that makes the case.