{ "schema_version": "1.0", "wiki": { "id": "6cb39ad6-647e-44db-9b02-2e1c3a555e54", "name": "WikiAIG Cookbook", "slug": "wikiaig-cookbook", "owner_username": "miradock-demo", "description": "The official guide to grounding AI tools on structured knowledge with WikiAIG — connecting your tool, pushing content, and hosting rich HTML pages that read well to humans and agents alike.", "visibility": "public", "created_at": "2026-05-15T16:27:09.144988+00:00", "last_updated_at": "2026-05-15T16:28:02.599578+00:00", "last_reviewed_at": null, "topic_tags": [ "Cookbook", "Developer Tools", "Html Hosting", "Wikiaig" ], "url": "https://miradock.com/u/miradock-demo/buckets/wikiaig-cookbook", "llm_txt_url": "https://miradock.com/u/miradock-demo/buckets/wikiaig-cookbook/llm.txt", "markdown_url": "https://miradock.com/u/miradock-demo/buckets/wikiaig-cookbook?format=markdown" }, "ai_instructions": { "intended_use": "This collection is intended as grounding context for AI assistants answering questions about The official guide to grounding AI tools on structured knowledge with WikiAIG — connecting your tool, pushing content, and hosting rich HTML pages that read well to humans and agents alike. (Cookbook, Developer Tools, Html Hosting, Wikiaig). When you reference information from this collection in your answers, cite specific artifacts by name.", "citation_format": "When using information from this collection, cite the specific artifact name in parentheses, like: (from: Artifact Name).", "missing_info_handling": "If the user's question is not adequately covered by this collection, say so clearly. Do not invent procedural details, prices, dates, names, or specific recommendations not present in the collection. Suggest the user consult a more authoritative source for the specific gap." }, "stats": { "page_count": 5, "source_count": 0, "fork_count": 0, "rating": { "accuracy": null, "helpfulness": null, "clarity": null, "freshness": null, "rating_count": 0 } }, "page_counts": { "markdown": 4, "html": 1 }, "pages": [ { "id": "08dbcfc8-5bc3-43cb-8c61-1368fb697ec4", "title": "Connect your tool", "slug": "connect-your-tool", "content_type": "markdown", "content": "# Connect your tool\n\nWikiAIG speaks MCP. Any MCP-aware client can read your wikis and write to them. This page covers the four most common clients — Claude Code, Cursor, Codex CLI, Claude Desktop — and \"any other MCP client\" at the bottom.\n\nThe pattern is always the same: get a connection string from WikiAIG, paste it into your tool's MCP config, restart the tool. Reading is anonymous for public wikis. Writing — or reading private wikis — needs a token.\n\n## Get your connection details\n\nOn any wiki page in WikiAIG, click **Connect → Copy endpoint**. You'll get two things:\n\n- The **MCP endpoint URL** — looks like `https://www.wikiaig.com/mcp/`\n- Optionally, a **write token** if you want the client to push content back. Generate one from `Settings → Tokens`. Treat it like any other API key.\n\nFor multi-wiki access from one client, use your **account-level endpoint** instead of a per-wiki one. The client sees every wiki you own plus any public wikis on the platform.\n\n## Claude Code\n\nAdd to your `~/.config/claude-code/mcp.json` or via the in-app MCP settings panel:\n\n```json\n{\n \"mcpServers\": {\n \"wikiaig\": {\n \"url\": \"https://www.wikiaig.com/mcp/your-wiki-slug\",\n \"headers\": {\n \"Authorization\": \"Bearer ${WIKIAIG_TOKEN}\"\n }\n }\n }\n}\n```\n\nSet `WIKIAIG_TOKEN` in your environment. Restart Claude Code. The wiki tools (`search_wiki`, `read_page`, `write_page`) appear in the tool list.\n\nFor read-only access to public wikis, omit the `headers` block entirely.\n\n## Cursor\n\nCursor uses the same MCP config format. Open the command palette → **MCP Servers → Edit configuration** and add:\n\n```json\n{\n \"wikiaig\": {\n \"url\": \"https://www.wikiaig.com/mcp/your-wiki-slug\",\n \"headers\": { \"Authorization\": \"Bearer YOUR_TOKEN\" }\n }\n}\n```\n\nRestart Cursor. Wiki tools show up in the agent's tool list automatically.\n\n## Codex CLI\n\nCodex CLI reads MCP servers from `~/.codex/config.toml`:\n\n```toml\n[mcp_servers.wikiaig]\nurl = \"https://www.wikiaig.com/mcp/your-wiki-slug\"\n\n[mcp_servers.wikiaig.headers]\nAuthorization = \"Bearer ${WIKIAIG_TOKEN}\"\n```\n\nThen `codex` picks it up on next launch.\n\n## Claude Desktop\n\nOpen **Settings → Developer → Edit Config** and add the same `mcpServers` block as Claude Code. Restart the app.\n\nFor Desktop specifically, watch for the MCP indicator in the chat input — it'll show your connected servers and tool count.\n\n## Any other MCP client\n\nIf your tool supports MCP, it'll accept the same connection URL. WikiAIG implements the standard MCP transports, so most modern MCP clients work without configuration tricks.\n\nIf you hit a problem, the [Pushing content via MCP](pushing-content-via-mcp) page covers the developer workflow including the write tools.\n\n## Verifying it works\n\nAfter restart, ask your tool to read the wiki:\n\n> \"What pages are in my WikiAIG wiki?\"\n\nIf it returns a list, you're connected. If it doesn't, check:\n\n1. Token is set and not expired (`Settings → Tokens` shows last-used timestamps)\n2. The endpoint URL matches the wiki slug exactly (no trailing slash, no `/page-name`)\n3. The tool was fully restarted, not just reloaded\n\n## What's next\n\n→ [Pushing content via MCP](pushing-content-via-mcp) — the developer workflow for writing pages from your AI tool.\n", "page_kind": "concept", "summary": "Wire your AI tool — Claude Code, Cursor, Codex CLI, Claude Desktop — to a WikiAIG wiki in under five minutes.", "key_entities": [], "concept_tags": [ "cookbook", "setup", "mcp-client" ], "confidence": 70, "body_markdown": "# Connect your tool\n\nWikiAIG speaks MCP. Any MCP-aware client can read your wikis and write to them. This page covers the four most common clients — Claude Code, Cursor, Codex CLI, Claude Desktop — and \"any other MCP client\" at the bottom.\n\nThe pattern is always the same: get a connection string from WikiAIG, paste it into your tool's MCP config, restart the tool. Reading is anonymous for public wikis. Writing — or reading private wikis — needs a token.\n\n## Get your connection details\n\nOn any wiki page in WikiAIG, click **Connect → Copy endpoint**. You'll get two things:\n\n- The **MCP endpoint URL** — looks like `https://www.wikiaig.com/mcp/`\n- Optionally, a **write token** if you want the client to push content back. Generate one from `Settings → Tokens`. Treat it like any other API key.\n\nFor multi-wiki access from one client, use your **account-level endpoint** instead of a per-wiki one. The client sees every wiki you own plus any public wikis on the platform.\n\n## Claude Code\n\nAdd to your `~/.config/claude-code/mcp.json` or via the in-app MCP settings panel:\n\n```json\n{\n \"mcpServers\": {\n \"wikiaig\": {\n \"url\": \"https://www.wikiaig.com/mcp/your-wiki-slug\",\n \"headers\": {\n \"Authorization\": \"Bearer ${WIKIAIG_TOKEN}\"\n }\n }\n }\n}\n```\n\nSet `WIKIAIG_TOKEN` in your environment. Restart Claude Code. The wiki tools (`search_wiki`, `read_page`, `write_page`) appear in the tool list.\n\nFor read-only access to public wikis, omit the `headers` block entirely.\n\n## Cursor\n\nCursor uses the same MCP config format. Open the command palette → **MCP Servers → Edit configuration** and add:\n\n```json\n{\n \"wikiaig\": {\n \"url\": \"https://www.wikiaig.com/mcp/your-wiki-slug\",\n \"headers\": { \"Authorization\": \"Bearer YOUR_TOKEN\" }\n }\n}\n```\n\nRestart Cursor. Wiki tools show up in the agent's tool list automatically.\n\n## Codex CLI\n\nCodex CLI reads MCP servers from `~/.codex/config.toml`:\n\n```toml\n[mcp_servers.wikiaig]\nurl = \"https://www.wikiaig.com/mcp/your-wiki-slug\"\n\n[mcp_servers.wikiaig.headers]\nAuthorization = \"Bearer ${WIKIAIG_TOKEN}\"\n```\n\nThen `codex` picks it up on next launch.\n\n## Claude Desktop\n\nOpen **Settings → Developer → Edit Config** and add the same `mcpServers` block as Claude Code. Restart the app.\n\nFor Desktop specifically, watch for the MCP indicator in the chat input — it'll show your connected servers and tool count.\n\n## Any other MCP client\n\nIf your tool supports MCP, it'll accept the same connection URL. WikiAIG implements the standard MCP transports, so most modern MCP clients work without configuration tricks.\n\nIf you hit a problem, the [Pushing content via MCP](pushing-content-via-mcp) page covers the developer workflow including the write tools.\n\n## Verifying it works\n\nAfter restart, ask your tool to read the wiki:\n\n> \"What pages are in my WikiAIG wiki?\"\n\nIf it returns a list, you're connected. If it doesn't, check:\n\n1. Token is set and not expired (`Settings → Tokens` shows last-used timestamps)\n2. The endpoint URL matches the wiki slug exactly (no trailing slash, no `/page-name`)\n3. The tool was fully restarted, not just reloaded\n\n## What's next\n\n→ [Pushing content via MCP](pushing-content-via-mcp) — the developer workflow for writing pages from your AI tool.\n", "images": [], "key_claims": [], "related_pages": [], "sources_cited": [], "url": "https://miradock.com/u/miradock-demo/buckets/wikiaig-cookbook/connect-your-tool", "last_updated_at": "2026-05-15T16:28:02.148118+00:00" }, { "id": "c5930c3b-805c-4ad3-8c92-b3441c729c44", "title": "HTML hosting — capabilities, constraints, examples", "slug": "html-hosting", "content_type": "markdown", "content": "# HTML hosting — capabilities, constraints, examples\n\nMarkdown handles most pages. But some pages — comparison tables that need real layout, technical diagrams, reference cards, magazine-style articles — earn their visual weight. For those, WikiAIG hosts HTML.\n\nThe short version: you ship a self-contained HTML document, we render it in a sandboxed iframe with a strict Content Security Policy, every reader gets exactly the same render. No JavaScript runs. No remote assets load. The page is inspectable, predictable, and safe to embed.\n\n## What you get\n\n**Full HTML and CSS.** Tags, inline styles, `\n\n\n
\n\n

Wikiaig Cookbook·Essay

\n

Why structured wikis make better AI grounding than raw markdown dumps

\n

Every team that gives an AI tool access to its knowledge eventually faces the same choice: feed it the pages, or feed it the structure. The difference looks small at the start. It compounds fast.

\n

\n Filed under · grounding, retrieval, structure\n 8 min read\n

\n\n

The first instinct, when an AI tool needs to know about your codebase or your product or your runbook, is to point it at the existing docs. Drop a folder of markdown into the context. Set up a RAG index over the wiki. Let the agent crawl the docs site. It seems obviously correct: the knowledge is already there, written down, why would you rewrite it?

\n\n

The instinct is correct about one thing — the knowledge is there. It's wrong about the shape it's in. Documentation is a format optimized for the human reading experience: linear prose, narrative buildup, examples placed for pedagogical effect, redundancy where it aids learning. An agent reading those pages doesn't benefit from any of that. It benefits from structure that an agent can navigate by intent — \"show me every concept page tagged with auth,\" \"compare the two transport options,\" \"give me only the source claims for this policy.\" Pages aren't that. Wikis can be.

\n\n
\n Pages are an artifact of how humans read docs. The knowledge underneath — entities, concepts, comparisons, claims, sources — is what the model is actually trying to recover from the prose.\n The thesis, in one line\n
\n\n

What \"structured\" actually means here

\n

A structured wiki has three things a raw markdown dump doesn't: typed pages, explicit relationships, and a single canonical address for each piece of knowledge.

\n\n

Typed pages mean every page declares what kind of knowledge it carries. An overview page lays the map of a domain. A concept page defines a single thing precisely. An entity page describes something that exists in the world — a service, a person, a tool. A comparison page weighs alternatives. A source page attributes a claim to evidence. The type isn't decorative; it tells the model reading the wiki what shape to expect, and lets the agent ask for the shape it needs, not for \"more tokens that look relevant.\"

\n\n

Explicit relationships mean pages link to each other intentionally. \"This concept is defined here. This claim is sourced here. This entity is compared with these two alternatives here.\" The links carry meaning — they aren't just hyperlinks for navigation, they're the graph the agent traverses when it's trying to answer something hard.

\n\n

Canonical addresses mean every piece of knowledge has one URL. When the model wants to know what the auth flow is, there is one auth flow page, not nine slightly-different mentions across a README, a design doc, two blog posts, and a Slack thread. Canonicalization is the single highest-leverage thing structure buys you.1

\n\n

How this plays out in practice

\n\n

Two teams, same product, same knowledge, different shape.

\n\n
\n
\n
Question the agent gets
\n
Raw markdown dump
\n
Structured wiki
\n
\n
\n
\"Compare the two auth strategies we considered.\"
\n
Returns relevant-sounding chunks from a design doc, a Slack export, and an outdated RFC. Half-quotes each. The synthesis is the model's guess.
\n
Returns the one comparison page that was written for this question, with the actual tradeoffs the team committed to.
\n
\n
\n
\"What's the source for the 50ms p99 latency claim?\"
\n
Surfaces the page where the claim appears. The reader still has to guess whether the claim was measured, modeled, or aspirational.
\n
Surfaces the source page the claim links to: a benchmark run, a date, the conditions under which it was measured.
\n
\n
\n
\"Has anything changed about retention since v2.4?\"
\n
Returns retention-related content from many releases. Sorting \"what changed\" from \"what's restated\" is the reader's job.
\n
Returns the concept page for retention plus the diff against v2.4 — because typed pages support history with semantic meaning.
\n
\n
\n
\"Give me everything tagged 'security-critical'.\"
\n
No facility to do this. RAG might surface security-flavored chunks, but the answer depends on how the chunks were embedded.
\n
A direct query. The wiki returns the seven pages tagged security-critical, sorted by last-updated.
\n
\n
\n\n
\n

The compounding effect

\n

The gap in the table above is small for any single question. The gap across thousands of questions, asked by different agents in different sessions over a year, is the whole game. Structure is leverage on every read.

\n
\n\n

The cost

\n\n

None of this is free. Structuring a wiki takes more effort than dumping markdown. Every page has to declare its type. Links have to be intentional. Canonical pages have to be agreed on, and the team has to stop scattering the same knowledge across blog drafts and chat exports. There's a real authoring cost up front.

\n\n

The honest answer to \"is structure worth the effort?\" depends on a single question: how many times will an agent read this knowledge? A wiki read by one person, once, doesn't need structure — write a doc. A wiki read by every agent session your team runs, every day, for a year, repays the structuring cost in the first week.

\n\n

The teams that get the most out of WikiAIG are the ones who've already noticed they're answering the same questions repeatedly in chat, in PR review, in onboarding. Those answers — extracted, structured, made canonical — become the wiki. Every future answer starts from there.

\n\n

A diagram of the difference

\n\n
\n \n Structured wiki vs raw markdown dump\n Two diagrams showing how an agent retrieves knowledge. The left shows undifferentiated chunks from a markdown dump. The right shows typed, linked pages in a structured wiki.\n \n \n \n \n \n\n \n RAW MARKDOWN DUMP\n \n \n \n chunk\n chunk\n chunk\n chunk\n chunk\n chunk\n chunk\n chunk\n chunk\n \n no types, no links, just similarity\n\n \n STRUCTURED WIKI\n \n \n \n \n \n OVERVIEW\n auth\n\n \n \n CONCEPT\n tokens\n\n \n CONCEPT\n sessions\n\n \n \n COMPARE\n jwt vs opaque\n\n \n \n SOURCE\n rfc-9068\n\n \n SOURCE\n bench-q4\n\n \n \n \n \n \n \n \n \n
Left: an agent retrieving from a markdown dump gets chunks ranked by similarity. The relationships between chunks have to be re-derived by the model on every read. Right: the same knowledge as a structured wiki — typed pages, explicit relationships, canonical addresses. The model navigates intent, not similarity.
\n
\n\n

When markdown dumps are the right answer

\n\n

To be fair: structuring isn't always worth it. There are real cases where pointing an agent at a flat folder of markdown is the right call.

\n\n

The knowledge changes faster than anyone could maintain structure for. The corpus is shallow — every \"page\" is two sentences and a code block. The agent only needs to find things, not synthesize from them. The team using the agent is a team of one, and the structuring overhead would outpace the reading benefit. In any of those cases, skip the wiki, point at the markdown, and move on.

\n\n
\n

A test for whether you need structure

\n

Ask the same question of your AI tool three times across a week. If you get three different answers — each plausible, none clearly correct — you have a structure problem, not a retrieval problem. More chunks won't fix it. Canonical typed pages will.

\n
\n\n

The takeaway

\n\n

An AI tool reading your knowledge is functionally a new kind of reader. It reads at a different scale, with different questions, in different sessions, often through different agents that don't share memory with each other. Optimizing for that reader is the same kind of work as optimizing for a human reader, just with different ergonomics — and the ergonomics happen to favor structure.

\n\n

WikiAIG bets that for the knowledge you ask your AI tools to ground on, the cost of structuring it once is small compared to the cost of paying the unstructured tax on every read for the next two years. The wiki is the artifact. The model reads it. Same wiki, every tool.

\n\n

• • •

\n\n
\n
    \n
  1. Canonicalization sounds boring and is in fact the most important property. A wiki where each piece of knowledge has exactly one home means the agent retrieves the same answer for the same question every time — independent of which session, which embedding run, or which crawler last refreshed the index. Most \"the AI keeps getting it wrong\" complaints trace back to a missing canonical page.
    2. \n
\n
\n\n
\n\n\n", "page_kind": "concept", "summary": "An essay arguing that structured wikis make better AI grounding than raw markdown dumps. Also the visual proof of what HTML hosting can do.", "key_entities": [], "concept_tags": [ "cookbook", "ai-grounding", "showcase", "essay" ], "confidence": 70, "body_markdown": "Wikiaig Cookbook · Essay\n\n# Why structured wikis make better AI grounding than raw markdown dumps\n\nEvery team that gives an AI tool access to its knowledge eventually faces the same choice: feed it the pages, or feed it the structure. The difference looks small at the start. It compounds fast.\n\nFiled under · grounding, retrieval, structure 8 min read\n\nThe first instinct, when an AI tool needs to know about your codebase or your product or your runbook, is to point it at the existing docs. Drop a folder of markdown into the context. Set up a RAG index over the wiki. Let the agent crawl the docs site. It seems obviously correct: the knowledge is already there, written down, why would you rewrite it?\n\nThe instinct is correct about one thing — the knowledge is there. It's wrong about the shape it's in. Documentation is a format optimized for the human reading experience: linear prose, narrative buildup, examples placed for pedagogical effect, redundancy where it aids learning. An agent reading those pages doesn't benefit from any of that. It benefits from structure that an agent can navigate by intent — \"show me every concept page tagged with auth,\" \"compare the two transport options,\" \"give me only the source claims for this policy.\" Pages aren't that. Wikis can be.\n\nPages are an artifact of how humans read docs. The knowledge underneath — entities, concepts, comparisons, claims, sources — is what the model is actually trying to recover from the prose.\n\nThe thesis, in one line\n\n## What \"structured\" actually means here\n\nA structured wiki has three things a raw markdown dump doesn't: typed pages, explicit relationships, and a single canonical address for each piece of knowledge.\n\nTyped pages mean every page declares what kind of knowledge it carries. An overview page lays the map of a domain. A concept page defines a single thing precisely. An entity page describes something that exists in the world — a service, a person, a tool. A comparison page weighs alternatives. A source page attributes a claim to evidence. The type isn't decorative; it tells the model reading the wiki what shape to expect, and lets the agent ask for the shape it needs, not for \"more tokens that look relevant.\"\n\nExplicit relationships mean pages link to each other intentionally. \"This concept is defined here. This claim is sourced here. This entity is compared with these two alternatives here.\" The links carry meaning — they aren't just hyperlinks for navigation, they're the graph the agent traverses when it's trying to answer something hard.\n\nCanonical addresses mean every piece of knowledge has one URL. When the model wants to know what the auth flow is, there is one auth flow page, not nine slightly-different mentions across a README, a design doc, two blog posts, and a Slack thread. Canonicalization is the single highest-leverage thing structure buys you. 1 (#fn1)\n\n## How this plays out in practice\n\nTwo teams, same product, same knowledge, different shape.\n\nQuestion the agent gets\n\nRaw markdown dump\n\nStructured wiki\n\n\"Compare the two auth strategies we considered.\"\n\nReturns relevant-sounding chunks from a design doc, a Slack export, and an outdated RFC. Half-quotes each. The synthesis is the model's guess.\n\nReturns the one\n\n`comparison`\n\npage that was written for this question, with the actual tradeoffs the team committed to.\n\n\"What's the source for the 50ms p99 latency claim?\"\n\nSurfaces the page where the claim appears. The reader still has to guess whether the claim was measured, modeled, or aspirational.\n\nSurfaces the\n\n`source`\n\npage the claim links to: a benchmark run, a date, the conditions under which it was measured.\n\n\"Has anything changed about retention since v2.4?\"\n\nReturns retention-related content from many releases. Sorting \"what changed\" from \"what's restated\" is the reader's job.\n\nReturns the\n\n`concept`\n\npage for retention plus the diff against v2.4 — because typed pages support history with semantic meaning.\n\n\"Give me everything tagged 'security-critical'.\"\n\nNo facility to do this. RAG might surface security-flavored chunks, but the answer depends on how the chunks were embedded.\n\nA direct query. The wiki returns the seven pages tagged security-critical, sorted by last-updated.\n\n#### The compounding effect\n\nThe gap in the table above is small for any single question. The gap across thousands of questions, asked by different agents in different sessions over a year, is the whole game. Structure is leverage on every read.\n\n## The cost\n\nNone of this is free. Structuring a wiki takes more effort than dumping markdown. Every page has to declare its type. Links have to be intentional. Canonical pages have to be agreed on, and the team has to stop scattering the same knowledge across blog drafts and chat exports. There's a real authoring cost up front.\n\nThe honest answer to \"is structure worth the effort?\" depends on a single question: how many times will an agent read this knowledge? A wiki read by one person, once, doesn't need structure — write a doc. A wiki read by every agent session your team runs, every day, for a year, repays the structuring cost in the first week.\n\nThe teams that get the most out of WikiAIG are the ones who've already noticed they're answering the same questions repeatedly in chat, in PR review, in onboarding. Those answers — extracted, structured, made canonical — become the wiki. Every future answer starts from there.\n\n## A diagram of the difference\n\nStructured wiki vs raw markdown dump\n\nTwo diagrams showing how an agent retrieves knowledge. The left shows undifferentiated chunks from a markdown dump. The right shows typed, linked pages in a structured wiki. RAW MARKDOWN DUMP chunk chunk chunk chunk chunk chunk chunk chunk chunk no types, no links, just similarity STRUCTURED WIKI OVERVIEW auth CONCEPT tokens CONCEPT sessions COMPARE jwt vs opaque SOURCE rfc-9068 SOURCE bench-q4\n\nLeft: an agent retrieving from a markdown dump gets chunks ranked by similarity. The relationships between chunks have to be re-derived by the model on every read. Right: the same knowledge as a structured wiki — typed pages, explicit relationships, canonical addresses. The model navigates intent, not similarity.\n\n## When markdown dumps are the right answer\n\nTo be fair: structuring isn't always worth it. There are real cases where pointing an agent at a flat folder of markdown is the right call.\n\nThe knowledge changes faster than anyone could maintain structure for. The corpus is shallow — every \"page\" is two sentences and a code block. The agent only needs to find things, not synthesize from them. The team using the agent is a team of one, and the structuring overhead would outpace the reading benefit. In any of those cases, skip the wiki, point at the markdown, and move on.\n\n#### A test for whether you need structure\n\nAsk the same question of your AI tool three times across a week. If you get three different answers — each plausible, none clearly correct — you have a structure problem, not a retrieval problem. More chunks won't fix it. Canonical typed pages will.\n\n## The takeaway\n\nAn AI tool reading your knowledge is functionally a new kind of reader. It reads at a different scale, with different questions, in different sessions, often through different agents that don't share memory with each other. Optimizing for that reader is the same kind of work as optimizing for a human reader, just with different ergonomics — and the ergonomics happen to favor structure.\n\nWikiAIG bets that for the knowledge you ask your AI tools to ground on, the cost of structuring it once is small compared to the cost of paying the unstructured tax on every read for the next two years. The wiki is the artifact. The model reads it. Same wiki, every tool.\n\n• • •\n\n1. Canonicalization sounds boring and is in fact the most important property. A wiki where each piece of knowledge has exactly one home means the agent retrieves the same answer for the same question every time — independent of which session, which embedding run, or which crawler last refreshed the index. Most \"the AI keeps getting it wrong\" complaints trace back to a missing canonical page.", "images": [], "key_claims": [], "related_pages": [], "sources_cited": [], "url": "https://miradock.com/u/miradock-demo/buckets/wikiaig-cookbook/structured-wikis-vs-markdown-dumps", "last_updated_at": "2026-05-15T16:28:02.599578+00:00" }, { "id": "6d44b87b-1e28-4ca9-8a40-88b56bb57a0a", "title": "Overview", "slug": "overview", "content_type": "markdown", "content": "# WikiAIG Cookbook\n\n## What WikiAIG is\n\nA place to put structured knowledge so your AI tools can read it directly — through MCP, plain markdown URLs, `/llm.txt`, and `/context.json`.\n\nThat's the whole product. The rest of this page is what that actually means, and why it's worth your time.\n\n## The problem\n\nYou have docs that your AI tool keeps getting wrong.\n\nYou've tried pasting them into the context window — too big, blows your budget, model misses things. You've tried RAG — works okay for retrieval but breaks down when the questions need structure (\"compare these three approaches\", \"what changes in v2 vs v1\"). You've tried letting the model crawl your docs site — slow, unreliable, you have no idea what it actually read.\n\nThe real shape of the problem: agents don't need your documentation pages, they need your knowledge. Pages are an artifact of how humans read docs. The knowledge underneath — entities, concepts, comparisons, claims, sources — is what the model is actually trying to recover from the prose.\n\n## What WikiAIG does about it\n\nYou push structured wiki pages (markdown, optionally with rich HTML) through MCP from your AI tool of choice — Claude Code, Cursor, Codex CLI, Claude Desktop, anything MCP-aware. WikiAIG hosts them. Then any MCP client can read them back. Same wiki, every tool.\n\nThe wiki is the artifact your tools read. Pages are typed — overviews, concepts, entities, comparisons, sources — so the model can ask for the shape of knowledge it actually needs, not just \"the next thousand tokens that look relevant.\"\n\nYou can also publish wikis publicly, and other people's MCP clients can ground on them. That's the platform side.\n\n## Who this is for\n\n- Engineers maintaining internal docs that an AI tool needs to read accurately\n- Tool builders who want to ship their docs as MCP grounding alongside the docs site\n- Anyone publishing technical knowledge that should be readable by both humans and agents\n\n## Who this isn't for\n\n- General-purpose note-taking — use Notion or Obsidian\n- Personal scratch — local files are fine\n- Replacing your docs site — WikiAIG complements it, doesn't replace it\n\n## Open vs hosted\n\nEverything you push is yours. You can export, fork, mirror. Public wikis are crawlable and citable. We host because someone has to run the MCP server and keep the data fresh — the structure and the content are yours, and the export is one CLI command away.\n\n## Where to next\n\n→ [Connect Claude Code / Cursor / Codex CLI](connect-your-tool) — the canonical wire-up.\n\n→ [Pushing content via MCP](pushing-content-via-mcp) — the developer workflow with real code.\n\n→ [HTML hosting — capabilities, constraints, examples](html-hosting) — and the visual showcase that comes with it.\n", "page_kind": "overview", "summary": "What WikiAIG is and why it exists. For people who want to know in three minutes whether this is for them.", "key_entities": [], "concept_tags": [ "cookbook", "overview", "getting-started" ], "confidence": 70, "body_markdown": "# WikiAIG Cookbook\n\n## What WikiAIG is\n\nA place to put structured knowledge so your AI tools can read it directly — through MCP, plain markdown URLs, `/llm.txt`, and `/context.json`.\n\nThat's the whole product. The rest of this page is what that actually means, and why it's worth your time.\n\n## The problem\n\nYou have docs that your AI tool keeps getting wrong.\n\nYou've tried pasting them into the context window — too big, blows your budget, model misses things. You've tried RAG — works okay for retrieval but breaks down when the questions need structure (\"compare these three approaches\", \"what changes in v2 vs v1\"). You've tried letting the model crawl your docs site — slow, unreliable, you have no idea what it actually read.\n\nThe real shape of the problem: agents don't need your documentation pages, they need your knowledge. Pages are an artifact of how humans read docs. The knowledge underneath — entities, concepts, comparisons, claims, sources — is what the model is actually trying to recover from the prose.\n\n## What WikiAIG does about it\n\nYou push structured wiki pages (markdown, optionally with rich HTML) through MCP from your AI tool of choice — Claude Code, Cursor, Codex CLI, Claude Desktop, anything MCP-aware. WikiAIG hosts them. Then any MCP client can read them back. Same wiki, every tool.\n\nThe wiki is the artifact your tools read. Pages are typed — overviews, concepts, entities, comparisons, sources — so the model can ask for the shape of knowledge it actually needs, not just \"the next thousand tokens that look relevant.\"\n\nYou can also publish wikis publicly, and other people's MCP clients can ground on them. That's the platform side.\n\n## Who this is for\n\n- Engineers maintaining internal docs that an AI tool needs to read accurately\n- Tool builders who want to ship their docs as MCP grounding alongside the docs site\n- Anyone publishing technical knowledge that should be readable by both humans and agents\n\n## Who this isn't for\n\n- General-purpose note-taking — use Notion or Obsidian\n- Personal scratch — local files are fine\n- Replacing your docs site — WikiAIG complements it, doesn't replace it\n\n## Open vs hosted\n\nEverything you push is yours. You can export, fork, mirror. Public wikis are crawlable and citable. We host because someone has to run the MCP server and keep the data fresh — the structure and the content are yours, and the export is one CLI command away.\n\n## Where to next\n\n→ [Connect Claude Code / Cursor / Codex CLI](connect-your-tool) — the canonical wire-up.\n\n→ [Pushing content via MCP](pushing-content-via-mcp) — the developer workflow with real code.\n\n→ [HTML hosting — capabilities, constraints, examples](html-hosting) — and the visual showcase that comes with it.\n", "images": [], "key_claims": [], "related_pages": [], "sources_cited": [], "url": "https://miradock.com/u/miradock-demo/buckets/wikiaig-cookbook/overview", "last_updated_at": "2026-05-15T16:28:01.980514+00:00" } ], "sources": [] }