The problem
Over roughly two years, the client's sales organization had accumulated five separate ways for AI assistants to touch their CRM: a Python script one rep maintained for pulling account data into a spreadsheet, a browser extension a sales-ops analyst had built for updating deal stages in bulk, and three other ad hoc integrations of varying quality. None shared an access model, two stored CRM API credentials in plaintext config files on individual laptops, and when the sales-ops lead tried to audit what had touched customer records over the past quarter, there was no consistent log to check.
This wasn't a customer-facing problem (no customer data was exposed externally), but it was a real internal risk: five inconsistent write paths into a CRM holding contract values, contact details, and deal history, with no unified permission model and no single place to see what an AI-assisted tool had changed and why.
What we actually did
We built a single MCP server exposing five specific, scoped CRM operations (account lookup, contact lookup, deal-stage read, deal-stage update, and note creation), replacing all five of the previous ad hoc integrations with one reviewed, centrally logged path.
Week 1: auditing what the five existing tools actually did
Before building anything, we cataloged exactly what each of the five existing scripts and extensions touched in the CRM, because nobody, including the sales-ops lead, had a full picture. This turned up one integration with write access to a pricing-override field, granted for a one-time project eighteen months earlier and never revoked. That kind of access creep made the case for centralizing better than we could have.
Week 2: designing read and write as genuinely different tools
Account lookup, contact lookup, and deal-stage read are low-friction, broadly available tools, because misusing a read operation has limited downside. Deal-stage update and note creation are scoped more tightly. An agent can change a deal stage only through a defined set of valid transitions (no jumping from "prospecting" straight to "closed-won," for instance). Every write is logged with the calling agent's context and a human-readable summary of what changed, in a form the sales-ops team can audit directly instead of digging through raw API logs.
Weeks 3-4: migrating five teams off their old tools and onto one
Migration meant more relationship work than engineering work. Each of the five existing integrations had a specific person who'd built or depended on it. We ran individual walkthroughs with each of them to confirm the new MCP server's tools covered their use case before deprecating their old script, rather than announcing a cutover date and hoping.
Challenges and tradeoffs
- The pricing-override access-creep finding required an uncomfortable conversation with sales leadership. Explaining that an integration had held unrevoked write access to pricing overrides for eighteen months wasn't a conversation the sales-ops lead wanted to have alone. We joined that meeting and presented it as a systemic gap the new server was designed to close, not a blame exercise aimed at whoever originally granted the access.
- Defining valid deal-stage transitions meant encoding sales-process knowledge that lived only in people's heads. Nothing written down defined which stage transitions were legitimate and which were data-entry mistakes. We worked with the sales-ops lead to define this explicitly, which surfaced edge cases (such as deals reopened after being marked closed-lost) that needed their own transition rules rather than being blocked outright.
- One rep's old script did something the new tools deliberately don't support, and we had to say no. The bulk deal-stage extension let a rep move dozens of deals at once with minimal per-deal review. It was fast, but it was also likely how the pricing-override issue went unnoticed for so long. We didn't replicate bulk updates in the new tools, trading some convenience for the auditability the project was meant to establish.
Results
All five previous ad hoc integrations were retired within four weeks of the new MCP server's rollout, and every sales agent's CRM access now runs through the same reviewed, logged tool set. In the three months since launch, no AI-initiated write has touched a CRM field outside the scoped tools, which the sales-ops lead has pointed to when presenting the project to the client's IT security team as a model for other internal tool consolidation.
The server's audit log has already been used to resolve a dispute about when and why a deal's stage was changed. Under the old sprawl, where at least two integrations kept no meaningful log at all, that question would have been unanswerable.
What we'd do differently
We'd run the access audit of the five existing tools before scoping the new server's design, rather than in the same week. The pricing-override finding changed how tightly we scoped write access, and learning it a few days earlier would have saved a little rework on the initial tool-schema draft.