MCP for Verba

[vk2r]

Description

I think that at the moment, connecting Verba with other services is relatively complex and I was wondering if implementing MCP would help in the process of improving the number of people using Verba, simplifying its implementation elsewhere.

[achaiah]

Definitely second that. Need a solid API and MCP server for agentic workflows.

[zanni098]

[Feature Proposal] Expose Verba's RAG pipeline as an MCP server

Summary

This builds on #381, which requested MCP support but didn't have an implementation plan. I'd like to propose a concrete design and volunteer to build it.

While weaviate/mcp-server-weaviate already exposes the vector DB layer over MCP, Verba's higher-level RAG pipeline — ingestion, retrieval, and document-grounded generation — has no MCP interface. Any agent or LLM client that speaks MCP today cannot query Verba directly.

---

Problem

Right now, integrating Verba into an agentic workflow requires writing custom HTTP wrappers around its REST endpoints. This is friction that MCP is specifically designed to eliminate. As MCP adoption grows (it's now supported by Anthropic, OpenAI, Google, and Microsoft), the lack of an MCP interface becomes a real barrier to Verba being used inside agent pipelines.

---

Proposed design

Add a verba_mcp_server.py (using the official mcp Python SDK) that exposes the following tools:

Tool	Description
query_documents	Runs a hybrid search + generation query against the loaded Verba knowledge base
list_documents	Returns the list of ingested documents with metadata
get_document_chunk	Retrieves a specific chunk by ID, for agent grounding
ingest_document	(Optional, v2) Accepts text/URL and triggers ingestion

The server would be started alongside the existing Verba backend (e.g. python verba_mcp_server.py) and read from the same Weaviate instance using the existing GoldenRetriever internals — no parallel stack required.

---

Why this design

• It doesn't change any existing Verba behavior or break the current UI
• It reuses GoldenRetriever and the existing retrieval pipeline directly
• It fits the pattern already set by weaviate/mcp-server-weaviate
• The MCP Python SDK is minimal — the server itself would be under ~200 lines

---

My plan

I've worked with MCP server implementations before (I maintain an agent deployment service that orchestrates multiple MCP runtimes). I'm happy to:

1. Open a draft PR with the initial query_documents and list_documents tools
2. Write documentation for the new server
3. Keep scope tight for v1 — no ingestion, just query-side

Does this design align with the direction you'd want to take Verba? Any concerns about adding the mcp SDK as a dependency? Happy to discuss before writing code.

References

• MCP for Verba #381 (original MCP request)
• https://github.com/weaviate/mcp-server-weaviate (Weaviate's DB-level MCP server)
• https://modelcontextprotocol.io/docs/tools (MCP tool spec)