MCP: The Integration Layer

Score every MCP server against these seven before installing it on a client engagement:

**1. Coverage** — which platforms, objects, and fields does it actually reach? 'Google Ads' is not specific enough.

**2. Read vs read/write** — can the agent act, or only look? Which specific write actions are available?

**3. Auth model** — OAuth 2.1 with PKCE is the gold standard (client-manageable, rotatable, revocable). API keys embedded in URLs are fragile. Developer tokens create setup burden.

**4. Pricing transparency** — is pricing published, or 'talk to sales'? Credit-metered servers (like Clay, ~20–100 credits per action) need budget guardrails built into the workflow.

**5. Raw vs opinionated** — does it return platform data as-is, or does it apply attribution correction? Know which you're getting before you report numbers.

**6. Scale mechanics** — per-call result caps matter enormously. ZoomInfo returns 25 results per call; Explorium returns up to 1,000. A 1,000-prospect enrichment job on ZoomInfo requires 40 looping calls that eat context and slow the agent. That's an architecture decision, not a footnote.

**7. Maintenance & docs** — is the repo actively maintained? Does it have real users? Dead repos become liabilities mid-engagement.

Every ad-platform MCP surfaces self-attributed conversions — meaning Google credits itself for every conversion on a path where a Google ad appeared, and Meta does the same. A naive agent summing across both platforms will double-count and systematically flatter whichever platform touches more customer journeys.

Deliver this three-level fix in every client meeting where cross-platform data appears:

**(a) Always report per-platform** with an explicit caveat that numbers overlap.

**(b) Anchor to GA4 or CRM outcomes** as the tiebreaker — these are single-source and not self-reported.

**(c) For larger clients, use a measurement-layer server** — cross-channel attribution tools like SegmentStream, or a BigQuery MCP over a modeled attribution table.

Delivering this analysis builds more trust than any dashboard. Most competitors don't mention it.

The mature MCP stack posture has four components:

**Official servers where they exist** — HubSpot, Salesforce, Google Ads, Meta Ads, Apollo, GA4, BigQuery. These are maintained by the vendor and don't require you to write API wrappers.

**Custom servers where they don't** — any tool without an official server can get one. Writing a simple MCP wrapper is a 1–2 day job for a developer, and it becomes a reusable agency asset.

**Gateway consolidation** — one endpoint that proxies all your servers, unifying credentials and audit logs (covered in the next module).

**Safety-guarded write paths** — write operations go through a hook or approval gate; they don't fire on model intent alone.

That combination is the 2026 reference architecture. Most 'AI-native' agencies are still at read-only dashboards, which puts them at Level 2 on the ladder. Document your stack as IP.

Per-call result caps are one of the most underappreciated architecture variables in MCP selection.

Imagine a 1,000-prospect enrichment job: - On **ZoomInfo** (25 results/call): 40 API calls, each one adding results to the context window. The agent loops, context grows, and the job slows — or hits the context limit entirely. - On **Explorium** (up to 1,000 entities/call): the same job completes in a single call that stays entirely outside the main context window.

This isn't a cost footnote. It's the difference between a workflow that scales and one that breaks at 500 rows. Evaluate per-call caps before you commit to a server for high-volume work.