The Applied Epic MCP framework was the core technical experiment of my Peoples First work.
The problem was easy to describe and hard to implement responsibly: the agency had valuable operational context in its management system, but a language model cannot be treated like a normal employee with free rein through sensitive records.
The answer was not to dump data into a chat window. The answer was to build a tool boundary.
The Idea
Model Context Protocol gave the project a clean mental model. Claude could ask for specific pieces of context through named tools, and the server could decide what was allowed, how much to return, and what shape the response should take.
That turned the system from "AI connected to everything" into something more disciplined:
- Bounded tool calls.
- Structured arguments.
- Predictable responses.
- Smaller context windows.
- Local data boundaries.
- Human review around sensitive actions.
In an insurance environment, that difference matters. The goal was to make the model useful without making it dangerous.
What I Built
I designed and engineered the MCP layer that acted as the bridge between Claude and the agency's operational context.
The system was built around insurance-specific workflows rather than generic chatbot behavior. It needed to help with questions around accounts, submissions, policies, renewal context, and operational follow-up without exposing unnecessary records or turning every request into a massive data dump.
The important engineering work was in the interface between the model and the system:
- Tool schemas that forced requests into known shapes.
- Retrieval paths that returned evidence instead of broad database access.
- Output limits so the model did not drown in context.
- Local deployment so sensitive material stayed inside the company environment.
- Operational guardrails around what the AI could and could not do.
Why MCP Was The Right Shape
MCP was useful because it made the system explicit.
Instead of relying on a prompt that says "please be careful," the architecture could enforce real boundaries. The model could only call tools that existed. Those tools could validate inputs. The server could sanitize outputs. The business logic could live in code instead of wishful thinking.
That is the kind of AI infrastructure I trust more: less mystery, more interface design.
The Business Lesson
This project also taught the other half of the problem. A custom MCP system can be powerful, but it creates ownership questions.
Who maintains it? Who audits it? Who changes it when the business changes? Who gets called when it breaks?
That is why the final recommendation was not simply "custom AI is better than SaaS." The real answer was conditional. Custom infrastructure can win when the organization has the appetite and ownership model to support it. Without that, a technically impressive system can become a liability.
That lesson was as valuable as the build itself.