librarian-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIBRARIAN_URL | No | Engine base URL. Use any port you run the engine on. | http://127.0.0.1:8000 |
| LIBRARIAN_PROJECT | No | Optional project tag sent with each call. | |
| CLAUDE_CODE_SESSION_ID | No | Used as the session id when present, otherwise a random id is generated per launch. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| librarian_locateA | Find the EXACT, current location of something on this PC (file:line) - a
function, route, config key, catalog entry, tool, or file. AI sessions should
USE THIS BEFORE grep-scanning the codebase; the answer is generated from a fresh code index,
so line numbers are current and a [changed] flag warns when a file was just
edited. Pass a natural query like 'where is the catalog search code' or
'route that handles checkout'. |
| librarian_briefA | START-OF-TASK BRIEF for AI sessions. Call this FIRST when beginning any non-trivial task:
pass the task/goal and the librarian reviews everything that already exists on
this PC and tells you what's relevant, HOW it helps here, what to reuse, and -
honestly - what we DON'T have. Lets you start with most of what you need
instead of hunting. If we have nothing, it says so plainly. If the coordinating session registered guidance (librarian_guide), the answer already accounts for it and shows its version. |
| librarian_askA | Ask the librarian a question about this PC's systems: what exists, where it
lives, which tool to use, or how something works. Returns a grounded answer
(WHAT / WHERE file:line / TOOLS / NEXT) over the whole-PC corpus (catalog +
tools + machine map + project memory + a live code index). AI sessions should
USE THIS instead of guessing, saying they can't find something, or calling a
premium model just to rediscover local context. If the coordinating session registered guidance (librarian_guide), the answer already accounts for it and shows its version. |
| librarian_dependsA | Show what depends on / connects to a catalog entry id (the 'what breaks if
I change X' graph). Use after librarian_locate returns an [entry] to see its
blast radius. Pass the entry id, e.g. 'payments-module'. |
| librarian_statusA | Health of the librarian: catalog availability + index counts (files,
symbols, routes, config keys, entries, changed files) + index age. |
| librarian_discussA | DISCUSS with the librarian - a running two-way conversation (it remembers
your prior turns). Use for hashing out a task together: verify your
understanding of the project, ask about paths/tools, and ANSWER the questions
it asks back (its ASK: line). Multiple trips are encouraged - keep going until
both sides agree the picture is complete. Pass reset=true to start a fresh
discussion for a new topic. Threads are per caller: workers do not see the
the coordinator's turns (and reset clears only your own thread). |
| librarian_guideA | For the coordinating session, before delegating to workers: register this session's intent so every worker's librarian_brief / librarian_ask / librarian_discuss is steered by it (their answers show the guidance version). Freeform intent about code/projects only - never client names, emails, health, or personal data (the engine rejects PII). Replaced on every call (version bumps); expires after 6h. reset=true clears it first (reset with empty text = just clear). Re-guide per phase.
|
| librarian_session_logB | For the coordinating session when judging a worker report: what this session's
workers (and the coordinator) asked the librarian and what they were served - one
line per interaction, newest last, with caller, kind, guidance version,
withheld-hit count (xN, only when exclusions filtered something), query,
cite count and provider. |
| librarian_tellA | GIVE the librarian knowledge it doesn't have - something you built or
discovered this session, a decision made, a path/tool it didn't know, or
context you think matters even if the librarian might not. It is ALWAYS
accepted (never rejected as irrelevant) and offered to future sessions.
Use whenever you know something the librarian got wrong or lacked. |
| librarian_gapA | REPORT a gap - the librarian was missing something you needed (and you
don't have the answer yourself, otherwise use librarian_tell). It goes on the
librarian's gap ledger; every review it re-hunts open gaps and escalates the
still-unanswerable ones to the operator. This is how the librarian learns what to
go back and get. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools are distinct (locate, depends, status, tell, gap, guide, session_log), but librarian_brief, librarian_ask, and librarian_discuss all retrieve context from the same corpus and their boundaries are fuzzy—an agent could easily pick the wrong one. Descriptions help (brief=start-of-task, discuss=multi-turn), but the overlap remains real.
All tools share the librarian_ prefix with short, readable suffixes, which makes them easy to scan. However, suffixes mix verbs and nouns (locate, ask, tell vs. status, gap, session_log), so it's not a strict verb_noun pattern.
10 tools is well within a healthy range for a knowledge/retrieval server. A couple (guide, session_log) are coordinator-only and add conceptual surface, but each serves a defined role.
The surface covers retrieval (locate/ask/brief/discuss), dependency graph, health, knowledge contribution (tell), gap reporting, and coordination (guide/session_log) — a full lifecycle. Minor gaps: no explicit list/update/delete of catalog entries, so knowledge can be added but not curated or removed.