This MCP server is an intelligent knowledge management system for engineering agents. It provides:
Search: Perform hybrid BM25 + vector semantic search with optional LLM reranking over the knowledge base. Filter by tags, project, role, or current task for context-aware retrieval (knowledge_search, knowledge_relevant).
Learn and organize: Import knowledge (text, code, docs); the LLM automatically extracts structured metadata (title, summary, tags, type, relationships). Knowledge can be staged for review before committing (knowledge_learn, knowledge_learn_staged).
Lifecycle management: Confirm staged entries, manage knowledge decay and refresh via FSRS-6 spaced repetition, enable role-based knowledge diffusion and activation, and run decay sweeps.
Monitoring and configuration: Check knowledge base status (entry counts, type distribution, LLM connection) and view LLM configuration without secrets (knowledge_status, knowledge_config).
Operational tools: Export/import for backup, audit operations, and identify knowledge gaps.
Self-contained architecture: Uses in-process SQLite with FTS5 and ONNX for embeddings, requiring no external services.
Planned integration for automatic discovery of research papers from arXiv to enrich the knowledge base.
Planned integration for automatic discovery of repositories and projects from GitHub to enrich the knowledge base.
Allows using a local Ollama instance as the LLM backend for knowledge processing, with OpenAI-compatible API.
Integrates with OpenAI's API to enable LLM-powered semantic understanding, knowledge extraction, and relevance reasoning.
Planned storage backend to replace JSON file storage for more robust and scalable knowledge persistence.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@auto-knowledge-base 学习关于React hooks的最佳实践"
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.
# 1. Install
git clone https://github.com/guyeyouhun/auto-knowledge-base.git
cd auto-knowledge-base
npm install # installs deps + auto-downloads embedding model (~55MB)
npm run build
node dist/install.js # creates .env template
# 2. Configure LLM (needed for rerank/synthesis)
# Edit .env:
LLM_BASE_URL=https://api.openai.com/v1
LLM_API_KEY=sk-...
LLM_MODEL=gpt-4o
# 3. Start
node dist/index.js # runs as MCP server over stdioNo additional services. No embedding server, no vector database, no Python runtime. BM25 and vector search both run in-process with SQLite + ONNX.
Related MCP server: Open WebUI Knowledge Base MCP Server
# Store knowledge → staging
knowledge_learn(content: "Vite uses Rollup for production bundling", title: "Vite Build")
# Confirm → committed
knowledge_confirm(id: "550e8400-e29b-41d4-a716-446655440000")
# Search (BM25 + vector hybrid + LLM rerank)
knowledge_search(query: "vite rollup")
# Role-aware knowledge push
knowledge_relevant(role: "frontend", task: "configure build tooling")
# Export backup
knowledge_exportLayer | Technology |
Retrieval | FTS5 BM25 → cosine similarity → LLM rerank |
Embedding | Process-internal ONNX via |
Storage | SQLite + WAL + FTS5 + relation graph + vector columns |
Spaced repetition | FSRS-6 for retention optimization |
Knowledge diffusion | Role-based BFS activation |
query → BM25 FTS5 → vector cosine rerank
→ if BM25 < limit: vector similarity scan → results
→ (optional) LLM rerank + synthesisEvery stage degrades gracefully. No single failure blocks the response.
learn (staging) → confirm (confirmed) → FSRS decay → frozen
↓
refresh queue → content-digester re-digestTool | Description |
| BM25 + vector hybrid + LLM rerank |
| Store knowledge (staging), auto-dedup |
| staging → confirmed |
| Role-based diffusion + BFS activation |
Tool | Description |
| Role entry nodes, diffusion depth |
| View LLM configuration |
Tool | Description |
| FSRS-6 decay sweep |
| JSON backup / restore |
| Operation log |
| Statistics (truth, temperature, relations, embeddings) |
Tool | Description |
| Request re-digestion (content-digester integration) |
| Report knowledge gaps, triggers auto-digest |
| Query gap records by status/role |
Only the LLM needs to be configured (in .env):
LLM_BASE_URL=http://localhost:11434/v1
LLM_API_KEY=your-api-key
LLM_MODEL=gpt-4oThe embedding model (fastembed + BGESmallZH) is automatically downloaded during npm install to knowledge/models/. No embedding configuration needed.
npm test # 157 tests, 21 files
npm run test:watch # watch mode
npm run build # tsc + copy schema查看 LLM 配置信息（不暴露密钥）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions that keys are not exposed, which is a behavioral trait. However, no other traits (e.g., permissions, rate limits) are disclosed, and no annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, single sentence. Front-loaded with essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimal but sufficient for a simple config view. Could mention return format or authentication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline score is 4. Description does not add parameter info as none exist. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to view LLM configuration information, with a specific note about not exposing keys. It distinguishes from sibling tools like knowledge_learn and knowledge_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like knowledge_status. The context implies it's for viewing config, but lacks direct comparison or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
导入知识到知识库。LLM 会自动提取结构化信息（标题、摘要、标签、关系）。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 知识内容（文本、代码、文档片段等） | |
| type | No | 知识类型（可选，LLM 自动判断） | |
| title | No | 标题（可选，LLM 自动生成） | |
| project | No | 关联项目名 | |
| tags | No | 标签（可选，LLM 自动提取） | |
| source | No | 来源描述 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions LLM extraction but omits important traits like idempotency, sync/async nature, side effects, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear action and key feature (LLM extraction). No wasted words, though additional behavioral info could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and moderate complexity (enum, nested, etc.), the description is too brief. Lacks return value info, error handling, or usage examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context that LLM auto-extracts structure for optional fields, but this does not significantly enhance understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool imports knowledge into the knowledge base and that the LLM auto-extracts structured info. It distinguishes from siblings like knowledge_config (configuration) and knowledge_search, but lacks explicit differentiation from knowledge_learn_staged.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., knowledge_learn_staged). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
暂存待确认知识。存入 staging 区域，需要确认后才正式入库。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 知识内容 | |
| source | No | 来源描述 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the staging nature and need for confirmation, but lacks details on side effects, reversibility, or behavior of multiple staging calls. For a write tool, this is insufficient beyond the basic staging concept.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences: first states the purpose, second explains the process. No extraneous words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the staging workflow and confirmation requirement. It does not mention how to confirm later or integration with sibling tools like knowledge_status, but remains fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described. The description adds context about staging overall but does not enhance parameter-specific meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '暂存待确认知识' (temporarily store knowledge to be confirmed) and '存入 staging 区域' (store in staging area), clearly indicating the tool's purpose of staging knowledge. It distinguishes from sibling tools like knowledge_learn (direct learning) and knowledge_config (configuration) by specifying the staging nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says '需要确认后才正式入库' (requires confirmation before formal entry), hinting that this tool is for adding knowledge without immediate commitment. It provides clear context but does not explicitly mention when not to use or compare with alternatives like knowledge_learn for direct insertion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取与当前任务相关的知识。基于任务描述和关键词返回最匹配的条目。
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | 当前任务描述 | |
| keywords | No | 关键词列表 | |
| project | No | 当前项目名 | |
| currentFile | No | 当前文件路径 | |
| maxResults | No | 最大返回数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool returns best matching entries but does not disclose read-only nature, behavior with no matches, or any side effects. A retrieval tool should clearly indicate it is a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the action and purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter retrieval tool with no output schema or annotations, the description lacks details on return format, error handling, or behavior when no results. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds that it uses task description and keywords, but does not clarify how project, currentFile, or maxResults affect results beyond schema descriptions. Marginal value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves knowledge relevant to the current task, using task description and keywords. It distinguishes from siblings like knowledge_search by emphasizing contextual relevance, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like knowledge_search or knowledge_learn. The description implies usage for context-based retrieval but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索知识库，支持语义理解。返回匹配的知识条目和综合说明。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词或自然语言查询 | |
| tags | No | 按标签筛选 | |
| project | No | 按项目名筛选 | |
| limit | No | 返回数量上限 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only search operation but does not explicitly state side effects, permission requirements, or any limitations. The mention of semantic understanding adds some behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no filler words. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with 4 params and no output schema), the description covers the main purpose and return value but lacks details about parameter interaction, read-only nature, and differentiation from closely related sibling 'knowledge_relevant'. It is adequate but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no new meaning beyond the schema; it paraphrases 'search keyword or natural language query' which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a knowledge base with semantic understanding and returns matching entries and explanations. It distinguishes from sibling tools like 'knowledge_config' and 'knowledge_learn' by focusing on search rather than configuration or learning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'knowledge_relevant' or when not to use it. There is no mention of context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
知识库状态概览：条目数量、类型分布、LLM 连接状态。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates that the tool returns status data, but with no annotations provided, it does not disclose behavioral traits such as whether it is read-only, what happens if the LLM connection is down, or if it requires authentication. It is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the tool's purpose and key details. It is front-loaded and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the main purpose adequately. It could mention read-only behavior or caching, but the current level is sufficient for a status overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so the description naturally adds no parameter meaning. Per the baseline rule for 0 parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an overview of knowledge base status, specifying three aspects: item count, type distribution, and LLM connection status. This verb+resource+details format makes the purpose unambiguous and distinguishes it from sibling tools like knowledge_search or knowledge_learn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The description implies it's for checking status, but does not mention alternatives or scenarios where other tools might be preferred. Given the presence of five sibling tools, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0knowledge_configknowledge_learnknowledge_learn_stagedknowledge_relevantknowledge_searchknowledge_statusTools are mostly distinct, but knowledge_relevant and knowledge_search both serve retrieval purposes, which could cause confusion. Descriptions help differentiate them though.
All tools follow a consistent knowledge_verb pattern in snake_case, making them predictable and easy to navigate.
With 6 tools covering configuration, import, staging, retrieval, and status, the count is well-scoped for a knowledge base MCP server.
Missing update and delete operations, and the staged workflow lacks a confirm tool, leaving notable gaps in the lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The knowledge base your AI reads and writes, under your rules — over MCP, EU-hosted.
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Cross-vendor AI memory over MCP. One semantic store, readable and writeable from every MCP client.
DocBase MCP server for AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/guyeyouhun/auto-knowledge-base'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
