What can you do with this server?

Read-only MCP server for querying a local AI knowledge base with cited, retrieved context. * Search the knowledge base by query using hybrid retrieval by default, with configurable result limits and cited source_id/source_url results. * Discover content without a specific query using modes such as random, digest, concepts, and channels. * Get context for a query via the shared retrieval pipeline, optionally including a recent digest. * Get status of the knowledge base, including index stats and Ollama health reporting. * All exposed tools are marked read-only (readOnlyHint: true); this public profile does not expose write operations.

Which integrations are available for this server?

Allows ingestion of YouTube video transcripts from configured channels, enabling semantic and hybrid search over their content.

How do I use AI Knowledge Base MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AI Knowledge Base MCP Server search for 'hybrid retrieval' concepts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

AI Knowledge Base MCP Server

by Alpha-W0lf

Overview Schema Source Related Servers Discussions Admin

Python

Local

AI Knowledge Base

Production-grade local hybrid RAG that keeps coding agents current: cited passages from your own documents, served through a read-only MCP (Model Context Protocol) server. LanceDB stores the index and Ollama makes the embeddings, so no documents or queries leave your machine. The first reranker load downloads its model weights from Hugging Face.

The public repo runs on committed synthetic documents.

Eval

Proof

A pre-registered evaluation: 48 synthetic, AI-written documents in 12 look-alike clusters, 96 graded queries, and a held-out set written blind by a separate agent that saw only the documents. The pre-registration fixes the data by hash, and the results file records the same hashes (pre-registration, results).

Held-out, 48 queries	MRR@10	nDCG@10	hit@1
Hybrid search + cross-encoder (default)	0.948	0.962	0.896
Hybrid search (RRF fusion, no reranker)	0.925	0.952	0.875
Keyword search alone	0.922	0.939	0.896
Vector search alone	0.893	0.922	0.812
Random order	0.061	0.096	0.021

The right document comes back first on 90% of held-out queries, against 2% by chance, and the full pipeline scores higher than either search leg alone on MRR@10 and nDCG@10 (against keyword-only, the margin is within the 95% confidence interval). Measured 2026-10-18 with nomic-embed-text and ms-marco-MiniLM-L-6-v2; the results file records the model revisions and dataset hashes. This repo started as a single-commit snapshot of the development history, so the commit named in the results file is from that pre-release history. On every ranking change, CI reruns the eval on its offline embedder and fails the build if a hybrid-search metric drops more than 0.02 below the committed baseline.

Related MCP server: Keepygaga RAG

The problem

AI techniques move weekly, and coding agents that only know their training data fall behind. Teams need a local, citable knowledge path: retrieve what matters, cite the source, and give agents tools they can call safely, without sending private documents to a third party.

How it works

flowchart LR
  F[Documents] --> I[Chunk + embed]
  I --> D[(LanceDB<br/>vectors + full-text index)]
  Q[Query] --> V[Vector search]
  Q --> K[Keyword search]
  D --> V
  D --> K
  V --> R[RRF fusion]
  K --> R
  R --> C[Cross-encoder rerank]
  C --> O[Cited results<br/>CLI or MCP]

Meaning-based (vector) search and keyword (full-text) search run side by side. Reciprocal Rank Fusion (RRF) merges the two lists, and a cross-encoder reranker re-scores the top results. CLI, MCP and the eval all call the same retrieve() function, and every result carries its citation (source_id, source_url), its rank in each leg and the stage that produced the final order.

Key engineering decisions

Hybrid fusion before the cross-encoder. Search stays fast and useful when the reranker is slow, missing or broken: a failed reranker falls back to the fused ranking and says so (ranking_stage: fusion_degraded). Hybrid search stops with a clear error if the keyword index is missing, and an index built with a different embedding model is refused until you rebuild it.
Public fixtures, private corpus. The repo ships synthetic documents with a license manifest. Your own channels and transcripts stay in git-ignored files, and every citation uses a stable source_id, never a local file path.
MCP read-only by default. The public profile exposes 4 tools, each advertising readOnlyHint. Search never writes: ingest builds the index, and a test proves that searching leaves the database files untouched. Tools that change data exist only when AI_KB_MCP_PRIVATE=1 is set.

Try it

You need Python 3.11+, uv and Ollama.

uv sync --extra ce                       # dependencies + cross-encoder
ollama pull nomic-embed-text             # local embedding model
uv run python -m src.ingest --fixtures   # index the smoke documents
uv run python -m src.search "reciprocal rank fusion RRF" --hybrid --ce
uv run python -m src.eval                # the 48-document evaluation

Set AI_KB_EMBEDDINGS=stub to run every command offline on the CI embedder (add --no-ce to search and eval or set AI_KB_CE=0, or download the reranker once first). To connect an agent, copy mcp-config.example.json into your MCP client and set cwd to your clone. Audit the server with mcp-audit: mcp-audit run --server "uv run python -m src.mcp_server".

Stack

Python 3.11+ · LanceDB 0.27 · Ollama nomic-embed-text (768-dim) · sentence-transformers cross-encoder ms-marco-MiniLM-L-6-v2 · MCP Python SDK 2.3 · uv

Deeper docs

GETTING_STARTED.md: full setup, MCP wiring and your own YouTube sync
FAQ.md: technical FAQ
docs/ARCHITECTURE.md: retrieval, identity and MCP contracts
evals/PREREGISTRATION_v2.md: eval data, metrics and criteria
AGENTS.md: how coding agents build and verify this repo
SECURITY.md: security policy
LICENSE: PolyForm Noncommercial 1.0.0 (source-available, non-commercial)

Built by Thomas (Tom) Chacko, Senior AI Engineer (Ex-Meta). Building agent knowledge systems? Reach me on LinkedIn.

Available Tools

4 tools

discoverA

Read-only

Discover AI content without a specific query (honest browse/digest/heuristics).

Modes: random, digest, concepts, channels — not a ranking product. Calls shared implementation in src.discover.

Name	Required	Default
`days`	No
`mode`	No	digest
`limit`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already establishes safety. The description adds useful behavioral context by describing the tool as 'honest browse/digest/heuristics' and explicitly stating it is 'not a ranking product,' which clarifies expected output behavior beyond what the annotation conveys. The implementation note adds little, but the core behavioral caveat is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but 'Calls shared implementation in src.discover' is an implementation detail with no value for selecting or invoking the tool, and 'not a ranking product' is repeated in spirit twice. It earns points for brevity but loses them for the filler final sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema and readOnlyHint cover some important context, and the mode list helps. Still, the description omits the meaning of days and limit, gives no explicit guidance on mode selection, and does not reference sibling tools for disambiguation, leaving meaningful gaps for a tool with three defaulted parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the meaning of the parameters. It does provide the available values for mode ('random, digest, concepts, channels'), which is valuable, but it says nothing about the meaning, units, or effects of 'days' or 'limit', leaving two of the three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource ('Discover AI content') and defines the scope ('without a specific query'), which immediately distinguishes it from the sibling search tool. It also names the operating modes and explicitly says it is 'not a ranking product', giving an agent a strong cue about what the tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without a specific query' implies this is the browsing/exploration alternative to search, and 'not a ranking product' further reinforces when it should not be used. However, it does not explicitly name sibling alternatives such as search, nor describe when one mode should be chosen over another.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_contextC

Read-only

Get comprehensive context via shared retrieval (+ optional recent digest).

Name	Required	Description	Default
`query`	Yes
`include_recent`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations declare readOnlyHint=true, and the description's 'Get' is consistent with a safe read operation, so there is no contradiction. The description adds that retrieval is 'shared' and that a recent digest is optional, but it does not clarify what shared retrieval entails or any behavioral caveats about scope or freshness. Given the read-only annotation, this is minimal but acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no filler and front-loads the main action. The parenthetical efficiently signals the optional recent-digest behavior, though the vagueness of 'comprehensive context' makes it slightly under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the parameter count is low, so detailed return-value documentation is not required. However, the description leaves ambiguity about what context is retrieved, what 'shared retrieval' means, and when search or discover would be more appropriate, so an agent cannot confidently select and invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the bare parameter names. It only touches on include_recent via 'optional recent digest' and never explains the required query parameter's meaning, format, or expected scope. This leaves the primary parameter semantically underdocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Get') and a resource ('context'), and mentions shared retrieval and an optional recent digest. However, 'comprehensive context' and 'shared retrieval' are imprecise, and it does not specify what kind of context is included or how this differs from the sibling tools search and discover.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided for when to use this tool versus search or discover, nor when the recent digest should be included or omitted. The phrase 'Get comprehensive context' implies a broad retrieval use case, but the description leaves the decision entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_statusA

Read-only

Get current status of the AI knowledge base.

Does not require embedding / Ollama for index stats (Ollama health is reported).

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds meaningful behavioral detail: embedding/Ollama are not required for index stats, and Ollama health is reported. This discloses dependency behavior and what the status covers. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. The core purpose is front-loaded, and the important dependency nuance is placed in the second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter tool with a readOnly annotation and an output schema, the description is complete enough. It states what the tool does and clarifies the key dependency behavior. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters receives, so there is no parameter schema burden for the description to carry. With 100% schema coverage and no params, the baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Get current status of the AI knowledge base.' It also mentions what the status includes (index stats and Ollama health), making its purpose distinct from siblings like get_context, search, and discover.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful context: it does not require embedding/Ollama for index stats, but Ollama health is still reported. This helps an agent know when this tool is safe to call. It does not explicitly list when-not-to-use alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchA

Read-only

Search the AI knowledge base for relevant content.

Uses the shared retrieval spine (hybrid → fusion → optional CE). Public results cite source_id / source_url — never absolute filepath. limit: Number of results to return (clamped between 5 and 10; default 5).

Name	Required	Description	Default
`limit`	No
`query`	Yes
`hybrid`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description adds meaningful behavioral context: it uses a shared retrieval spine (hybrid → fusion → optional CE), and public results cite source_id/source_url, never absolute filepaths. This goes beyond the annotation and helps an agent understand output constraints and internal behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. The retrieval spine and result-citation behavior are useful details, and the limit clarification is relevant. It earns its place, though the structure could be slightly tighter by grouping the limit note with parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema and readOnlyHint annotation, the description covers the key behavioral aspects an agent needs: what it searches, how retrieval works, and what result fields look like. It doesn't explain when to prefer this over 'discover' or 'get_context', which is a minor gap for a search tool with siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does explain 'limit' (clamped between 5 and 10; default 5), which adds value beyond the schema. However, it does not explain 'query' or 'hybrid' semantics beyond what the schema already provides (names/types/defaults). With 3 params and only one explained, the compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Search the AI knowledge base for relevant content.' It clearly identifies what the tool does. However, it doesn't explicitly differentiate from siblings like 'discover' or 'get_context', though the retrieval focus is reasonably distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching the knowledge base but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The mention of the retrieval spine and public result behavior gives some context, but no exclusions or alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Jul 14, 2026
- First observeddiscover
- First observedget_context
- First observedget_status
- First observedsearch

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-09-27 02:00 across 4 tools

Disambiguation3/5

get_context, search, and discover all relate to retrieving information, which creates some overlap; however, search is query-based, discover is browse-based, and get_context aims for comprehensive retrieval, so descriptions mostly disambiguate. get_status is clearly separate. The boundary between get_context and search remains slightly fuzzy.

Naming Consistency3/5

Two tools use the get_ prefix while two use bare verbs, creating a mixed convention. The names are still readable and each clearly indicates its action, but the inconsistent style is noticeable.

Tool Count4/5

Four tools is a reasonable size for a focused knowledge-base retrieval server, though it feels on the lean side. Each tool has a distinct role and the count is appropriate for the apparent scope.

Completeness2/5

The server only provides retrieval and status operations; there are no tools for adding, updating, or deleting knowledge-base content. For a server named 'AI Knowledge Base', this is a significant gap that limits agents to read-only workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Anclum A
io.github.wdfdaivd
Search MCP servers, agent skills and open-source AI projects, plus AI tools. Read-only.
Search Developer Tools
31
https://anclum.com/mcp
Ragora A
io.github.mregmi
Search your knowledge bases from any AI assistant using hybrid RAG.
RAG Systems Search Knowledge & Memory
2
https://mcp.ragora.app/mcp
ATProto Data Layer A
dev.workers.filae.atproto-mcp
Search ATProto writing, annotations, identity, agents, and forum posts. 12 read-only tools.
Search Social Media Web3 & Decentralized Tech
2
https://atproto-mcp.filae.workers.dev/mcp
DocsMint A
io.github.HiAi-gg
Cloud or self-hosted knowledge for AI agents: hybrid search, reranking, GraphRAG, scoped MCP tools.
Documentation Access Knowledge & Memory RAG Systems
221110
https://docsmint.com/mcp

Related MCP Servers

OKF MCP Server
RAG Systems Knowledge & Memory
UnknownUserKR
F
license
Not graded
quality
B
maintenance
Provides read-only access to a personal RAG knowledge base, enabling hybrid search, evidence-grounded retrieval with citations, and knowledge gap tracking for LLM agents.
Updated 17 days ago (2026-10-09 13:44 UTC)
-
Keepygaga RAG
RAG Systems Search
TimWongUp
A
license
A
quality
C
maintenance
Enables local-first hybrid knowledge retrieval from authorized Markdown and plain-text files, combining full-text and vector search with reranking and traceable source references via a single search tool.
Updated 6 days ago (2026-10-19 22:12 UTC)
1
MIT
loci-mcp
RAG Systems Vector Databases Knowledge & Memory
gSidorov61153
F
license
Not graded
quality
A
maintenance
Enables AI agents and MCP hosts to query locally indexed notes, docs, chat logs, and other files via hybrid vector/BM25 retrieval with section-level citations. Exposes tools, resources, and prompts for searching and asking over the indexed content.
Updated 10 days ago (2026-10-15 21:01 UTC)
-
loci-mcp
RAG Systems Knowledge & Memory Note Taking
ananya0615
F
license
Not graded
quality
A
maintenance
Enables AI agents and MCP hosts to query a local index of scattered notes and documents through hybrid vector and BM25 retrieval, returning section-level citations and exposing tools, resources, and prompts.
Updated 9 days ago (2026-10-17 07:21 UTC)
-