rag-mcp is a Retrieval-Augmented Generation MCP server that lets you ingest, store, and semantically search text using PostgreSQL + pgvector and any OpenAI-compatible embeddings (OpenAI, Azure, Ollama, llama.cpp).
Ingest Text: Chunk, embed, and store any text into a named collection, with optional JSON metadata per chunk.
Semantic Search: Query a collection with natural language and retrieve the top-k most relevant chunks, each with a 0–1 cosine similarity score.
List Collections: View all collections and their chunk counts.
Delete Collection: Permanently remove a collection and all its chunks (irreversible).
Configure: Customize database connection, embedding service, and chunking parameters via environment variables.
Integrate: Designed for any LLM agent or MCP client to ground responses in your documents.
Allows using local Ollama models for embedding generation, enabling offline or private semantic search.
Enables the MCP server to generate embeddings using OpenAI's embedding models for semantic search.
Provides the vector storage and search backend using pgvector for efficient cosine similarity queries.
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., "@rag-mcp search my notes for 'project roadmap'"
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.
A RAG-over-docs MCP server: ingest text into collections, then let any LLM agent semantically search it. Backed by PostgreSQL + pgvector, embeddings via any OpenAI-compatible endpoint (OpenAI, Azure, or a local Ollama / llama.cpp server).
RAG is split the MCP-native way — this server owns retrieval (chunk → embed → store → cosine search); the calling model owns generation. Point Claude, ChatGPT, Cursor, or any MCP client at it and answers get grounded in your docs.
Tool | Purpose |
| Chunk, embed, and store text in a collection (with optional metadata) |
| Top-k semantic search over a collection; returns chunks + 0–1 cosine score |
| List collections and their chunk counts |
| Delete a collection and all its chunks |
| Re-embed a collection's stored content with the current embeddings backend, migrating dimension if needed |
Related MCP server: Chalee MCP RAG
# 1. Start Postgres + pgvector and the server
cp .env.example .env # set EMBEDDINGS_API_KEY
docker compose up -d --build
# — or run locally over stdio (e.g. for Claude Desktop) —
uv pip install --system .
docker compose up -d db # just the database
EMBEDDINGS_API_KEY=sk-... rag-mcpAdd to an MCP client (stdio):
{ "mcpServers": { "rag": { "command": "rag-mcp",
"env": { "EMBEDDINGS_API_KEY": "sk-...",
"DATABASE_URL": "postgresql://postgres:postgres@localhost:5432/rag" } } } }docker-compose.yml publishes Postgres to 127.0.0.1:5432 only (not
0.0.0.0), so psql debugging from the host works but the database is never
reachable off-host. rag-mcp itself talks to it over the compose network as
db:5432. For further host-specific tweaks (e.g. dropping the port binding
entirely on a server where even loopback access isn't needed), copy
docker-compose.override.yml.example
to docker-compose.override.yml — it's gitignored and loaded automatically by
docker compose. Don't hand-edit the tracked docker-compose.yml or hide
local changes with git update-index --skip-worktree; either desyncs
git status/git diff from what's actually deployed and can silently block
fast-forward merges of upstream fixes.
All via environment (see .env.example): DATABASE_URL,
POSTGRES_PASSWORD (must match the password in DATABASE_URL; set a real
secret on any host beyond local dev), EMBEDDINGS_API_BASE /
EMBEDDINGS_API_KEY / EMBEDDINGS_MODEL, EMBED_DIM
(must match your model's dimension — 1536 for text-embedding-3-small),
CHUNK_SIZE, CHUNK_OVERLAP, and MCP_TRANSPORT (stdio | http).
ingest_text splits text on natural boundaries with overlap, embeds each chunk,
and stores it in a chunks table with a vector(EMBED_DIM) column and an
ivfflat cosine index. search embeds the query and returns the nearest chunks
by cosine distance (<=>). Everything is namespaced by collection.
Changing EMBEDDINGS_PROVIDER, EMBEDDINGS_MODEL, or EMBED_DIM makes the
live chunks.embedding column mismatch the new config — the server detects
this at startup, logs it loudly, and search/ingest_text refuse to run
until it's resolved (list_collections/delete_collection are unaffected).
Recover by calling reindex_collection(collection) for every collection. It
re-embeds each row's stored content (bypassing ingest_text's chunking, so
existing chunk boundaries don't shift) with the currently configured backend.
If the new embedding width differs from the live column, your vectors are
staged in a hidden column rather than written live, so other, not-yet-migrated
collections keep serving search normally; once every collection has been
reindexed, the last call atomically swaps the staged column in as embedding
and rebuilds its index. The tool's response includes dimension_changed and
column_swapped so you can tell whether search/ingest_text are usable
again yet.
Copyright © 2026 Next Level Management Advisors, LLC.
Licensed under the GNU Affero General Public License v3.0 (AGPL-3.0) — see LICENSE. If you run a modified version over a network, the AGPL requires you to make your modified source available to its users.
Commercial licensing: to use this in a closed-source or commercial product, or to host a modified version without publishing your source, a commercial license is available — contact forrest@nlma.io.
Delete a collection and all of its chunks. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes the destructive nature ('Delete', 'Irreversible') and the cascading effect on chunks. Without annotations, this disclosure is sufficient for understanding the tool's impact.
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 extremely concise with two sentences. The first sentence states the action, and the second adds critical irreversibility warning. 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 simple delete tool with one parameter and an existing output schema, the description provides the essential behavioral details. It covers what is deleted and the permanence, though it could mention return value briefly.
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 single parameter 'collection' is not described beyond the schema. With 0% schema coverage, the description should clarify what the collection identifier represents, but it adds no semantic value.
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 verb 'delete' and the resource 'collection', and mentions 'all of its chunks', which distinguishes it from sibling tools like list_collections and ingest_text.
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. It only states the action and irreversibility, but lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chunk, embed, and store text in a collection for later semantic search.
collection: logical namespace (e.g. a project or document set). metadata: optional JSON attached to every chunk (source, title, url, ...).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| metadata | No | ||
| collection | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only reveals that the tool modifies data and uses chunking/embedding. It does not disclose side effects (e.g., overwriting, idempotency), auth requirements, or error conditions.
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 concise: two sentences for the action and two lines for parameters. No unnecessary words, and the action is front-loaded.
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?
The tool performs a complex pipeline (chunk, embed, store), but the description omits critical details: success return value, collection creation behavior, chunking parameters, and embedding model. Given no annotations, the description is insufficient for safe invocation.
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?
Parameter descriptions exist only for 'collection' and 'metadata' in the description, providing semantic context. 'text' is unexplained, and output schema is not addressed. With 0% schema coverage, this adds some value but is incomplete.
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 action: chunk, embed, and store text for semantic search. It distinguishes from siblings (delete_collection, list_collections, search) by being the ingestion tool.
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 implies usage for adding text to a collection for later retrieval, but does not explicitly state when to use or avoid it, nor mention prerequisites like collection existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all collections and their chunk counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation (list all collections) but does not explicitly state it is non-destructive, nor does it mention any other behavioral aspects like rate limits or pagination behavior.
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, concise sentence with no unnecessary words. Every part of the sentence is informative.
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 has no parameters and an output schema exists (though not shown), the description is mostly adequate. However, it could provide more context about what a collection is or any prerequisites, but for a simple listing tool, it is sufficiently 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?
The tool has zero parameters, so the schema provides full coverage. Per guidelines, baseline score for 0 parameters is 4. The description adds no param info, which is acceptable.
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 verb 'List' and the resource 'collections' and specifies that chunk counts are included. It distinguishes itself from siblings (delete, ingest, search) by being a read-only listing operation.
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 like search or ingest_text. The description does not provide any context for appropriate usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search a collection. Returns the top-k chunks with a 0-1 cosine score.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| collection | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions semantic search and returns chunks with scores, indicating a read operation. However, it does not disclose permissions, rate limits, or whether it is read-only (though likely). The description is 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 extremely concise with two sentences containing no unnecessary words. It efficiently conveys the core functionality and output format.
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 output schema exists, return values are covered externally. However, with 0% schema description coverage and no parameter explanations, the description is incomplete. It does not clarify the meaning of 'chunks', sorting order, or how the score is used, leaving gaps for an AI agent.
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 description coverage is 0%, so the description should explain parameters. It does not describe 'k', 'query', or 'collection' beyond their presence in the schema. 'query' and 'collection' are self-explanatory but could benefit from format hints, while 'k' default of 5 is not justified. The description adds minimal value over the schema.
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 performs semantic search on a collection and returns top-k chunks with a cosine score. The verb 'search' and resource 'collection' are specific, and it distinguishes from siblings like delete_collection, ingest_text, and list_collections, which manage collections rather than search 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?
The description implies usage for semantic search, but it does not explicitly state when to use this tool versus alternatives. Since it is the only search tool among siblings, usage is clear, but there is no guidance on when not to use it or any prerequisites.
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.0delete_collectioningest_textlist_collectionssearchEach tool has a distinct purpose: delete_collection removes a collection, ingest_text adds content, list_collections enumerates collections, and search queries them. There is no functional overlap.
All tool names follow a consistent verb_noun snake_case pattern (e.g., delete_collection, ingest_text, list_collections). Even 'search' fits as a verb describing the action.
With 4 tools, the server provides essential RAG operations (CRUD for collections plus search) without being too sparse or overly complex. This is appropriate for its purpose.
The tool surface covers the core workflow: list collections, ingest text, search, and delete. Missing update or get collection details, but these represent minor gaps that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Turn documents into structured, AI-ready data by parsing, enriching, chunking, and embedding.
Database for your AI agent. Turn its output into data, docs, skills, and apps you can actually use.
Versioned agent memory in your own Postgres: portable context, permissioned, audit trail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/NextLevelManagementAdvisors/rag-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
