Generates embeddings using OpenAI's text-embedding-3-small model for semantic search.
Stores and queries document chunks with pgvector-based vector similarity search in PostgreSQL.
Supports Supabase as a PostgREST backend for managing document chunks and metadata.
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., "@RagLit MCP Server Search for chunks similar to 'quantum computing'."
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.
Model Context Protocol server enabling AI agents to query and interact with PostgREST APIs
RagLit is a Model Context Protocol (MCP) server that bridges AI agents like Claude Desktop with PostgREST-compatible backends for RAG (Retrieval-Augmented Generation) pipelines. The server implements the MCP specification to expose document chunking, embedding generation, and semantic search capabilities, enabling AI agents to ingest documents into PostgreSQL databases and query them using vector similarity search. Built with TypeScript using repository pattern for database abstraction, demonstrating understanding of emerging AI agent architectures and standardized tool protocols.
Related MCP server: MCP Knowledge Base Server
Runtime: Node.js · TypeScript AI/ML: OpenAI API (text-embedding-3-small) · pgvector Database: PostgreSQL · PostgREST Architecture: Model Context Protocol (MCP) · Repository Pattern Tools: Zod (validation) · ESLint
MCP-compliant server implementing standardized tool protocol for AI agent communication
Document ingestion pipeline with fixed-size word-based chunking and configurable overlap
OpenAI embedding generation service with text-embedding-3-small model integration
Semantic search using PostgreSQL pgvector extension via PostgREST RPC functions
Metadata filtering with JSONB containment queries for exact-match document retrieval
Repository pattern abstraction layer for PostgREST API with interface-based design
Three MCP tools exposed: chunk_document, search_chunks, filter_metadata
Environment-based configuration supporting Supabase and self-hosted PostgREST instances
Schema validation using Zod for type-safe request/response handling
Built using the Model Context Protocol (MCP) specification, an emerging standard for AI agent tool integration pioneered by Anthropic. Implements stdio-based communication pattern where Claude Desktop launches the Node process and communicates via standard input/output. Chose repository pattern with abstract ChunkRepository interface to decouple business logic from PostgREST implementation details, enabling future adapter implementations for different backends. PostgREST integration leverages PostgreSQL's pgvector extension through RPC function calls (match_chunks, filter_chunks_by_meta) rather than direct SQL, providing API-level abstraction. Document chunking uses fixed-size word-count strategy with overlap to maintain semantic context across chunk boundaries. OpenAI embedding service encapsulates API calls with error handling and retry logic. Environment configuration validation using Zod ensures runtime type safety for required variables (EXTERNAL_API_URL, OPENAI_API_KEY).
Key Learnings:
Implementing Model Context Protocol (MCP) specification for AI agent tool integration
Designing repository pattern abstractions for REST API interactions with type-safe interfaces
Understanding pgvector cosine similarity search with PostgreSQL RPC function integration
Building document chunking strategies balancing semantic coherence with embedding costs
Using Zod for runtime schema validation and environment configuration
Challenges Overcome:
Debugging PostgREST schema cache issues requiring exact column name matching (camelCase)
Designing MCP tool schemas that balance flexibility with type safety using Zod
Implementing proper error handling for cascading failures (OpenAI → PostgreSQL → PostgREST)
Structuring repository interface to support both Supabase and self-hosted PostgREST
Understanding MCP stdio communication pattern and Claude Desktop integration requirements
npm install
npm run build
npm run start
# Server communicates via stdio for MCP clientsClaude Desktop Integration:
Add to claude_desktop_config.json:
{
"mcpServers": {
"raglit-postgrest": {
"command": "node",
"args": ["/absolute/path/to/raglit-fixed-mcp/dist/index.js"],
"env": {
"EXTERNAL_API_URL": "https://your-project.supabase.co",
"OPENAI_API_KEY": "sk-your-key",
"EXTERNAL_API_KEY": "your-postgrest-key"
}
}
}
}PostgreSQL Setup:
-- Enable pgvector extension
CREATE EXTENSION IF NOT EXISTS vector;
-- Create chunks table
CREATE TABLE public.chunks (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
"documentId" TEXT NOT NULL,
content TEXT NOT NULL,
"chunkIndex" INTEGER NOT NULL,
"chunkSize" INTEGER NOT NULL,
"chunkOverlap" INTEGER NOT NULL,
"chunkStrategy" TEXT DEFAULT 'fixed-size' NOT NULL,
metadata JSONB DEFAULT '{}',
embedding VECTOR(1536)
);
-- Create RPC functions for search and filter
-- (See full README for complete SQL)Environment Variables:
EXTERNAL_API_URL=https://your-postgrest-url
OPENAI_API_KEY=sk-your-openai-key
EXTERNAL_API_KEY=your-postgrest-api-key
EMBEDDING_MODEL=text-embedding-3-small| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| metadata | No | Optional metadata to associate with the chunks. | |
| chunkSize | No | The target size of each chunk in words (tokenized by whitespace). | |
| documentId | Yes | ||
| chunkOverlap | No | The number of words to overlap between consecutive chunks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| limit | No | The maximum number of filtered chunks to return. | |
| metadataFilter | Yes | An object containing metadata key-value pairs to filter by. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| limit | No | The maximum number of search results to return. | |
| query | Yes | The search query string. | |
| threshold | No | The similarity threshold for matching chunks (0 to 1). | |
| metadataFilter | No | Optional metadata filter to apply to the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0chunk_documentfilter_metadatasearch_chunksEach tool targets a distinct step in the RAG pipeline: chunking documents, searching chunks, and filtering by metadata. The purposes are clearly separable based on names alone, with no overlapping actions.
All tool names follow a consistent verb_noun pattern in snake_case: chunk_document, search_chunks, filter_metadata. This creates a predictable and readable naming convention.
Three tools is on the lower end of the well-scoped range (3-15), but it covers the core RAG operations without being sparse. The count is reasonable for a focused server, though slightly minimal.
The tool set covers the essential lifecycle for a simple RAG server: ingest (chunk), retrieve (search), and refine (filter). Minor gaps exist, such as lack of explicit document management or chunk retrieval, but the core workflow is functional.
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
Hosted persistent memory with semantic search, importance and TTL for AI agents.
Versioned agent memory in your own Postgres: portable context, permissioned, audit trail.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thebrownproject/raglit-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server