
Gnosis MCP
io.github.nicholasglazerPublished by GitHub account nicholasglazerv0.17.5Updated Oct 25, 2026
Zero-config MCP server for searchable documentation. SQLite or PostgreSQL.
Overview
A local, zero-config MCP server that indexes your own documentation into SQLite or PostgreSQL so an assistant can search it instead of reading whole files.
- What you can do
- Search documentation by keyword or hybrid semantic plus keyword search, with highlighted excerpts and token savings per lookup. Retrieve a full document by path, follow related and linked documents, and inspect knowledge graph statistics. Search indexed git commit history and get a usage-weighted context summary. Create, replace, delete documents and change their metadata, only when write mode is enabled.
- When to use it
- Useful when an assistant repeatedly needs answers from a local docs corpus, such as API references, architecture notes or project documentation, and you want grounded answers with fewer tokens than pasting files. Also fits teams that want retrieval over git history or crawled documentation sites.
- Requirements
- Runs as a local Python process, installed from PyPI (pip or uvx) or as a Docker image. SQLite is the default backend and needs no configuration; PostgreSQL with pgvector is optional. Keyword search needs SQLite FTS5. Semantic search needs the optional embeddings extra; local ONNX models download on first run, and remote providers such as OpenAI need GNOSIS_MCP_EMBED_API_KEY. Configuration uses GNOSIS_MCP_* environment variables.
Installation
In SourceWeft
- Open Gnosis MCP in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Gnosis MCP
Stop pasting files into context. Your AI agent searches your local docs instead.
5–10× fewer tokens per lookup. 92 % Hit@5 on real dev docs. Zero cloud dependencies.
[PyPI] [Downloads] [Python] [MIT License] [CI]
Quick Start · Documentation · Tools · Configuration · Full Reference
[Gnosis MCP — ingest docs, search, view stats, serve]
Ingest docs → Search with highlights → Stats overview → Serve to AI agents
Without a docs server
- LLMs hallucinate API signatures that don't exist
- Entire files dumped into context — 3,000–15,000 tokens per doc
- Architecture decisions buried across dozens of files
- Every repeated lookup pays full context cost
With Gnosis MCP
search_docsreturns ranked, highlighted excerpts — typically 300–800 tokens- Real answers grounded in your actual docs, not guesses from training data
- One local index across hundreds of files — instant multi-doc search
- 5–10× token savings per lookup when your corpus covers the question
What makes gnosis-mcp different
- Your data stays on your machine. SQLite by default, PostgreSQL at scale — nothing leaves the host.
- Index anything that's docs-shaped. Markdown, git commit history, crawled websites — one index, one search API.
- Measured, not marketed. Ships BEIR SciFact numbers (0.671 nDCG@10 — within 1 % of the Lucene BM25 baseline), a reproducible eval harness (
gnosis-mcp eval), and a chunk-size sweep showing where the quality plateau actually sits.
Full side-by-side vs Context7 / docs-mcp-server / mcp-local-rag: gnosismcp.com#compare.
Features
- Zero config — SQLite by default,
pip installand go - Hybrid search — keyword (BM25) + semantic (local ONNX embeddings, no API key). Tune RRF fusion with
GNOSIS_MCP_RRF_K. - Cross-encoder reranking — optional
[reranking]extra with a 22M-param ONNX model. Off by default. Test on your own corpus before enabling — the bundled MS-MARCO reranker hurts dev-doc retrieval in our measurements. - Git history — ingest commit messages as searchable context (
ingest-git) - Web crawl — ingest documentation from any website via sitemap or link crawl
- Multi-format —
.md.txt.ipynb.toml.csv.json+ optional.rst.pdf - Auto-linking —
relates_tofrontmatter creates a navigable document graph - Watch mode — auto-re-ingest on file changes
- Prune stale docs —
gnosis-mcp ingest --pruneremoves chunks whose source file was deleted.--wipefor a full reset before re-ingest. - Built-in eval harness —
gnosis-mcp evalprints Hit@K / MRR / Precision@K in one command, against a bundled fixed fixture set - PostgreSQL ready — pgvector + tsvector when you need scale
Performance
Fast. 8.7 ms mean MCP round-trip. Hybrid search p50 < 30 ms on a 700-doc corpus. Keyword QPS scales from 9,463 @ 100 docs to 471 @ 10,000 docs (full numbers).
Finds the right answer. On 558 real dev docs with 25 hand-written golden queries: Hit@5 = 0.92, nDCG@10 = 0.87, MRR = 0.79. On BEIR SciFact (5,183 docs, public retrieval benchmark): nDCG@10 = 0.671 — within 1 % of the Lucene BM25 baseline.
Tokens saved. Each search_docs call returns 200–500 tokens of on-point snippets instead of the 3,000–15,000 tokens a full-file Read would have cost. Track your own with gnosis-mcp savings (v0.12.0+) — the ledger writes to search_access_log on every call and aggregates per tool per --days N:
Typical compression runs 10–60× depending on corpus coverage and query specificity — verify on yours. access_log is on by default; GNOSIS_MCP_ACCESS_LOG=false opts out.
The same ledger answers the other question — what is this corpus being asked, and where does it come up empty — with gnosis-mcp usage (v0.17.4+): calls, the queries that matched nothing, which documents are served most, which have never been served, and which clients are doing the asking.
Reproducible. gnosis-mcp eval runs a bundled retrieval-quality harness locally in one second — but it ingests nine hardcoded sample documents into a temporary database and answers ten bundled queries, so it returns the same numbers for every corpus and is a smoke test, not a measurement of your docs. To score your own corpus, run python tests/bench/bench_real_corpus.py --corpus <docs-root> --golden <golden.jsonl> (the numbers above come from tests/bench/golden-knowledge.jsonl). tests/bench/*.py reproduce every number. Methodology: docs/benchmarks.md.
Rerankers stay off by default. The bundled MS-MARCO cross-encoder drops nDCG@10 by 27 points on dev-docs and adds 400× latency; BGE-reranker-v2-m3 drops it 31 points at 2400×. Test on your corpus before enabling — full write-up: bench-experiments-2026-04-18.
Quick Start
That's it. Your AI agent can now search your docs.
Connect your client — see llms-install.md for copy-paste JSON snippets for Claude Code, Claude Desktop, Cursor, Zed, opencode, Windsurf, VS Code, JetBrains, Cline, and any other MCP client.
Re-organized your docs? gnosis-mcp ingest ./docs --prune re-ingests and removes any DB chunk whose source file no longer exists. --wipe resets the entire index first. Or run gnosis-mcp prune ./docs --dry-run to preview what would be deleted. Pruning only touches documents this root is responsible for: crawled URLs and generated documents (git history) are left alone unless --include-crawled / --include-generated says otherwise.
Want semantic search? Add local embeddings — no API key needed:
Test it before connecting to an editor:
Then wire it into the clients you actually use — one command, no paths to edit:
setup resolves the command path for the machine it runs on instead of the one the README
assumed, and each block it installs is marker-delimited so re-running rewrites it in place. Where
a client does not read the server's own MCP instructions, it also installs the short rule that
gives the agent a reason to prefer gnosis over reading files — a mounted server nobody calls is
the silent failure mode. doctor is the check for that: it reads the access log and tells you
whether a client has really called the server. Details:
docs/cli.md.
gnosis-mcp check is the gate: it exits 0 only when the backend started and the schema the
server needs is present, and it names whatever is missing before exiting 1. Keyword search needs
SQLite FTS5, which is compiled into your Python's SQLite rather than guaranteed by it — check
reports it as FTS5: ready. Anything else: docs/troubleshooting.md.
Run with Docker (zero install)
Multi-arch image, ~140 MB, ships with local ONNX embeddings + REST:
Or use the committed docker-compose.yaml:
Images tagged :latest, :<version>, :<version-minor>, :main, :sha-<sha>. Production
recipes — systemd, reverse proxy, security checklist, upgrades — are in
docs/deployment.md.
Try without installing (uvx)
Documentation
Canonical index — every topic is one hop away: docs/overview.md.
The handful most readers need:
- Install & client setup — every editor's copy-paste config, Windows paths, write mode, embeddings
- CLI — every subcommand and flag
- Configuration — all
GNOSIS_MCP_*env vars - MCP tools & resources — what your agent can call, and what each returns
- Deployment — Docker, systemd, reverse proxy, security checklist
- Troubleshooting — first-run failures and how to recover
- Benchmarks — reproducible retrieval and latency numbers
Also in docs/: REST API · embeddings service · how we measure search · reranker experiments · releasing.
Tools
Gnosis MCP exposes nine tools and three resources over MCP. Your AI agent calls these automatically when it needs information from your docs:
The six read tools are always advertised. The three write tools require GNOSIS_MCP_WRITABLE=true — without it they are withdrawn from tools/list entirely, so a read-only client is never handed a tool it cannot call.
With embeddings configured, search_docs fuses keyword and semantic results with Reciprocal Rank Fusion and returns a highlight field carrying the matched terms in <mark> tags — that is what keeps a lookup at a few hundred tokens instead of a full file. get_context is the session-start tool: it ranks documents by how often they are actually retrieved, unless GNOSIS_MCP_ACCESS_LOG=false turns tracking off.
Full reference — every parameter, return shape, error, and the graph relation types (related, content_link, git_co_change, git_ref, plus the typed frontmatter edges): docs/tools.md.
Configuration
Nothing required for SQLite — zero config works. Override via GNOSIS_MCP_* env vars. The four most-asked:
The remaining 45 — chunking, search limits, RRF, reranking, crawl, webhooks, column overrides, logging — are documented in docs/config.md.
Backend selection is automatic: set GNOSIS_MCP_DATABASE_URL to a postgresql:// URL and it uses PostgreSQL; leave it unset and it uses SQLite at ~/.local/share/gnosis-mcp/docs.db. Override with GNOSIS_MCP_BACKEND=sqlite|postgres. PostgreSQL setup — gnosis-mcp[postgres], gnosis-mcp init-db, CREATE EXTENSION IF NOT EXISTS vector, then gnosis-mcp embed — is in docs/overview.md.
Embeddings
Semantic search is the one optional add-on most setups want. Local ONNX is the recommended path: zero config, no API key, ~23 MB quantized model (MongoDB/mdbr-leaf-ir, Apache 2.0) auto-downloaded on first run.
Remote providers work the same way via gnosis-mcp embed --provider openai (needs GNOSIS_MCP_EMBED_API_KEY) or --provider ollama. Model choices, dimensions, the OpenAI-compatible POST /v1/embed service, and pre-computed vectors for your own pipeline: docs/embeddings-service.md · docs/config.md.
Available On
MCP Registry (feeds VS Code MCP gallery and GitHub Copilot) · PyPI · mcp.so · Glama · cursor.directory
AI-Friendly Docs
Development
All tests run without a database. Keep it that way.
Good first contributions: new embedding providers, export formats, ingestion for new file types (via optional extras). Open an issue first for larger changes.
Sponsors
If Gnosis MCP saves you time, consider sponsoring the project.
License
Learn more
- Documentation index — the canonical map of every docs page
- Installation guide — copy-paste setup for every MCP client
- Published docs — the same docs, rendered for browsing
- PyPI — releases, version history, install
- Why this exists — the write-up behind gnosis-mcp
Source: README.md at commit 8397bd0
Tools
0Version history
1- v0.17.5LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts