Skip to main content
Glama
Sign In
wikikit

wikikit

by AvalancheAI-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

agent-wiki-kit

CI License: MIT Python 3.10+

One engine for every LLM wiki you'll ever run. A wiki is a folder of Markdown files with frontmatter plus a wiki.yaml registry — wikikit makes it lintable (contracts, links, freshness), publishable (llms.txt, llms-full.txt, index.json, plain no-JS HTML), and consumable by any agent over MCP. Zero dependencies: Python 3 stdlib only.

The pattern follows the Karpathy LLM-wiki idea and the agentwikis.com serving model: knowledge is compiled once and kept current, not re-derived per query. Compilation is agent work (the wiki-ingest skill / wikikit ingest); the engine itself is deterministic.

See it live: examples/corporate-brain-patterns is a real wiki built with wikikit — read INDEX.md for the source pages, or the generated _site/ for what wikikit build emits (llms.txt, llms-full.txt, index.json, HTML).

Why not just a vector DB / RAG over raw docs?

Raw-text retrieval re-derives an answer from whatever chunks happen to match a query, every single time — no page ever gets better, corrections don't stick, and nothing tells you a source went stale. wikikit's bet: a small, governed, continuously-curated wiki that an agent reads directly beats re-deriving from an ever-growing pile of raw source documents, both on accuracy and on maintenance cost. See reference/curated-vs-raw-retrieval for the evidence. It isn't a replacement for a vector DB on unstructured search — it's for the slice of knowledge worth compiling once and keeping current, the same slice a human onboarding doc or runbook already covers.

Related MCP server: @openindex/openindexwiki

Quick start

pip install -e .            # or: pip install wikikit, once published

# scaffold a wiki (constitution + registry + meta)
wikikit init ~/wikis/my-domain --name my-domain

# compile a source into it (uses the claude CLI; or use skills/wiki-ingest interactively)
wikikit ingest ~/wikis/my-domain ~/Downloads/some-research.md

# health
wikikit lint ~/wikis/my-domain      # errors exit 1 — CI-able
wikikit status ~/wikis/my-domain

# publish for agents + humans
wikikit build ~/wikis/my-domain     # -> _site/llms.txt, index.json, HTML

# serve to any MCP client
wikikit serve ~/wikis/my-domain

No install? Every command also runs as python3 wikikit_cli.py <cmd> ... from a clone of this repo.

Register with Claude Code / Claude Desktop:

{"mcpServers": {"my-domain-wiki": {
  "command": "wikikit",
  "args": ["serve", "/path/to/wikis/my-domain"]}}}

MCP tools exposed: wiki_list_pages, wiki_read_page, wiki_read_section (cheap targeted reads), wiki_search, wiki_recent. Pages are re-read on each call, so edits are live without restarting.

Page contract

---
title: GitLab's Public Handbook
type: entity          # from wiki.yaml page_types
status: live          # live | draft | deprecated | planned
last_verified: 2026-07-07   # a claim: checked against reality on this date
summary: One line for llms.txt listings and search results.
sources: [where this came from]
tags: [a, b]
---

[[wikilinks]] are first-class (lint checks them both in [[slug]] and relative .md link form). Dirs starting with _ (_raw, _meta, _site) are operational, never served.

Lint rules

MALFORMED, MISSING_FIELD, BAD_STATUS, BAD_DATE, UNKNOWN_TYPE, BROKEN_LINK (errors — exit 1) · STALE, ORPHAN, NO_SUMMARY (warnings).

Layout

wikikit/            engine (frontmatter, wiki model, lint, search, build, mcp_server, ingest, cli)
templates/          scaffolding used by `init` (CONSTITUTION.md, wiki.yaml)
skills/wiki-ingest/ Claude Code skill: how to compile sources into a wiki
examples/corporate-brain-patterns/  working demo — public case studies in compiled organizational knowledge (lints clean, serves over MCP)

Instance profiles (roadmap)

The same engine backs different products by choosing page types + ingest sources:

  • Market/competitor wiki — entities + synthesis + weekly signals, for tracking a competitive landscape.

  • Key-account wiki — snapshot, buying map, tech stack, angle, and signals per account.

  • Data-asset wiki — tables, semantic models, pipelines, and agents, feeding downstream analytics agents.

  • Ops wiki — runbooks + known-error DB.

Available Tools

5 tools
wiki_list_pagesA

List all wiki pages (slug, title, type, status, last_verified, summary). Use first to discover what exists before reading or searching.

NameRequiredDescriptionDefault
page_typeNoPage type filter, one of ['entity', 'synthesis', 'signals', 'reference'].

TDQS

A4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden, and it does disclose the shape of the result set (slug, title, type, status, last_verified, summary). It says nothing about pagination, result caps, or ordering for what could be a large list, and never states plainly that this is a non-mutating read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste: the first front-loads what is returned, the second front-loads the usage rule. Every clause earns its place, and the field list compensates for the absent output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-optional-parameter, read-only listing tool with no output schema, the description supplies the return fields and the usage ordering, which is most of what an agent needs. The remaining gap is pagination and list-size behavior, which is minor for this complexity.

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

Parameters3/5

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

Schema coverage is 100% and the single page_type parameter is fully documented in the schema with its allowed values, so the baseline is 3. The description never mentions the filter or how it changes the listing, adding nothing beyond the schema here.

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 ('List all wiki pages') and enumerates the returned fields, so the agent knows exactly what comes back. The trailing clause positions it against the read/search siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly orders its use ('Use first to discover what exists before reading or searching'), naming the read/search siblings as the alternatives. It gives no when-not guidance or explanation of the page_type filter's role in narrowing results.

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

wiki_read_pageB

Read one full wiki page by slug, including metadata and sources.

NameRequiredDescriptionDefault
slugYesPage slug, e.g. 'entities/gitlab-handbook'.

TDQS

B3.4/5.0
Behavior3/5

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

There are no annotations, so the description must carry behavioral context. 'Read' implies a safe, non-mutating operation and it discloses that output includes metadata and sources, but it does not cover permissions, missing-page behavior, or other operational traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with no filler; it states purpose, scope, and notable output contents efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no output schema or annotations, the description identifies what is returned (metadata and sources). It stops short of documenting failure modes or output structure, but is largely sufficient for correct invocation.

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

Parameters3/5

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

The schema already documents the single required slug parameter at 100% coverage, including an example. The description repeats 'by slug' but adds no syntax or meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Read), resource (wiki page), and scope (one full page by slug), plus output contents. It does not explicitly name or contrast with sibling tools like wiki_read_section, so sibling differentiation is only implied by 'full page' rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to choose this over wiki_read_section, wiki_search, or wiki_list_pages. The description only defines the operation, leaving selection entirely to inference.

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

wiki_read_sectionA

Read a single section of a page by heading (case-insensitive substring). Cheaper than wiki_read_page — prefer it when you need one section.

NameRequiredDescriptionDefault
slugYes
headingYesHeading text or substring.

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. It usefully documents that heading matching is a case-insensitive substring and that the call is cheaper than a full page read, but it says nothing about behavior when the heading does not match, whether multiple matches are possible, or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no waste, with the core action stated first and the cost/alternative rationale second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with no annotations and no output schema, the description covers the essentials: what it returns (a section), how the heading is matched, and when to prefer it. The main gap is failure/edge behavior (no match, ambiguous match) and the undocumented slug parameter.

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

Parameters3/5

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

Schema coverage is only 50%: 'heading' has a description while 'slug' is undocumented in both schema and description. The description does add value by clarifying the case-insensitive substring matching semantics for heading, but it leaves slug's meaning (the page identifier) entirely to inference.

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 (Read) and resource (a single section of a page) plus the lookup key (heading), and explicitly contrasts itself with the sibling wiki_read_page. An agent can distinguish it from wiki_read_page and wiki_search without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear selection rule — 'prefer it when you need one section' — and names the alternative (wiki_read_page) along with the reason (cheaper). It stops short of stating the when-not case explicitly (i.e., use wiki_read_page for whole pages or wiki_search when you don't know the heading), so it is strong but not fully exhaustive.

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

wiki_recentB

Pages verified/updated within the last N days (default 14) — the freshness view.

NameRequiredDescriptionDefault
daysNo

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the default window (14 days) and the verified/updated semantics, but says nothing about read-only status, result ordering, pagination, or volume limits for what could be a large set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the selection criterion, with the default and the tool's role packed into a short em-dash clause. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter query tool with no annotations and no output schema, the essentials (what is returned and the default window) are covered, but ordering, pagination, and the read-only nature of the operation are left for the agent to assume.

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

Parameters4/5

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

The single parameter has 0% schema description coverage, so the description must compensate and largely does: it defines 'days' as a lookback window and states the default of 14. It does not clarify whether the window is calendar or rolling, or any upper bound.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (pages) and the precise selection criterion (verified/updated within the last N days), and the 'freshness view' framing signals how it differs from a generic page list. It stops short of naming wiki_list_pages as the non-freshness alternative, so differentiation is semantic rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'the freshness view' and the time-window criterion, so an agent can infer this is for recency questions. There is no explicit when-to-use statement, no exclusion of the sibling list/search tools, and no guidance on choosing a window size.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedwiki_list_pages
    • First observedwiki_read_page
    • First observedwiki_read_section
    • First observedwiki_recent
    • First observedwiki_search
Deploy Server
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation4/5

Each tool has a distinct retrieval purpose (list, full read, section read, search, freshness), and descriptions explicitly clarify when to prefer one over another. Minor overlap between wiki_list_pages and wiki_recent since both enumerate pages, but the time filter distinguishes them.

Naming Consistency4/5

All tools share the wiki_ prefix and use snake_case, with mostly verb_noun patterns (list_pages, read_page, read_section). wiki_search and wiki_recent drop the noun but remain readable and consistent with the prefix.

Tool Count5/5

Five tools is well-scoped for a wiki reader: discovery, full read, targeted section read, search, and freshness each earn their place without redundancy.

Completeness4/5

The read/discovery lifecycle is well covered (list, read, section, search, recent). If the server is strictly read-only this is complete; a create/update path would be the only plausible gap for an editing-capable wiki.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers