Beyond Chatbots: Wrapping My RAG Agent in an MCP Server

In my last post, I walked through a RAG pipeline that answers questions from a company policy document. The next question I wanted to answer: what happens when I want other AI systems to use that same capability, without hardcoding a Python import?

That's what pulled me into building an MCP server. In this article, I will explain how I built a custom MCP server that exposes tools to AI agents and how this architecture enables more powerful enterprise AI applications.

What is MCP?

Model Context Protocol is an open protocol that standardizes how AI applications communicate with external tools and data sources. Instead of creating custom integrations for every AI application, MCP provides a common interface where servers expose tools that AI clients can discover and invoke.

Technology Stack

• Python
• MCP SDK
• Ollama / Local LLM
• AI Agent Client
• FastAPI (optional integration)

What's Actually in the Server

I built this with FastMCP, and it currently exposes four tool categories:

• Calculator tools - calculator_add and calculator_multiply.
• search_company_documents - the RAG agent from my last project, but now reached over HTTP instead of a direct function call. The MCP tool sends a request to the RAG agent's FastAPI /search endpoint and returns the answer. This one requires an api_key parameter.
• get_employee_leave - looks up an employee's remaining PTO from an in-memory store. Simple lookup, no external calls.
• get_ticket_information - same pattern, returning ticket status, assigned team, and priority.

Each tool is registered with a @mcp.tool() decorator, which is what makes FastMCP genuinely pleasant to work with.

Challenges I Encountered

The calculator, employee, and ticket tools were straightforward pure functions with no external dependencies. The RAG search tool was a different problem entirely, and it was the hardest part of this whole project.

My RAG agent runs as its own FastAPI service, on its own process, with its own vector store loaded into memory. The MCP server doesn't share any of that - it has to reach across a real network boundary with a plain requests.get() call to http://127.0.0.1:8000/search.

Handling real failure modes like connection refused if the RAG service isn't up, timeouts, a response shape that has to be parsed correctly on the other side.

Future Enhancements

• Extend authentication to the employee and ticket tools, so the protection is uniform rather than partial
• Replace the in-memory employee/ticket dictionaries with a real data source
• Eventually, wire this MCP server in as the tool layer for a multi-agent workflow - letting a research agent and a writer agent share the same discoverable tool set instead of each having their own direct integrations

Key Takeaways

Building an MCP server changed my perspective on AI applications. The future of enterprise AI is not only about generating better responses. It is about creating systems where AI agents can safely interact with real-world tools and business capabilities. MCP provides an important foundation for building these next-generation AI applications.

GitHub: https://github.com/srirdeevi/mcp-server