librarian
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIBRARIAN_DATA | No | Path to the data directory where the pack's database and cached responses are stored. | ./data |
| LIBRARIAN_EMBED_DIM | No | Embedding dimension for the configured embedding model. | 768 |
| LIBRARIAN_OLLAMA_URL | No | URL of the Ollama server used for semantic search embeddings. | http://localhost:11434 |
| LIBRARIAN_EMBED_MODEL | No | Embedding model name used by Ollama for semantic search. | nomic-embed-text |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Local search index: Esri ArcGIS Enterprise. ArcGIS Enterprise (Portal, Server, Data Store, Web Adaptor, enterprise geodatabases): architecture, installation, upgrades, administration and troubleshooting, mostly from practitioner Q&A. Workflow: call outline once to see what is covered; search for candidate passages; fetch the best hits (scope='thread' for a whole discussion) before answering. Weigh sources: results flagged 'official' (vendor docs, knowledge base, bug reports) outrank forum posts; among forum posts prefer accepted answers, vendor staff, recognized experts, and posts on the user's version. Say when sources disagree, when advice is for a different version, or when nothing relevant was found. Cite every claim by chunk_id and URL.
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchA | Hybrid keyword + semantic search over the local index, reranked for quality and version. Write one specific question or symptom per call; include error text and product names. If the user's question spans several distinct topics, make one call per topic. Good: 'webgisdr backup fails unable to generate token 11.3'; 'federate ArcGIS Server with Portal certificate error'; 'Data Store upgrade 11.5 to 12.1 validation fails'. Bad: 'portal'; 'upgrade, federation, SSL and backups in 11.x'. If two or three rephrased searches find nothing relevant, stop and say so rather than searching indefinitely. Returns compact results: chunk_id (stable, citable), date, versions, source/kind, flags (official, accepted, top_voted, vendor_staff, expert), score, approximate tokens, URL, snippet. Args:
query: the question or symptom, e.g. an error message plus the component involved.
limit: max results (1-50).
version: the user's product version, e.g. "11.3" or "10.9.1" ("11" = any 11.x).
Pass it whenever known: matching versions rank higher.
version_mode: "boost" (default) ranks matching versions higher; "filter" keeps only them
(drops the many posts that never state a version, so use sparingly).
date_from / date_to: ISO dates (YYYY-MM-DD) bounding the post date.
source_type: e.g. "docs", "kb", "bug", "forum" (see |
| fetchA | Full text of a result as clean markdown, with citation metadata. Args: chunk_id: id from search results, e.g. "gis_se:a:12345#c0". scope: "chunk" (just that passage), "document" (the whole post or page, default), or "thread" (question plus replies: accepted answer, vendor staff, experts and top-voted first). max_tokens: approximate output budget (default 6000). Content beyond it is listed by id so you can fetch specific parts; raise it only when you need the whole thread. |
| outlineA | Map of the index: sources, boards/tags, date ranges and version coverage. Read this first to learn what the index can answer and which terms and versions it covers. Args: source: limit to one source id. |
| index_infoB | What this index covers: sources, document counts, date ranges, version tag counts. |
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 4 tools
search and fetch are clearly distinct (find vs. read), but outline and index_info overlap heavily — both are described as telling you 'what the index covers' (sources, dates, version coverage), with only counts vs. boards/terms differentiating them. An agent can plausibly pick the wrong one of the pair when it just wants to know what's available.
Two tools are bare verbs (search, fetch), one is a standalone noun (outline), and one uses a noun_noun form with an underscore (index_info). All are readable and snake_case-compatible, but there is no single consistent pattern across the set.
Four tools is lean and appropriate for a retrieval server: discover, search, fetch, plus one metadata helper. The only quibble is that the metadata helper is duplicated (outline vs. index_info), so one slot is arguably wasted.
The core retrieval lifecycle — orient on the index, search with filters, fetch full documents/threads with citation metadata — is fully covered with no dead ends. Minor gaps: no way to enumerate chunks within a document or browse a source without a query, though search filters partially compensate.