Generic LLM Wiki (MCP)

The Problem It Solves

LLMs are confident liars. Ask about niche, structured domains (F5 TMSH, network configs, internal tooling) and you get answers that look right but are subtly wrong in ways that matter. The LLM Wiki pattern solves this by injecting curated, interlinked knowledge into the session so the agent consults the vault before answering instead of guessing from training data.

The problem with previous wiki brain implementations was deployment. Each one was built as a local script running directly on the agent. That works for one agent on one machine. The moment you want another agent on another machine to use the same knowledge base, you're reinstalling, reconfiguring, and hoping both copies stay in sync.

Generic LLM Wiki (MCP) will attempt to fix this by making the wiki brain a standalone service. Any MCP-compatible agent on any machine connects to it over the network. One vault, one server, many agents. It's built. It's ready to test!, but there are only so many hours in the day.

Architecture

MCP Tools

Tool	Description
init_wiki	Bootstrap a wiki instance's name, description, category taxonomy, and guidance. Fails if already initialized.
get_schema	Read the current instance's schema — call this first in any new session.
get_recent_log	Read the most recent entries from the append-only operation log.
list_pages	List all pages, optionally filtered to one category.
read_page	Read a page's frontmatter, content, and version stamp.
write_page	Create or update a page. Updates require expectedVersion from a prior read_page; stale values are rejected with a conflict.
append_log	Append an entry to the log after an ingest/query/lint/edit. Never modifies past entries.
add_raw_source	Add UTF-8 text content into raw/. Create-only — raw/ is immutable. Binary files stay out-of-band.
search	Full-text search across page titles, tags, and bodies.

Why MCP, Not Local

The first version of the Task Tracker MCP server was installed directly on Hermes. It worked. Hermes could call every tool, create tasks, manage projects, all through natural language. The integration was seamless.

It worked. It was also wrong. It was a stepping stone and I learn from my mistakes.

MCP is a client-server protocol. The agent is the client. The MCP server is a separate process that exposes tools over a transport layer. When you configure an MCP server in an agent's config file using stdio transport, you're using a convenience feature for local development. It's not the production deployment model.

The mistake became obvious when I wanted Claude at work to use the same Task Tracker MCP server. Claude is on a thin client. I don't install anything on my work machine. Claude needed to connect to a server running somewhere else, and the server I built couldn't do that.

Generic LLM Wiki (MCP) is built differently from the start. It runs as a Docker container on my home lab infrastructure. Agents connect to it over the network via Streamable HTTP transport. Hermes at home, Claude at work, any future agent, all pointing at the same endpoint, all getting the same grounded knowledge.

Client Setup

Client	Configuration
Claude Code	claude mcp add --transport http my-wiki https://host:3000/mcp --header "Authorization: Bearer <TOKEN>"
Hermes Agent	config.yaml native MCP client — Streamable HTTP transport
Any MCP Client	Point at https://host:3000/mcp with Authorization: Bearer <TOKEN> header

Lessons from the Task Tracker MCP Server

• MCP servers are services, not plugins. Install them where agents can reach them, not inside the agent itself.
• Stdio transport is for development. Production MCP servers should use Streamable HTTP so any client on any machine can connect.
• One server, many agents. The whole point of a protocol is decoupling. Don't re-couple it by embedding the server in one agent's config.
• Containerize early. Docker means the server runs on infrastructure you control, not on whatever machine the agent happens to be on.
• "It works on my machine" is not deployment. If only one agent on one machine can use it, you haven't deployed it. You've hidden it.

Details

Language	TypeScript 91.7% · JavaScript 7.6% · Dockerfile 0.7%
Runtime	Node.js 18+ · Docker Compose recommended
Protocol	MCP (Model Context Protocol) · Streamable HTTP · Stateless
Auth	Bearer token per instance — checked directly, not proxied
License	MIT
Source	GitHub — itlostandfound/mcp-server-llm-wiki
Docker	docker pull itlostandfound/mcp-server-llm-wiki:latest
Predecessors	TMSH LLM Wiki Brain · QKView LLM Wiki Brain
Related	MCP Server for Task Tracker (the project that revealed the architecture mistake)

Control Mechanism

A local LLM Wiki (accessed via direct filesystem reads on the agent's own machine) embeds its operating instructions in a project-level file (like a CLAUDE.md file) that sits alongside the wiki content in the repository root. When Claude Code opens a session in that directory, it reads the file automatically and follows its rules. The instructions travel with the content: same folder, same access, same lifecycle. But this means the instructions only activate when the agent is in that specific project directory — ask a question from anywhere else and the wiki is invisible.

This generic MCP server is different. It has no local filesystem and no project directory. It doesn't — and shouldn't — carry domain-specific instructions inside its codebase. Instead, the operating rules that tell an agent how to use a given wiki instance properly must be delivered through the agent platform's own configuration system:

• Hermes Agent — instructions go into a Skill (a SKILL.md file under ~/.hermes/skills/), loaded by name in the profile's skill list or on demand via skill_view. Skills are global to the profile — they're available in every session, not tied to a project directory. The skill file contains the domain rules, session protocol, page conventions, routing logic, and hard prohibitions that would otherwise live in a CLAUDE.md.
• Claude Code (project-scoped) — instructions go into a .claude/CLAUDE.md at the project root. When Claude opens that directory, it reads the instructions automatically. This is the same pattern as a local filesystem wiki — instructions travel with the project.
• Claude Code (global) — instructions go into ~/.claude/CLAUDE.md, which Claude reads in every session regardless of directory. This is the direct equivalent of a Hermes Skill: always available, routing triggers activate the wiki when the topic matches. This is the preferred pattern for domain wikis you want available everywhere, not just in one project folder.

In all cases, the guidance field stored inside the wiki's own wiki.schema.yaml (set during init_wiki) provides a compact summary of the domain rules that the server itself knows — but this is a summary, not the full operating manual. The full manual (what pages to read at session start, how to route between sibling wikis, what never to do, de-identification rules, etc.) belongs in the Skill or CLAUDE.md, where the agent actually consumes it. The schema guidance and the external skill reinforce each other: the schema tells any connecting agent the domain vocabulary, and the skill tells the configured agent the operational playbook.

Worked Example: F5 BIG-IP Administrator Skill

The BIG-IP Administrator LLM Wiki was the first real deployment of this server. Here is the exact process used to create the control mechanism for agents connecting to it.

1. Define the wiki instance

Deploy the server with a dedicated WIKI_ROOT, bearer token, and domain name. Configure the MCP server in the agent platform so the wiki tools appear with a recognizable prefix. In Hermes, this means adding the server to the profile's config.yaml:

mcp_servers:
  bigipadmin:
    url: "https://mcp-bigipadmin.work.itlostandfound.xyz/mcp"
    headers:
      Authorization: "Bearer <TOKEN>"

In Claude Code:

claude mcp add --transport http bigipadmin https://mcp-bigipadmin.work.itlostandfound.xyz/mcp \
  --header "Authorization: Bearer <TOKEN>"

2. Bootstrap the wiki schema

Connect an agent and call init_wiki with the domain taxonomy, naming patterns, and guidance text. The guidance field in the schema is a compact version of the operating rules — enough for an unconfigured agent to avoid the worst mistakes, but not a substitute for the full skill.

3. Write the Skill (or CLAUDE.md)

The skill contains everything the agent needs to operate correctly: identity, routing rules, page conventions, hard prohibitions, session start protocol, and the MCP tool reference with pitfalls. This is where the CLAUDE.md content goes when there is no project directory.

Hermes Agent: Skill-Based Control

For Hermes, the control mechanism is a Skill — a SKILL.md file in the skill directory, loaded by the agent when the topic matches. The F5 BIG-IP Administrator Wiki skill (f5-bigip-wiki) was created with the following approach:

1. Identify what the CLAUDE.md did — read the existing TMSH CLAUDE.md and extract every operational rule: identity, repository layout, routing, page conventions, domain rules, logging format, session start protocol, and prohibitions.
2. Adapt for MCP access — replace filesystem references (read_file, search_files) with MCP tool calls (mcp_bigipadmin_get_schema, mcp_bigipadmin_list_pages, mcp_bigipadmin_search, mcp_bigipadmin_read_page). The agent never touches files directly — everything goes through the server's tools.
3. Add the tool reference and pitfalls — document all 9 MCP tools with their constraints (e.g., write_page requires expectedVersion, init_wiki is one-shot, append_log replaces manual log editing).
4. Add routing and de-identification rules — this wiki cross-links to the TMSH wiki and must never reference the QKView wiki. Client-identifying data (hostnames, IPs, case IDs) must be de-identified on ingest.

The resulting skill is loaded with skill_view(name='f5-bigip-wiki') and contains the full operating manual for any Hermes agent connecting to this wiki instance.

Example prompt that activates the skill:

Load the f5-bigip-wiki skill, then connect to the BIG-IP Administrator wiki.
Run the session start protocol: call get_schema, list_pages, and get_recent_log.
Report current page count, date of last update, and one-line status.

When this prompt arrives, Hermes loads the skill, calls the MCP tools to orient itself, and reports back — and from that point on, every query, ingest, or edit follows the skill's rules for routing, page conventions, de-identification, and logging. No explicit "use the wiki" instruction needed; the skill system activates it on topic match.

Claude Code: Global Routing vs. Project Scoping

Claude Code has two levels where instructions can live, and they serve different purposes:

• Global ~/.claude/CLAUDE.md — read by Claude in every session, regardless of directory. This is the direct equivalent of a Hermes Skill: always available, always loaded. This is where wiki routing triggers and domain-awareness rules belong.
• Project .claude/CLAUDE.md — read only when Claude opens a session in that specific directory. This is the local-filesystem pattern the TMSH wiki uses.

For an MCP-served wiki, the project-scoped approach requires you to cd into a specific directory every time you want wiki access. That works, but it limits the wiki to sessions that happen to start in that folder. The more powerful pattern is global scope — putting the routing logic in ~/.claude/CLAUDE.md so that Claude knows the wiki exists no matter what project you're working in.

Building the Skill: Global Routing + Full Operating Rules

The process mirrors the Hermes skill creation, but the output goes into Claude's global instruction file instead of a Hermes skill directory. Steps 1–4 are identical to the Hermes process (extract rules, adapt for MCP, add tool reference, add routing/de-identification). Step 5 is unique to Claude Code:

5. Add routing triggers at the global level — in ~/.claude/CLAUDE.md, add a directive that tells Claude when to activate this knowledge:

## Wiki Routing

When the user asks about F5 BIG-IP administration, LTM, GTM/DNS, APM, ASM/AWAF, AFM,
or BIG-IP troubleshooting, connect to the BIG-IP Administrator wiki (MCP server: bigipadmin).
Run the session start protocol: get_schema, list_pages, get_recent_log. Then follow the
BIG-IP Administrator Wiki operating rules below for all subsequent queries and edits.

When the user asks about TMSH syntax or shell commands, connect to the TMSH wiki
(MCP server: tmsh). Follow the TMSH Wiki operating rules for syntax queries only —
never copy TMSH syntax into Administrator wiki pages.

This global routing trigger means Claude doesn't need to be told "use the wiki" — it recognizes the domain from the question and activates the right wiki automatically, exactly like a Hermes Skill that's loaded on topic match.

Two scoping strategies compared

Strategy	File	Scope	When it loads	Best for
Project-scoped	.claude/CLAUDE.md in project root	That project only	When Claude opens that directory	Wikis tied to a specific codebase
Global	~/.claude/CLAUDE.md	All sessions	Every session, always	Domain wikis you want available everywhere

For a knowledge base like BIG-IP Administrator, global scoping is almost always the right choice. You want Claude to know the wiki exists whether you're in /projects/networking/, /tmp/, or your home directory. The routing trigger ensures it only activates when the topic is relevant — it doesn't pollute unrelated conversations.

Example prompt with global routing (no project scoping needed):

What's the difference between an LTM virtual server's source-address-translation
and SNAT pool?

Claude sees the domain trigger in its global CLAUDE.md, recognizes this as a BIG-IP question, connects to the bigipadmin MCP server, runs the session start protocol, searches for relevant pages, and answers with citations from the wiki. No explicit "use the wiki" instruction needed.

Summary: Where the Instructions Live

Agent Platform	Instruction File	Location	Scope	Delivery
Local filesystem wiki	CLAUDE.md	Project repo root	That project only	Read automatically by Claude Code at session start
Hermes Agent (remote MCP)	SKILL.md	~/.hermes/skills/<category>/<name>/SKILL.md	Global (all sessions for that profile)	Loaded by name via skill system, on demand or in profile config
Claude Code (project-scoped)	.claude/CLAUDE.md	Project directory root	That project only	Read automatically at session start
Claude Code (global)	~/.claude/CLAUDE.md	User's home Claude config	All sessions, always	Read automatically in every session; routing triggers activate the wiki on topic match

The generic MCP server provides the transport and enforcement (tools, auth, optimistic concurrency, structural validation). The Skill or CLAUDE.md provides the domain operating rules (what to write, how to route, what never to do). The guidance field in wiki.schema.yaml provides a compact summary that any connecting agent can read — but it is not a replacement for the full control mechanism. Together, these three layers ensure that every agent connecting to a wiki instance operates correctly, regardless of which agent platform it runs on.

The key insight: both Hermes and Claude Code need essentially the same content — domain identity, routing rules, page conventions, prohibitions, session protocol, tool reference, and pitfalls. The delivery mechanism differs (Skill vs. CLAUDE.md, on-demand loading vs. global routing trigger), but the knowledge is portable. A Hermes skill can be translated to a Claude CLAUDE.md section and vice versa with minimal adaptation (mainly MCP tool name prefixes and the routing trigger format).

Project Status

Production-ready for single-instance deployments and is released on Docker Hub.