Case Study: MCP Server Rollout at a Marketing Agency

This MCP server rollout at a marketing agency is the case study we point clients at when they ask whether an agentic AI rollout pays for itself at a sub-fifty-person scale. Twelve consultants across four practice groups — analytics, CRM, content, design — were building one-off AI workflows in isolation, reinventing the same credential plumbing and the same retrieval shapes every quarter. Over ninety days we replaced that with a shared MCP capability catalog, a single distribution model, a security audit baseline, and a governance charter the agency now owns and runs itself.

The agency has asked to stay anonymous. Names, account identifiers, and tool-internal labels are redacted; the four capability areas, sequencing, distribution model, audit baseline, governance gates, and outcome shape are reproduced faithfully from the engagement notebook. Where numbers appear they are the ones in our records; where ranges appear it is because the underlying variance was larger than a single point estimate would honestly convey.

This guide pairs cleanly with our org-deployment playbook — the 30/60/90-day MCP rollout plan — and with the audit baseline used in §04. If you are running this internally on a similar scale, the two documents are designed to be read together; the playbook supplies the abstract sequencing, this case study supplies the concrete shape.

The agency runs four practice groups — paid media and analytics, CRM and lifecycle, content and editorial, and brand and design — staffed by twelve senior consultants and a small platform team shared across all four. Each practice group had been quietly building its own AI scaffolding over the previous year: a custom GA4 retrieval wrapper here, a HubSpot-extract script there, a content brief generator built directly against a vendor API, a brand-system retrieval over the agency's asset library. None of these were unreasonable on their own; the problem was that there were twelve of them.

The first conversation that surfaced the rollout was a senior account director asking why three different consultants had independently built three different versions of a tool that pulled the same campaign-performance metrics out of the same GA4 properties. The honest answer was because no one owned a shared one. The deeper problem was that each version had its own credential scope, its own audit-log story (mostly: none), its own assumptions about which properties were in scope, and its own bug surface. Multiplying that pattern across analytics, CRM, content, and design was untenable, and the agency knew it.

Two specific incidents in the six weeks before the engagement sharpened the brief. First, a consultant left and the GA4 integration she had built turned out to have been running under a shared service-account credential that nobody else knew the scope of; the credential was rotated reactively and three live workflows broke. Second, a content-team script that wrapped a vendor API for editorial drafts was found to be logging the full vendor response — including PII passed through in customer-research inputs — to a debug file that had quietly grown to several gigabytes. Neither incident was catastrophic; both made the case for a shared, audited surface much more concrete.

The leadership ask was specific: one capability catalog, one distribution model, one audit baseline, one governance charter, and a quarterly cadence that the platform team can run without our help after handover. The ninety-day horizon was their constraint, not ours; the agency's client-reporting cycle made starting fresh in any other quarter operationally awkward, and the platform team had a roughly three-person-month budget to spend on internal infrastructure before client work re-claimed the calendar.

The phase-one inventory closed with nine MCP-eligible workflows grouped under four capability areas. Each area got a single shared server in the new catalog, with the per-consultant variants either folded in as tool variations or deprecated outright. The grid below names each area, the tools it exposes, and the downstream systems each one wraps; the design rule across all four was the same — shared auth library, scope-bound tokens, centralised structured audit logging at the tool boundary.

One design decision worth flagging up front: narrow tool surfaces, not omnibus tools. The temptation in phase two was to expose "search the CRM" or "run an analytics query" as a single tool with a generic argument shape; we rejected those in favour of named, narrow tools that map cleanly onto specific consultant workflows. Narrow tools audit better, scope better, and version better; omnibus tools collapse the audit trail and make scope-limiting nearly impossible.

Two of the four servers in the catalog hold a small number of mutating tools (CRM note creation, design-system revision prototype); the other two are read-only by design. We weighted heavily toward read-only on the first pass because the audit-and-rollback story for mutations is qualitatively harder than for reads, and the agency's appetite for risk on mutations was — sensibly — lower than its appetite for retrieval-driven AI assistance.

One pattern that paid off across all four servers: per-client scope tokens, not per-consultant tokens. Every catalog server validates that the calling agent's token carries an explicit client-scope for the workflow it is running. The shared auth library enforces this; the consultant doesn't have to remember. The result is that cross-client data leaks — the single highest-cost failure mode in an agency context — become structurally hard to ship, not merely policy-disallowed.

The three distribution models we usually recommend — project-scoped, plugin-marketplace, and internal registry — each fit a different band of organisational scale. The phase-one inventory at this agency closed with nine workflows across twelve consumers; the shape of that population pointed cleanly at the lightest of the three. Heavier models would have brought ceremony — manifest schemas, hosted registries, signing pipelines — that pays off at larger scale and would have impeded shipping here.

Project-scoped in practice meant a single internal monorepo holding the four catalog servers, published to an internal npm scope, consumed by each consultant's Claude Desktop config and the agency's internal agent runner. Versioning was per server. Updates were pull-based on the consumer side, with a shared release-notes feed the platform team posts to. The full decision matrix is in our org-deployment playbook; the choice here was made on three specific signals.

One framing rule held across the decision: pick the lightest model that still works, with a documented re-pick gate when the population doubles. The platform team committed in writing to revisiting the model when the catalog crossed roughly fifteen servers or when an external-facing consumption surface — for instance, a client-side agent — required signed packages. Until then, the project-scoped model is the explicit choice rather than the default.

A second pattern worth naming: signing was deferred, not skipped. At twelve consumers, git provenance plus internal npm scope plus monorepo access control gave the supply-chain story enough teeth. The governance charter explicitly names the trigger for moving to a signing pipeline; the platform team is not pretending signing doesn't matter, just that the cost of building it now exceeds the marginal safety it would add at this scale.

Every server in the catalog passed the 75-point security audit before being added; servers that failed were remediated before consumer teams could wire against them. The matrix below names the three audit pathways we ran and what each one returned. The audit baseline is the same one documented in our companion checklist; the application here was per-server, with the four servers in the catalog audited sequentially as they hit phase-two completion.

One sequencing rule held across the audit: distribution channel live but empty until audit pass. The npm scope went live in week five with zero published servers. Catalog servers were added one at a time as each audit cleared. The discipline of the freeze is what makes the audit gate real rather than aspirational; without it, the channel becomes convenient, servers ship through it, and the audit becomes a retrospective "we'll get to it" that never lands.

Three categories of finding surfaced across the four-server audit pass. Critical findings — two in total — were landed inside phase two: a service-account credential scoped wider than the consumer-facing tool required, and a content-server tool that wrote vendor responses to a debug log without redaction. Both were the kind of finding the phase-one-incidents had foreshadowed; both took less than a day to remediate once named. High findings — eleven in total — were sorted onto a remediation backlog with named owners and target dates; all but one were closed before catalog open. Medium and low findings — twenty-three in total — were filed onto the quarterly re-audit schedule with no phase-two pressure to land.

The most consequential finding in the entire pass was on the smallest server. A content-retrieval tool that wrapped a single read against the editorial corpus turned out to hold a credential scoped for convenience rather than for least authority; the same credential could mutate the corpus the tool was nominally read-only against. Size is uncorrelated with blast radius. The full audit baseline is in our 75-point MCP server security audit checklist — every catalog server was audited against every point in that checklist, every time.

The governance charter the agency now owns is two pages, names four gates, and was written and ratified inside phase three. The shape is the one we recommend in the org-deployment playbook; the specifics were adapted to the agency's approval flows and to the per-client scope-token rule. Charter ratification — platform lead, senior account director, and the head of the content practice signing — happened in week ten; the charter went live in week eleven alongside the re-audit schedule.

Two practical notes on writing the charter. First, length matters less than enforceability. The two-page draft we shipped is enforceable because every gate names its evidence — what artifact closes the gate, who reviews it, and where the decision is logged. A longer charter without named evidence is a longer document, not a stronger control. Second, the charter is the document that lets the platform team say nowithout it becoming a political fight every time a consultant proposes a new server. That mattered more than expected once the catalog opened and consumer demand started to outpace the platform team's phase-three throughput.

One operational pattern from this phase worth calling out: the per-tool kill-switch. The shared auth library ships with a feature-flag check at each tool entry point. The platform lead and the on-call rotation each have flip authority without further approval; flipping a flag disables a single tool catalog-wide within minutes, independent of deploy. The kill-switch hasn't had to be used in production at this agency yet; the value of having it is that the incident-response runbook stops being theoretical.

On the on-call rotation: with a twelve-consultant agency and a small platform team, a formal pager rotation would have been ceremony exceeding the threat model. The compromise the charter names is business-hours coverage with named escalation — the platform lead is the primary contact during agency hours, with a senior consultant in each practice group named as the secondary for tools their group owns. Out-of-hours coverage is opt-in via the on-call channel; this fits the agency's actual incident shape better than imposing twenty-four-seven pager culture on a team that doesn't run client services overnight.

The outcomes below are the ones we measured at day ninety, with a soft check-in at day one-eighty for the cadence-related metrics (re-audit pass rate, consumer adoption, charter enforcement instances). Numbers are rounded where the underlying variance was larger than the rounding error; ranges appear where a single point estimate would be misleading.

The headline outcome is the one in the takeaways: tool reinvention was eliminated. Nine parallel AI workflows became four shared catalog servers, all twelve consultants now call into the same surface for analytics, CRM, content, and design retrieval, and the platform team owns one well-audited substrate instead of supporting twelve loosely-coupled ones. The structural change is what compounds; the per-metric outcomes below are evidence that the structural change held.

On softer outcomes — time-to-deliverable, consultant satisfaction, the rate at which the platform team gets pulled into one-off integration questions — the picture at day ninety is consistent rather than dramatic. Time-to-deliverable on analytics-driven reports dropped by a band the agency characterised as "noticeable but not transformational"; the platform team reported being pulled into roughly a third of the one-off integration conversations they had previously been pulled into; consultants surveyed at day eighty named the shared catalog as the biggest single change to their workflow over the quarter. None of those are headline-grade numbers in isolation; the structural change is what makes them compound over the following quarters.

One caveat worth being honest about: the rollout was paid engineering time the agency reallocated from client work for one quarter. The structural payoff is real; the cost was real too. For agencies considering whether to replicate this internally, the right framing is that ninety days of focused platform-team investment buys you a substrate that the following quarters of client AI work sit cleanly on top of — but the ninety days have to come from somewhere, and the discipline of the freeze (no new servers shipping outside the new pipeline during phase one) is harder than the engineering. That part is procedural, not technical.

Three lessons we'd carry forward to any similar agency rollout, and one we'd change in retrospect. Each is anchored in something that surfaced during the ninety days, not in abstract best practice.

Keep: narrow tools, not omnibus tools.The single biggest design decision that paid off across all four servers was the discipline of named, narrow tools per workflow. Omnibus tools — a single "query the CRM" with a free-text argument — would have collapsed the audit trail and made scope-limiting nearly impossible. Narrow tools audit cleanly, scope cleanly, and version cleanly; they also give the kill-switch a meaningful unit of operation. We'd hold that line again.

Keep: per-client scope tokens, not per-consultant tokens.Cross-client data leak is the single highest-cost failure mode in an agency context. Per-client scope tokens, validated by the shared auth library, made the leak structurally hard to ship rather than merely policy-disallowed. Every catalog server inherits this from the library; the consultant doesn't have to remember. We'd hold this line again, harder than we held it the first time.

Keep: re-audit cadence aligned to client cycles. Anchoring the quarterly re-audit to the agency's client-reporting cycles rather than to a calendar quarter made the cadence operationally compatible with how the agency actually plans its workload. Calendar-quarter cadence would have collided with peak client deliverable weeks for at least two of the four practice groups. Map the cadence onto the agency's rhythm, not onto an abstract calendar.

Change: prototype the design-system create tool inside phase two, not at the boundary of phase three.The create-revision tool for the design-system server was prototyped late in phase three and held back for a phase-four engagement because we ran out of audit-and-review runway. With hindsight, we should have either committed the prototype tool to phase two with a clear audit slot, or named it out of scope at the engagement brief. The middle path — "let's see if we can squeeze it in" — cost more attention in the closing week than it saved.

For agencies considering whether to run this internally, the plan in this case study is sufficient to drive a credible rollout on your own. The reason agencies engage us is rarely capability; it is calibration — having seen the failure cluster and the sequencing trade-offs across a handful of similar rollouts, the early decisions get made faster and the governance charter lands in the form that prevents the failure modes we've seen most often. If that calibration matters, our agentic AI transformation engagements include agency MCP rollouts as a discrete deliverable. If it doesn't, the plan above is yours to run, and the org-deployment playbook is the abstract sequencing it sits on.