CRM assistant over MCP
An assistant that does real CRM work through tools reached over MCP, with approval on the calls that write.
The problem
An assistant that can only talk is half a tool. Users want it to actually do the CRM work — create a lead, log a call, send a follow-up — but hardcoding each integration is brittle and every new tool means new glue code.
You want the assistant to reach real tools over MCP, so the tools live behind a standard protocol instead of bespoke wiring, with approval on the ones that write. Add a tool by connecting a server, not by editing the agent.
Architecture
The agent talks to tools through one protocol. A user asks, the agent decides which tools it needs, it calls them over MCP where each integration is a server, the CRM actions run, and the agent reports what it did. MCP is the seam that lets you add a tool without touching the agent.
Put approval on the writes, not the reads. Looking a contact up is safe to do freely; creating a lead or sending an email is a call that should be confirmable, and the protocol boundary is a natural place to enforce it.
What it draws on
Everything here comes from this stage of the roadmap; the project is where those courses meet.
- OpenAI Agents SDK: handoffs and agents as tools
- MCP: build the server, with approval on risky tools
- Claude Code: MCP, skills and subagents
- Topic: SSO, OAuth and RBAC
What done looks like
| Requirement | Done when |
|---|---|
| MCP | The CRM is reached only through your MCP server |
| Permissions | A rep never sees another rep's accounts |
| Drafts | Emails are drafted, never sent, without approval |
| Failure | An expired token produces a clear message, not a crash |
Where to start
Get the agent calling one read-only tool over MCP before anything writes. Prove the protocol path end to end, then add a write tool with an approval step. Adding the third tool should be a matter of connecting a server — if it means editing the agent, the seam is in the wrong place.
Every expert started right here.