kb-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KNOWLEDGE_BASE_ROOT | No | The path to the knowledge base vault root, used as fallback if --root is not provided. |
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 |
|---|---|
| kb_searchB | Lexical full-text search over index.md and wiki pages. Returns ranked results with page id, title, score, matched terms, and a prose snippet. |
| kb_read_pageB | Read one page by id (e.g. 'wiki/overview'). Returns its markdown text, resolved outgoing links, and backlinks. |
| kb_graph_summaryC | Graph statistics and the index.md category structure. |
| kb_hygieneC | Broken links, missing-page targets, and orphan pages. |
| kb_build_contextB | Assemble a navigable starting set for a query. Returns the top matching pages with snippets plus their immediate graph neighbours, to decide what to read next. |
| kb_verifyB | Phase-1 audit: graph stats, graph hygiene, and citation hygiene. Citation hygiene reports uncited wiki pages, source pages with no raw evidence, and broken raw/ citations. |
| kb_propose_changesA | Preview a change set without writing. Each change is {op:'write_page', page_id, text} | {op:'write_index', text} | {op:'add_index_entry', category, entry} | {op:'append_log', text}. Prefer add_index_entry for a new page: it adds one catalog line without reading or rewriting index.md. Returns a unified diff and create/update/append action per operation, plus verification before and after the change as it would land (with the warning delta). Nothing is written. |
| kb_apply_changesA | Commit a change set to disk, then re-verify. Same change shape as kb_propose_changes. Writes go through the guarded vault writers: raw/ is never written and log.md is append-only. Returns the applied operations and the post-apply verification. |
| kb_fetch_queriesA | Read back recorded queries (kb_search / kb_build_context calls). Returns the most recent |
| kb_suggest_researchA | Tell the owner's research process about a gap in the knowledge base. Call this when the knowledge base could not answer something your work
needed (kind "gap"), or when a subject the owner's work keeps touching
should be in the knowledge base (kind "subject"). One suggestion per gap.
Phrase |
| kb_fetch_suggestionsA | Read back recorded research suggestions (kb_suggest_research calls). Returns the most recent |
| kb_reloadB | Rebuild the in-memory graph and search index from disk. |
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 12 tools
Most tools target clearly distinct operations (search, read, propose/apply changes, fetch queries/suggestions), and the propose/apply and fetch_queries/fetch_suggestions pairs are explicitly differentiated. However, kb_verify overlaps with the combined functionality of kb_graph_summary and kb_hygiene, so an agent may hesitate over which audit-style tool to call first.
Every tool uses the same kb_ prefix followed by a verb_noun or verb_noun_phrase pattern in snake_case (kb_search, kb_read_page, kb_propose_changes, kb_fetch_queries). There are no mixed conventions or stray camelCase names, making the set highly predictable.
With 12 tools, the set is well within a reasonable range for a knowledge-base server and each tool covers a distinct phase of the workflow (search, read, inspect, verify, propose, apply, record, reload). No tool appears redundant or purely filler.
The surface covers search, read, graph inspection, hygiene/citation audits, guarded write flows, query/suggestion recording, and index reload, which is close to full lifecycle coverage for a safe KB. A minor gap is the absence of a direct 'list all pages' or 'get raw index' tool, though kb_graph_summary and kb_search provide workarounds.