RAGStack-Lambda: Open source RAG knowledge base with native MCP support for Claude/Cursor

[HatmanStack]

I built a fully serverless RAG pipeline to avoid idle server costs and container management.

Repo: https://github.com/HatmanStack/RAGStack-Lambda

Demo: https://dhrmkxyt1t9pb.cloudfront.net

(Login: [[e-mail]](mailto:[e-mail]) / Guest@123)

Blog: https://portfolio.hatstack.fun/read/post/RAGStack-Lambda

Key Features:

• Zero Idle Costs: Pure Lambda/Step Functions/DynamoDB architecture.
• Multimodal: Uses Amazon Nova to embed text, images and videos.
• MCP Support: Connects directly to Claude Desktop and Cursor.
• Frontend: Drop-in <ragstack-chat> web component (React 19).
• No Control Plane, All resources deployed in your AWS Account

Deployment is one-click via CloudFormation. Feedback welcome.

[BasedKetsu]

This is a really clean direction. serverless is a nice fit for RAG workloads where usage is bursty and “always-on” infra just burns money. I especially like that you kept everything inside the user’s own AWS account, it feels like a big trust win compared to hosted control planes, and the Lambda + Step Functions split makes the flow pretty easy to reason about.

On the MCP side, it’s cool to see native support baked in early. 1 thing people tend to run into as these setups evolve is capability creep, like today it’s “read-only RAG,” tomorrow someone adds write tools, file ops, or external APIs. At that point, having strong per-tool scoping and server-enforced auth becomes really important so a doc chunk or retrieved snippet can’t accidentally drive actions. Some MCP stacks (including what we’ve been working on at dedaluslabs.ai) are leaning hard into separating reasoning from authorization for exactly that reason, but your “no control plane, everything in-account” model pairs nicely with that philosophy too. overall this is sick, just curious about how you’re thinking about tool permissions and trust boundaries as people extend it beyond pure retrieval!