KnowledgeBaseMCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KB_ROOT | No | The path to the knowledgebase or bundle. Defaults to the current directory when not set. | |
| KB_USER | No | Prefills the reviewer id in verify's confirmation prompt. |
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 |
|---|---|
| lintA | Check the bundle against OKF v0.2. Run it before and after any change, and in CI.
Each finding: kind; scope (okf = the spec, house = hygiene); severity (error fails, warning does not); file;
message; fix (what to do); fixable (true: |
| baselineA | Snapshot today's lint findings so CI fails only on new ones ( |
| statusA | Bundle summary: concepts by type, by status (absent = stable, §5.4), by trust tier (§5.3), stale count
( |
| listA | Concepts, filtered by type, tag, status (draft | stable | deprecated; absent = stable), trust tier (unverified | machine-confirmed | human-reviewed) or stale=true. The review worklist after an ingest: status=draft tier=unverified. |
| linksB | Edges of one concept (§6): |
| searchC | Case-insensitive text search over concepts; each hit is {bundle, file, line, text}. |
| getA | One .md file of a bundle (a concept, index.md or log.md), or several at once with files=[...]. A
missing index.md is synthesized from frontmatter (§8; |
| initA | Start a bundle: a root index.md declaring okf_version "0.2" with a generated document list, and a
§9 log.md. Refuses if index.md exists. Then add concepts (any .md with |
| fixA | Mechanical repairs, nothing that needs judgment: strip frontmatter from index.md files (§8; the root
keeps okf_version), rebuild generated index lists, give each tag its most common spelling, and put log.md
sections and entries back in order after a merge (§9).
apply=False shows the diff (CLI exit 1 if there is work); apply=True writes, re-lints and returns |
| indexA | Rebuild generated document lists from frontmatter (title, type, tags, |
| setA | Edit frontmatter on one or many concepts by text; every other key stays byte for byte (§4.1). fields: {key: value}; null drops a key. Checks type, status (§5.4), stale_after (§5.5, ISO with a UTC offset) and tags (a list). generated, verified and sources have their own tools (provenance, verify, cite). apply=False shows the diff. |
| createA | Create a concept with valid OKF frontmatter (§4.1): type, title, description, resource, tags, status, and
|
| moveA | Move or rename a concept and rewrite every link to it (relative and /-absolute, §6.1, in concepts,
index.md and log.md), plus the moved concept's own relative links. Stays inside one bundle; |
| logA | History, newest first. With file: the entries in every log.md over that concept that link to it (§9),
and the git commits that changed it. Without: the bundle's recent entries from all its log.md files.
|
| recordA | Write a §9 entry, |
| verifyA | Record a §5.2 |
| citeA | Record where a fact came from as a §5.1 |
| recheck_planA | Facts due a re-check: |
| recheck_applyA | Record a re-check, after you compared each due source with the claims citing it (recheck_plan) and
corrected any that changed; git keeps what they said before. Each result is {bundle?, file, id?}, or one
as file= and id=; no id = every source on that concept. retrieved_at moves to now. by (at the terminal,
--attest) also adds a §5.2 |
| provenanceA | Fill a missing |
| splitB | Make a directory its own bundle (§3): its index.md declares okf_version "0.2" (created if missing, with
a generated list), a log.md is started, and |
| migrateA | Move a concept to another bundle of the knowledgebase ( |
| renameA | Rename or move a bundle within the knowledgebase (§3): bundle= (default: where the user is) to |
| archiveA | Move a concept, or (no file) the whole bundle= named, into the knowledgebase's archive bundle ( |
| unarchiveA | Put an archived concept or bundle back where it came from: path is its place in the archive, / for a concept (its bundle must exist) or for a whole bundle (its index.md declares okf_version again). apply=False shows the plan and diff. |
| upgradeA | OKF v0.1 to v0.2 (§13). A legacy |
| heatmapB | The hottest concepts and who heats them, from git history (.mailmap names). files: commits that changed
each concept in the last |
| webA | The link graph (§6): which concepts link to ( |
| bundlesC | Bundle roots under a directory: each index.md declaring okf_version (§12). A bundle without that declaration looks like any folder; pass it as bundle= directly. |
| ingestA | Bring markdown from a local directory or git clone into an OKF bundle, or adopt it in place (bundle =
source; needs a clean git tree, so the diff is the review). Each file gets frontmatter: |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| okf-spec | The OKF v0.2 specification (SPEC.md) |
TDQS
Scored across 30 tools
Most tools are distinct, but several lifecycle tools overlap conceptually: move vs migrate vs rename vs split vs archive/unarchive, and verify vs cite vs recheck_apply vs provenance. The descriptions explicitly cross-reference each other, which helps, but an agent could still misselect among these closely related bundle/concept operations.
Names are all lowercase and mostly single words, but they mix verbs (search, create, verify, archive) with nouns (status, links, baseline, heatmap, bundles) rather than following a predictable verb_noun pattern. The recheck_plan/recheck_apply pair is the only notable compound style, making the set readable but not consistently patterned.
30 tools is heavy for a knowledge-base server, well beyond the 3-15 well-scoped range. The domain is broad, and many tools are specialized, but the surface feels overloaded with migration, linting, graph, provenance, and lifecycle operations that could likely be consolidated.
The surface covers creation, reading, frontmatter editing, linking, linting, fixing, provenance, verification, archiving, migration, and ingestion, which is extensive. However, there is no tool for editing concept body content after creation and no direct delete operation, leaving notable gaps for core authoring workflows.