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.
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.
Python, MCP SDK, Ollama / Local LLM, AI Agent Client, FastAPI (optional integration).
I built this with FastMCP, and it currently exposes four tool categories:
Each tool is registered with a @mcp.tool() decorator, which is what makes FastMCP genuinely pleasant to work with. 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.
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.