Plug the index into an AI assistant, and it answers your questions about these documents by quoting them, rather than from memory. This page has the whole setup, from a settings menu or from a command line. Four tools, read only, no account and no key.
MCP, the Model Context Protocol, is a standard way to let an assistant look something up in another service while it answers you. Connect the index and your assistant stops answering about these documents from memory: it quotes the passages a document actually gives on a subject, and says where in the document each one sits, so you can check the answer rather than trust it.
The index speaks it at one address:
/api/mcpThere is nothing to sign in to and no key to obtain. The index only reads: it can be asked what the documents say, and it cannot be asked to change anything. Everything it serves is the published index, the same data the spec reader is built from, so a call reads what the site shows and nothing else.
One command, in the client you already use. Each was checked against its publisher’s own documentation as of September 2026.
claude mcp add --transport http ai-character-index /api/mcpAdd --scope user to have it in every project rather than only this one. Type
/mcp inside Claude Code to see that it connected.
codex mcp add ai-character-index --url /api/mcpcodex mcp list shows what is configured.
gemini mcp add --transport http ai-character-index /api/mcp{
"mcpServers": {
"ai-character-index": {
"type": "http",
"url": "/api/mcp"
}
}
}Clients spell this differently, so prefer the client’s own command where there is one: it writes the shape that client expects.
Once it is connected, ask in ordinary words. For instance:
The index carries thirteen behaviours as of September 2026, and the assistant will name the ones it used and quote from the documents it read.
Four, and all of them read. Four words recur below. A behaviour is one thing a
document might commit a model to, such as deferring to a user’s own decisions. A
locator is the address of a quote inside a document, naming the document, its version,
the section and the sentences, as in
openai--model-spec@2026-08-18 > #scope_of_autonomy > ¶14. The
panel is the three frontier models that read every document for every behaviour and
marked the passages. A depth is the score those judges give a document for a behaviour,
from 0, absent, to 4, rules with worked examples: it says how much the document gives an
evaluation to work with, not how much the lab cares.
about. What the index is, what it does not report, and what the other three tools return, in one answer meant to be read before anything else is asked. No arguments. It names the documents, the behaviours and the sections they sit in, the panel that judged and the publication being served, each read from that publication when you ask rather than written into this page, so it is current whenever it is called. Most assistants never show a server’s own instructions to the model, so this is the same text where the model will see it.
list_model_specs. Every specification the current publication carries: id,
laboratory, title, version, source URL, how many behaviours were judged against it and how
many passages it holds. No arguments. It does not return the specification text, which runs to
hundreds of kilobytes; the source URL is in the answer. Each specification is one version, and
its id reads <lab>--<document>@<version>, such as
openai--model-spec@2026-08-18, which is also the head of every locator into
it.
list_behaviours. Every behaviour the publication shows, with the section it is grouped in, the brief the judge panel was given, the boundary of the construct and where the definition came from. Each one also carries, per specification, how many passages it has, the strongest band any of them reaches and the panel’s mean depth. No arguments. The slugs it returns are what the next tool takes.
retrieve_passages. The passages of a specification that bear on a behaviour, quoted verbatim and located. Each one comes back with its locator, its quote, the band it sits in and the verdict every judge gave it.
null.defining is the document’s fullest
statement of the behaviour, core establishes it there, related
bears on it without establishing it. Each means that band and stronger.
related by default, so every band comes back, which is what the spec
reader shows before you touch a toggle. Every passage carries its strength, so pass
core or defining to narrow the answer. A judge’s own
verdict of adjacent is the band named related here.next_cursor of the previous page. It names the
publication it was issued against, so a walk that spans a new publication stops rather
than drifting across two indexes.Where a judge could not answer a pair at all and a model declared for its seat judged in
its place, the pair carries substitutions, naming the seat, the substitute and the
reason, in both list_behaviours and retrieve_passages. That
seat’s verdicts and depth are then the substitute’s.
A pair with no passages says so rather than disappearing. Absence of coverage is a result of the index, not a hole in it.