Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@library-of-babel-mcp where in the library is the text 'the quick brown fox'?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server granting access to the Library of Babel, the largest knowledge base in the known universe.
No install step — npx fetches the server on demand.
In Claude Code:
claude mcp add library-of-babel -- npx -y library-of-babel-mcpIn Claude Desktop or any other MCP client, add this to your MCP config (e.g.
claude_desktop_config.json):
{
"mcpServers": {
"library-of-babel": {
"command": "npx",
"args": ["-y", "library-of-babel-mcp"]
}
}
}Then restart the client. You should see the four tools listed below.
Related MCP server: MCP Open Library & File Search Server
Alphabet: 29 symbols — a-z, comma, space, period.
Page length: 3200 characters (40 lines x 80 chars).
Address: hexagon (base-36 string, ~3004 digits), wall (1-4),
shelf (1-5), volume (1-32), page (1-410) — 262,400 pages per hexagon.
Library size: 29^3200 pages, a 4680-digit number.
The library is a bijection between addresses and page contents, following the structure libraryofbabel.info uses. There is no PRNG and no special-cased slot: every address maps to exactly one page, every possible page maps back to exactly one address, and the mapping inverts in both directions.
Flatten the address into a single integer index.
Scramble it: content = (index * MULTIPLIER) mod N, where N = 29^3200.
Write content out as 3200 base-29 digits — that's the page text.
MULTIPLIER is coprime to N, so step 2 is a permutation of the entire space
and its inverse is another multiplication by MULTIPLIER⁻¹ mod N (computed by
Hensel lifting, since N is a prime power). So searching means: build the
exact page you want — your text plus padding — read it as a base-29 number,
multiply by the inverse, and unpack the index into coordinates. The page really
is at that address. Nothing is stored; nothing is scanned.
Because padding and offset are part of the page, changing either gives you a genuinely different page at a different address.
The structure and observable behaviour match the real site. The particular
permutation does not: libraryofbabel.info's own constants are deliberately
unpublished — the author's reference
repo documents
the method (an invertible LCG plus xorshift scrambling) but withholds its m,
a, and c. Addresses produced here are therefore not portable to that
site, and vice versa.
get_page(hexagon, wall, shelf, volume, page) — read the text at an address.
search_text(text, padding, offset) — find the address of a page containing
your text. padding is "spaces" (default) or "random"; offset is a
character position or "random". Max 3200 chars; input is lowercased and
restricted to the library's alphabet.
lookup_page(text) — the exact inverse of get_page: give it a full
3200-character page, get back its address.
random_page() — jump to a uniformly random address.
LOB_API_KEY — leave empty for provisional guest access, until you have
located the volume containing your API key.
npm install
npm run build
node dist/index.jsIt speaks MCP over stdio, so it expects a client on the other end — it will just sit there logging "Library of Babel MCP server running on stdio" to stderr, which is normal.
To point a client at the checkout instead of the published package, use the built entrypoint:
{
"mcpServers": {
"library-of-babel": {
"command": "node",
"args": ["/absolute/path/to/library-of-babel-mcp/dist/index.js"]
}
}
}Retrieve the exact text on a page at a given address in the Library of Babel. Every address always returns the same content (the library never changes). Coordinates: hexagon (base-36 string id), wall (1-4), shelf (1-5), volume (1-32), page (1-410). Almost every address is gibberish — meaningful pages are found via search_text, not by browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| wall | No | ||
| shelf | No | ||
| volume | No | ||
| hexagon | Yes | Base-36 hexagon id (0-9, a-z), any length |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: deterministic results ('Every address always returns the same content') and that most addresses contain gibberish. It does not mention error handling or output format, but for a simple read operation these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words: purpose, determinism, and coordinate/usage guidance. Each sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides a solid amount of context: purpose, coordinate ranges, deterministic behavior, and tool-selection guidance. It leaves out explicit failure semantics and return value details, but it is largely complete for deterministic page retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (hexagon), so the description compensates by listing all five coordinates with their ranges and explaining hexagon as a base-36 string id. This adds meaningful context beyond the raw schema, though it stops short of mentioning default values for optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve the exact text') and resource ('a page at a given address in the Library of Babel'), making the tool's function immediately clear. It also distinguishes itself from siblings like search_text by emphasizing direct address-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Almost every address is gibberish — meaningful pages are found via search_text, not by browsing.' This names an alternative tool and states when not to use get_page, while also implying it should be used for direct, known-address retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a complete 3200-character page, return the address it lives at. This is the exact inverse of get_page: the text must be exactly 3200 characters drawn from the library's alphabet (a-z, comma, space, period). For partial text, use search_text instead.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The full 3200-character page content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral constraints: exact 3200-character input and alphabet limitations (a-z, comma, space, period), making it an exact-match operation. However, it does not describe error handling or return format for non-matching text, which would be useful for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the core function, and the second provides inverse relationship and alternative. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool with no output schema, the description is complete: it gives purpose, input constraints, related tools, and an alternative for partial text. The return value (address) is clearly stated, and there are no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'text' parameter with a basic description, but the tool description adds critical semantic constraints: exact length and allowed character set. This goes beyond the schema's 'full page content' and significantly aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact function: given a 3200-character page, return its address. It uses specific verbs (return, lives at) and clearly distinguishes itself from siblings by describing the inverse of get_page and pointing to search_text for partial text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for complete exact pages, and explicitly instructs 'For partial text, use search_text instead.' It also implies the relationship with get_page as the inverse operation, giving a clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Jump to a uniformly random address in the Library of Babel and return its content. Almost always gibberish — that's the point.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the uniform randomness and the expected gibberish content, providing a clear expectation of output quality. However, it does not elaborate on potential edge cases or the exact nature of 'content', but this is sufficient for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every word adds value. The playful tone is appropriate and does not compromise clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description fully covers what the tool does, how it behaves (uniform randomness), and what to expect (gibberish). It is complete and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema already reflects this with 100% coverage. No parameter explanations are needed, and the description appropriately focuses on the tool's behavior rather than inputs. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Jump to a uniformly random address'), the resource ('Library of Babel'), and the result ('return its content'). It distinguishes itself from sibling tools like get_page and search_text by emphasizing randomness, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for random sampling ('Jump to a uniformly random address') but does not explicitly state when to use this tool versus alternatives or when not to use it. The context of siblings suggests it is for random discovery, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the address of a page containing the given text (up to 3200 characters). The Library of Babel already contains every possible page, so 'search' doesn't scan anything: it constructs the exact page you asked for and inverts the address mapping to learn where that page sits. The returned address is a genuine location — get_page on it returns your text. Padding and offset are part of the page, so changing either yields a different address. Text is lowercased and restricted to the library's 29-symbol alphabet (a-z, comma, space, period); unsupported characters are dropped or converted to spaces.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to locate in the library | |
| offset | No | Where the text starts on the page: a character offset, or "random" | |
| padding | No | Fill the rest of the page with spaces, or with random characters | spaces |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses that no actual scanning occurs, text is lowercased and restricted to a 29-symbol alphabet, unsupported characters are dropped/converted, and padding/offset affect the resulting address. This goes beyond a simple read/write hint and provides operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loads the purpose, and every sentence adds value. It is somewhat dense as a single paragraph but remains appropriate in length and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return value (an address), how to validate it (get_page returns your text), and the behavioral implications of parameters. For a tool with three parameters and no output schema, this is thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds meaningful semantics: the text length limit, the alphabet restriction, character handling, and that offset/padding are part of the page and thus change the address. This enriches understanding beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Find the address of a page containing the given text.' It also distinguishes itself from siblings by explaining that it constructs and inverts the address mapping rather than scanning, making its unique functionality clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: you want an address for a page containing given text, and get_page on that address returns the text. It implies the relationship with sibling tools but does not explicitly list alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0get_pagelookup_pagerandom_pagesearch_textScored across 4 tools
Each tool has a clearly distinct purpose: get_page retrieves content by address, random_page fetches a random page, search_text finds an address for arbitrary text, and lookup_page is the exact inverse of get_page. There is no overlap or ambiguity between them.
All tool names follow the same snake_case pattern with two words, and the naming clearly reflects their function (get_page, random_page, search_text, lookup_page). The format is consistent and predictable.
With 4 tools, the server is well-scoped for the Library of Babel concept. Each tool earns its place, covering the essential operations without unnecessary bloat or missing functionality.
The tool set provides complete coverage for the domain: retrieving pages, exploring randomly, searching for text, and mapping pages back to addresses. There are no obvious gaps or dead ends for the intended use case.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for Russian books search, details, and recommendation candidates.
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
