The eight tools

Each tool is a thin wrapper over a db.js store function, declared with a Zod schema so the SDK validates arguments before the handler runs. Read tools first, then write tools.

Read

• wiki_tree — the whole structure: every section with nested pages/subpages. Call this first to see what exists before writing.
• wiki_list_sections — sections with page counts.
• wiki_search {query} — full-text search over titles and bodies, with excerpts.
• wiki_get_page {section, page} — one page's full Markdown body plus its parent/children.
• wiki_recent — most recently updated pages.

Write

• wiki_create_section {title, slug?, blurb?, accent?} — make (or fetch) a section. One per project. accent is one of ultramarine|teal|amber|rose|violet|green.
• wiki_create_page {section, title, body, slug?, parent?} — create or overwrite a page. body is Markdown. Pass parent (a page slug) to nest it as a subpage.
• wiki_update_page {section, slug, title?, body?, parent?} — patch an existing page.

The intended workflow

wiki_tree                    # what's already documented?
wiki_create_section(...)     # one section for the thing you built
wiki_create_page(overview)   # what it is and why
wiki_create_page(part-a, parent: feature)   # how each part works
wiki_create_page(part-b, parent: feature)

Create is idempotent-ish: wiki_create_page on an existing (section, slug) overwrites rather than erroring or duplicating. That makes re-running documentation safe — you can regenerate a page without first deleting it. The same is true of wiki_create_section, which returns the existing section if the slug is taken.

The teaching contract

The tool descriptions deliberately tell the agent to write explainers — "what it is, how it works, why, gotchas" — not changelogs. The point of Codex is understanding, so the tools nudge every writer toward prose you'd actually learn from.