One base, many sources
Raku documentation does not live in one place. The language docs are one repository. Module documentation lives with the modules, across two ecosystems. The examples are a third repository. Each is written by different people, in whatever markup their project already used.
Putting all of that under one roof is what the Raku Knowledge Base is for: one build, one URL scheme, one search. It is not affiliated with the official Raku project; it is an independent base, built and published with Podlite, and it has run on that engine since its first commit in January 2023.
Two things are new this month. Since 22 September 2026 the base has an MCP server, so an AI agent can be pointed at the documentation and answer from it rather than from memory. And each monthly data release now carries an ecosystem report: what appeared, what moved, what version it moved to.
What follows is what is actually in it, measured on 25 September 2026, and what an agent gets when it is pointed at the result.
What an agent can check, not just trust
An agent answers with the same confidence whether it read the documentation or remembered it wrong. Naming a source does not settle that either: a real page can be cited for a claim the page never makes.
So the useful question is narrower. Can the agent hand back the page, the section and the words it leaned on, so all three can be checked?
Here is one run, start to finish.
question How does an action class share state between grammar rules?
page /doc/language/grammars
section Special tokens → "Always succeed" assertion
Enter fullscreen mode Exit fullscreen mode
The section is worth noting. It is not the one whose name sounds closest — Attributes in grammars is the obvious guess, and it is the wrong one. The answer sits two headings away, in the Digifier and Devanagari example:
class Devanagari {
has @!numbers;
method digit ($/) { @!numbers.tail ~= <० १ २ ३ ४ ५ ६ ७ ८ ९>[$/] }
method succ ($) { @!numbers.push: '' }
method TOP ($/) { make @!numbers[^(*-1)] }
}
say Digifier.parse('255 435 777', actions => Devanagari.new).made;
Enter fullscreen mode Exit fullscreen mode
One rule opens the current slot, another extends the most recent one. The state lives on the action object, so the methods cooperate through the same attribute. The limit sits nearby, under Attributes in grammars. Grammar attributes are reachable only from methods. Change one inside a method, and if that method was called from a token, the change reaches only that token’s own match object.
Three things came back, and all three can be opened and read. That is the whole claim.
How retrieval actually works
What sits behind the service is a flat index. A record holds four fields: url, title, top-level section, text. Search scores pages on title and text matches and returns a url, a title, a section name like doc, and a window of text. There is no per-heading retrieval in it.
That section name was readable because it was printed in the page the server handed over. That is a lower bar than structure-aware retrieval, and it is worth stating plainly, because it is the bar that was actually cleared. A page with visible headings, returned whole, is enough to make an answer checkable.
What is in the Raku Knowledge Base
Start with what the engine is pointed at: a tree of 60,501 files. Only 20,469 of them are in a format a page can be made from at all:
Those other 40,032 files never had a chance: test files, JSON, build settings, images, and the project bookkeeping — licences, changelogs, .gitignore. Two thirds of the tree is walked past.
Even inside that fifth, a file is only a candidate. Most Raku programs carry no documentation, and the engine has to open each one to find out. A file earns a page by documenting itself. In a sample of 219 published pages whose source is a Raku program, the rule held without exception: every one carried embedded RakuDoc.
Group those same files by the markup their contents carry, and measure the volume rather than the count:
For the programs only the lines inside a RakuDoc block are counted, not the whole file. Some files could not be matched on disk, so each group total is scaled from the ones that could; coverage ran from 81% to 98%.
Two measures, and they disagree without either being wrong. RakuDoc holds more of the markup lines; Markdown holds more of the characters, because a Markdown line runs about half again as long. Lines say RakuDoc, characters say Markdown, and it is worth knowing which of the two a claim is standing on.
One figure inside that is worth pulling out. Across every Raku program in the tree, 12.9% of all lines are documentation. Among the ones that made it to a page — the documented ones — it is 36.5%. Same markup, different population.
All of it comes out as 10,754 pages with one URL scheme. That is the work Podlite does here, and it happens before any agent connects: a search index does not need a common authoring format, it needs a common published one.
What changed this month
The ecosystem report mentioned above is generated, not written. The one dated 1 September 2026 lists every module added and every module updated since the one before it, each with its version change and a link. Snapshots are compared, the difference is printed. It ranks nothing and scores nothing. It is a change list.
What the MCP server offers
The server went live on 22 September 2026. It speaks the Model Context Protocol, so any client that speaks MCP can use it — Claude Code, Codex, and the rest. Three tools, and that is the whole surface:
- search the document collection available through the service, and get back matching pages with a snippet;
- read one page by url;
- list the top-level sections with a page count for each.
The third is duller than it sounds and more useful than it sounds. It gives an agent the size and shape of what it is about to search before it spends a single query.
That server is open source under the Artistic License 2.0, the same licence as Rakudo. Its code sits in mcp-server in the knowledge base repository, so the retrieval described above can be read rather than taken on trust.
Where it stops
What the server reads is the document collection available through it: the Raku documentation, module documentation from both ecosystems, and the examples repository. It does not automatically include every page the site publishes, and it does not include the tooling around the base.
Search it for MCP material and it returns the Raku modules named MCP, MCP::Server and MCP::Client, plus pages that merely matched on bundle and install. That boundary runs both ways: if the service does not find something, that is a fact about the collection, not about Raku.
Connect an agent
Every data release ships the collection offline with a prebuilt index:
tar xzf raku-kb-mcp-offline.tar.gz
cd raku-kb-mcp && npm install
claude mcp add raku-kb -- node "$PWD/bin/raku-kb-mcp.mjs"
Enter fullscreen mode Exit fullscreen mode
Written for Claude Code, those three lines run as they stand; the same setup runs under Codex with one word changed. Connection commands for the hosted server, and the list of what it will not answer, are on the MCP page.
Ask it the grammar question above, then check its answer: the page it names, the heading it quotes under, and whether the code it shows is the code the page carries.
If the documents are your own
Search only ever repays what publishing put in. For documents to come back with a page and a heading an agent can name, they have to be published with those headings intact and addressable. Podlite for agents is the kit for that side of it: a parser an agent can call instead of guessing at a document’s shape.