mcp-llm-wiki
Related Servers
Alternatives to mcp-llm-wiki
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenancePersistent markdown wiki for your AI agent, built on Karpathy's LLM wiki gist.62 PyPI1MIT
- AlicenseNot gradedqualityFmaintenanceEnables creation of persistent, compounding knowledge bases using Karpathy's LLM Wiki pattern with LLM-maintained markdown wikis. Supports automated ingestion, cross-referencing, synthesis, and linting of sources as an alternative to traditional RAG systems.61MIT
- FlicenseAqualityAmaintenanceEnables agents to run hybrid dense and BM25 search over a local folder of Markdown files, read and write notes, and trigger reindexing as the folder changes. It also injects the most relevant sections into each prompt automatically and runs entirely locally with a bundled embedding model.12-
- FlicenseNot gradedqualityBmaintenanceTurns a user's own Markdown wiki into a locally indexed knowledge base, enabling semantic search, per-page retrieval, source listing, and citation-backed RAG question answering. All embedding and generation run through a local Ollama instance, so queries and documents never leave the machine.1-
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to build and maintain a shared, git-backed Markdown wiki: they search, file, update and link notes with YAML frontmatter, keep verbatim sources, and optionally read code repos, so knowledge one assistant records is available to all the others. Runs without LLM calls, embeddings or a database, with the vault's own files defining page types, instructions and tools.MIT
- AlicenseBqualityBmaintenanceEnables AI agents to securely read, search, and write to a local Markdown knowledge base with hybrid RAG retrieval, privacy zones, hash-locked writes, audit logging, and rollback-safe archiving.13MIT
TDQS
Scored across 18 tools
Each wiki_* and raw_* tool targets a distinct operation/resource: search, reads, lists, mutations, index maintenance, link analysis, and linting. Even close pairs like wiki_write_page vs wiki_patch_page and wiki_update_index vs wiki_reindex are clearly separated by write-versus-partial-edit and catalogue-versus-search-index semantics.
The dominant pattern is prefix + verb_noun (wiki_list_pages, wiki_write_page, wiki_read_page), with raw_list/raw_read forming a consistent raw_* subfamily. Minor deviations like wiki_backlinks (noun instead of verb) and wiki_index_status vs wiki_reindex/update_index break the pattern slightly, but the convention is still predictable.
At 18 tools the server is above the typical 3-15 sweet spot, but the count is justified by the breadth of the wiki lifecycle: search, CRUD, structure listing, index maintenance, backlinks, linting, and logging. A few tools could theoretically be merged, but each has a distinct purpose.
The server covers the full wiki lifecycle: search, read, create, overwrite, patch, move, delete, plus supporting functions like backlinks, index generation, lint, and reindexing. The read-only RAW layer is intentionally separate and documented, and no critical workflow appears to be a dead end.