A
licenseA
qualityNot graded
maintenanceProvides centralized knowledge management for projects, allowing users to store, search, and maintain project-specific knowledge that persists across sessions.
27
14 npm
1
-
mcp-rag
by LXVault
This server exposes an MCP RAG knowledge base over stdio, letting authorized clients search and manage project knowledge and project settings.
Identity:
whoamiconfirms the user/project bound to the API token;get_projectreturns project details such as title, summary, and knowledge-base chunk count.Knowledge retrieval:
search_knowledgeperforms semantic search over the project's knowledge base using the project's embedding model.Knowledge addition:
add_knowledgesaves new text chunks into the knowledge base for later retrieval.Project management: create projects, change project title/description, and add members (token-based, with server-side owner/admin enforcement).
Note:
upload_fileis mentioned in the README but not detailed in the provided schema.Access control: All actions are tied to a per-project access token and recorded in the backend audit log, so actions are traceable to the token owner.
Click on "Deploy 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., "@mcp-ragsearch my knowledge base for deployment steps"
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.
mcp-rag-mcp-server
A Model Context Protocol server that exposes the MCP RAG knowledge base to MCP compatible clients such as Claude Desktop and IDE assistants.
It is a thin adapter over the Express backend in
LXVault/server-expressjs. It authenticates
with a per project access token generated in the
web app, and the backend records every call in
its audit log, so any action taken through this server is traceable to the user who
generated that token.
Tools
Nine, in three groups:
Identity:
whoami,get_project.Knowledge:
search_knowledge,add_knowledge,upload_file.Project management:
create_new_project,change_project_title,change_project_description,add_member.
Arguments, return values and the embedding prerequisites: Tools reference.
The project management tools never trust a claimed identity or target. The backend resolves the acting user and the project from the token and enforces owner and admin server side, so a prompt injected tool call cannot escalate privileges or act on another project.
Related MCP server: autotuesday-kb-mcp
Quick start
npm install
MCP_API_BASE_URL=http://localhost:4000/api \
MCP_API_TOKEN=mcp_xxxxxxxx \
npm startGenerate the token from the web app's Access Tokens page. Note that the base URL includes
/api. The server speaks JSON-RPC over stdio, so it is normally launched by an MCP client
rather than by hand.
Documentation
Overview, what the server exposes and why the token matters.
Tools reference, every tool and its arguments.
Setup, installing and wiring it into an MCP client.
Environment variables, both values and what a wrong one does.
Claude Desktop extension, packaging a one click bundle.
The full documentation map is
.agents/index/project-wiki-index.md.
Working with agents
Agent instructions start at AGENTS.md. Shared conventions come from the
LXAgents instruction set served by the lxagents-agents-base MCP connector; this
repository carries only what is its own.
License
MIT. See LICENSE.
Available Tools
4 toolsadd_knowledgeA
Save a piece of text as a new chunk in the project's knowledge base so it can be retrieved later with search_knowledge. The chunk is embedded with the project's model, so the user's OpenRouter API key must be set in the web app.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The text to store as a knowledge chunk. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds context about embedding with the project's model and API key requirement, but does not disclose potential limitations like content length, duplicate handling, or indexing delays. This is adequate but could be more thorough.
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?
Two sentences, no wasted words. First sentence states purpose and links to sibling. Second sentence adds critical context about embedding and authentication. Both sentences are meaningful and earn their place.
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?
For a simple tool with one parameter and no output schema, the description covers main aspects: purpose, mechanism (embedding), and a prerequisite. It could mention if there is a return value or indexing delay, but overall it is sufficiently complete.
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 coverage is 100% for the single parameter 'content'. The description's mention of 'text' is redundant with the schema description. The description adds no new parameter-specific details beyond what the schema provides.
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?
Description clearly states the action: 'Save a piece of text as a new chunk in the project's knowledge base.' It distinguishes from sibling tool search_knowledge by explaining the relationship (retrieve later).
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?
Description mentions prerequisite (OpenRouter API key set in web app) and links to related tool search_knowledge for retrieval, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives beyond search_knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectA
Get details about the project this token grants access to, including its title, summary and the number of knowledge-base chunks available.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It mentions 'this token grants access to' implying authentication, but does not disclose behavioral traits such as error handling, permissions required, or side effects. Minimal transparency beyond the basic function.
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 a single sentence of 22 words, concise and front-loaded with the core purpose. Every word contributes meaning without redundancy or unnecessary elaboration.
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?
For a simple get tool with no input parameters and no output schema, the description provides sufficient context by listing what the response includes (title, summary, number of chunks). Could be improved by mentioning potential error conditions (e.g., invalid token) but overall adequate.
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 input schema has zero parameters, making schema description coverage trivial at 100%. The description adds no parameter info (none needed) but provides context on return fields. Baseline 4 is appropriate as the description does not need to compensate for missing parameter details.
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 clearly states the tool 'Get details about the project this token grants access to', specifying the verb 'Get' and resource 'project details', and lists included fields like title, summary, and number of knowledge-base chunks. This effectively distinguishes it from siblings such as add_knowledge, search_knowledge, and whoami.
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 when needing project details but provides no explicit guidance on when to use this tool versus alternatives (e.g., when not to use it, or prerequisites like valid token). It does not mention any exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_knowledgeA
Semantic search over the project's knowledge base: ranks chunks by meaning using the project's embedding model. Requires the user to have set their own OpenRouter API key in the web app (Profile).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The text to search for. | |
| limit | No | Maximum number of chunks to return (default 5). |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description covers basic behavior (semantic search, ranking) and a key requirement, but omits details like return format, error handling, or performance characteristics.
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?
Two concise sentences that front-load the core purpose and then add a crucial prerequisite. No wasted words.
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?
With no output schema, the description should explain what the tool returns (e.g., ranked chunks, scores). It only mentions 'ranks chunks' but not the output format. Parameters are well-covered by schema.
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 coverage is 100%. Description adds minimal value: for 'query' it restates the schema, for 'limit' it mentions default value (5). Does not explain deeper meaning or usage nuances.
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 clearly states 'semantic search over the project's knowledge base' and 'ranks chunks by meaning using the project's embedding model'. It distinguishes from siblings (add_knowledge, get_project, whoami) which have different purposes.
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?
Explicitly states a prerequisite (user must have OpenRouter API key). No alternative tools are mentioned, but siblings are distinct enough to make usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiA
Identify the user and project that the current API token is bound to. Use this to confirm whose context actions will be attributed to.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses read-only behavior (identify). No side effects mentioned, but for a zero-parameter info tool, this is adequate.
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?
Two sentences, no filler, front-loaded with action and purpose. Every word earns its place.
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?
No output schema, but description hints at return of user and project info. Given simplicity and sibling context, it's sufficiently complete.
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?
No parameters. Schema coverage 100%. Baseline 4 applies per rubric for zero-parameter tools.
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?
Clearly states it identifies the user and project bound to the API token. Distinct from siblings (add_knowledge, get_project, search_knowledge) which involve knowledge management or project details.
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?
Explicit guidance: 'Use this to confirm whose context actions will be attributed to.' No when-not-to or alternatives, but context is clear given siblings.
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 updates
v1.0.0- First observed
add_knowledge - First observed
get_project - First observed
search_knowledge - First observed
whoami
TDQS
A4.2/5.0
Scored across 4 tools
Disambiguation5/5
Each tool targets a distinct action: adding knowledge, retrieving project details, semantic search, and identity confirmation. No overlap in purpose.
Naming Consistency5/5
All tools use consistent snake_case with a verb_noun pattern (add_knowledge, get_project, search_knowledge), and whoami follows the same style.
Tool Count5/5
4 tools is well-scoped for a minimal RAG server, covering the essential operations without unnecessary bloat.
Completeness4/5
Core operations (add, search, project info, identity) are present. Missing delete/update for knowledge is a minor gap, but the server covers the main use case.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Project memory, semantic code search, and grounded agent context.
- Knowledge BaseOAuthai.b77
A searchable knowledge base your assistant reads and writes.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables secure access to an organizational knowledge base via Supabase (RLS), providing tools for search, retrieval, writing, version history, and change tracking.-
- AlicenseAqualityAmaintenanceEnables coding agents to query local notes, decisions, docs, and code with hybrid retrieval (BM25 + embeddings + reranking) and get path:line citations. It provides tools like rag_query for full-corpus search and search_knowledge for project-scoped knowledge recall.21MIT
- AlicenseNot gradedqualityBmaintenanceProvides a shared project knowledge and handoff layer for coding agents, offering tools to list, search, retrieve, and update stages of project information to maintain continuity across long-running projects17MIT