Let’s Go Beyond Tool Wrappers: What MCP Extensions Should Look Like in Adtech and Martech

By Dan Jaye, CTO

My recent LinkedIn post called out the industry's (so far) tool-only approach to MCP. The response: "Okay, so what SHOULD we be building?"

Here's the detailed answer on architectural patterns that would actually leverage MCP for enterprise martech and adtech workflows.

The MCP Hype Cycle Is Blocking Real MCP Adoption

When you have 10+ vendor MCP servers in a martech stack, certain capabilities need to work across ALL of them:

• Vocabulary Translation: Google's "campaign" vs Facebook's "ad set" vs TTD's "line item"
• Compliance Enforcement: GDPR consent, CCPA opt-outs, brand safety rules
• Context Management: Campaign planning flows to creative, media, and measurement

Tool-only MCP requires each vendor to implement each concern independently. That's 10 servers × 3 concerns = 30 separate implementations with no coordination.

What we need: Protocol-level extensions that work universally.

The "MCP-Compatible" Mirage

We're seeing new standards emerge that wave the MCP flag but don't actually use MCP meaningfully. Case in point: ADCP (Audience Data Context Provider) and similar efforts claim MCP compatibility while remaining completely independent protocols.

The pattern: These standards work "on HTTP and A2A as well as MCP." Translation: MCP is just one of many transport options. They don't leverage Resources, Sampling, Prompts, or any MCP-specific capabilities. They're REST APIs with optional MCP wrappers.

What they actually do: Auto-negotiate which underlying APIs are available and wrap them in a simple interface. That's it. No semantic translation. No cross-server context. No compliance framework. Just API discovery with MCP as one possible wire format.

Why this fragments the ecosystem: We end up with multiple incompatible "standards," each claiming MCP support, none actually using MCP's architectural capabilities. Enterprises choose between:

• MCP-native systems (using full protocol)
• MCP-compatible systems (tools only)
• MCP-adjacent systems (different protocol, MCP adapter)

None of them interoperate properly because they're solving different problems at different layers.

The better approach: Build extensions to MCP itself. Contribute them upstream to the core protocol or official extension registry. Don't create parallel standards that happen to speak MCP as one of several transports. We need ONE foundation with rich extensions, not multiple competing foundations with thin MCP veneers.

Why Full MCP Adoption Matters: Metcalfe's Law

The value of the MCP ecosystem follows Metcalfe's Law: network value increases exponentially with the number of interoperable nodes. Every vendor implementing only tools-only wrappers adds linear value. Every vendor implementing full MCP features (Resources, Sampling, Prompts, UI) multiplies ecosystem value.

Current state: 500 MCP servers with tool-only implementations = 500 disconnected API wrappers and 10’s of thousands of tools that can only be accessed a few at a time. Minimal network effects.

Full protocol adoption: 500 servers with Resources (shared state), Sampling (cross-server queries), and vocabulary translation = 250,000 potential interoperable workflows.

FinTech understands this. They're building context-aware, cross-vendor workflows that compound value. Adtech and martech treating MCP as "API wrapper standard" caps value at replacement-level; we replicate existing REST APIs without gaining interoperability benefits.

To build a vibrant, innovative adtech ecosystem, we need full MCP adoption across vendors. Half-measures create fragmentation, not network effects.

Extension Pattern 1: Local Proxy MCP Server Pattern

The Problem: You can't modify MCP clients (Claude Desktop, Cursor) to add enterprise governance. These clients are locked down.

The Solution: The Local MCP server acts as a proxy between the client and vendor servers, extending how vendor responses are presented to the client.

The architecture: MCP Client → Local Proxy Server → Vendor MCP Servers

The client connects to your local proxy server (which is just another MCP server from its perspective). The proxy forwards requests to vendor servers, then intercepts and transforms responses before presenting them to the client.
This pattern has been adopted and is being proven by a number of companies in the Authentication/Authorization and Security space, and is the basis for the following ad tech and martech use cases.

What this enables:

• Vocabulary Translation: A proxy receives vendor-specific terminology from servers and translates it into standard terms before presenting it to the client. The agent sees consistent vocabulary across all vendors.
• Compliance Enforcement: Proxy intercepts tool calls, validates compliance before forwarding to vendors. Returns enriched error messages with policy violations.
• Context Enrichment: Proxy augments server responses with cross-vendor context, brand guidelines, or budget constraints before the client sees them.
• Response Transformation: Proxy can combine multiple vendor responses, apply business logic, or format outputs optimally for the client.
• Why this matters: Enterprises add a governance layer without modifying locked-down clients or vendor servers. Both remain unchanged.

Extension Pattern 2: Context Continuity via Resources + Sampling

The Problem: Marketing workflows span multiple servers. Campaign planning (Google Ads) → Creative development (Adobe) → Media buying (TTD) → Measurement (analytics). Each step needs context from prior steps.

Tool-only MCP fails because tool outputs are ephemeral; they disappear when you switch servers.

The Solution: Use MCP Resources for durable state and Sampling for cross-server queries.

• Resources as workflow state: Instead of returning campaign planning via tools, publish them as addressable Resources with URIs, schemas, and versioning. Other servers reference them by URI or query them semantically.
• Sampling for cross-server context: When the creative server needs campaign context, it uses Sampling to query the planning server's LLM. The planning server answers questions about the target audience, budget, and brand guidelines,without the creative server needing to understand the planning data model.
• Workflow orchestration: Expose Resources for each stage (planning, creative, media, measurement). Each Resource includes status, approvals, dependencies, and outputs. Agents navigate by reading Resources, executing operations, and updating state.
• Business impact: Multi-vendor workflows become automated pipelines. Campaign changes propagate automatically and creative stays aligned with media strategy. Measurement reflects actual campaign parameters, not stale copies from three revisions ago.

Extension Pattern 3: Vocabulary Translation Layer

The Problem: Every vendor uses different terms:

• Campaign / Ad Set / Line Item / Insertion Order
• Audience / Segment / Cohort / Target Group
• Creative / Asset / Material / Ad Unit

AI agents trained on one vendor's terminology fail with others.

The Solution: Vocabulary as first-class Resource with translation mappings.

• Core vocabulary registry: A canonical taxonomy (likely IAB-based) defines standard terms. Each vendor server publishes a Resource declaring how their terminology maps to the standard.
• Translation at the proxy: Proxy queries vocabulary Resources from all connected servers, builds translation map. When vendor responses arrive with vendor-specific terms, proxy translates to standard vocabulary before presenting to client.
• Why this matters: Vendors build MCP servers using native terminology. Publish vocabulary mapping as Resource. Proxy handles translation. No vendor maintains multiple API flavors.

Extension Pattern 4: Guardrail Framework

The Problem: Privacy compliance (GDPR, CCPA), brand safety, and industry regulations aren't optional. Implementing them separately in every server creates compliance gaps.

The Solution: Centralized guardrail validation using all five MCP features together.

• Tools for validation: Expose compliance checking as MCP tools called before execution. Before activating an audience, call validate_privacy_compliance with criteria. Returns pass/fail with violation details.
• Resources for rules: Regulatory requirements, brand safety tiers, approved vendor lists stored as Resources. Update the Resource when GDPR rules change,all guardrail checks immediately reflect updates.
• Prompts for compliance patterns: Standard compliance check workflows as reusable Prompts. "Check if this campaign complies with pharma advertising rules in EU" becomes a single Prompt invocation.
• Sampling for distributed compliance: Before orchestrating multi-vendor workflows, query each vendor's compliance status via Sampling. "Does your server support CCPA opt-out signals?" Route based on compliance capabilities.
• MCP UI for human review: When guardrails detect violations, return UI components that render approval workflows. Legal team sees violation context, approves/rejects, decision flows back to the agent.
• Architecture inversion: The traditional approach requires N servers × M compliance rules, yielding N×M implementations. The guardrail framework requires N servers to call standardized guardrail tools, resulting in N implementations.
• Deployment: Guardrail tools can live in the local proxy server, enforcing enterprise policies before forwarding to vendor servers. Proxy intercepts responses, adds compliance metadata before client sees them.

Extension Pattern 5: Adtech and Martech Public Sub-Registries

The Reality: The official MCP Registry launched in September 2025 at registry.modelcontextprotocol.io as the "primary source of truth" for publicly available MCP servers. It stores basic metadata (name, description, package location, installation). The OpenAPI spec is open source for building compatible sub-registries.

Critical gap: The official registry is intentionally minimal and NOT designed for direct enterprise use. Enterprises need domain-specific sub-registries.

What Adtech and Martech Needs: Public sub-registries that ingest upstream data and add marketing-specific capabilities.

Martech sub-registry capabilities:

• Domain metadata: Declare what the server does,advertising, analytics, creative, measurement, audience management, attribution.
• Vocabulary support: Which taxonomies does it use? IAB taxonomy v2, custom brand taxonomies, agency-specific classifications.
• Guardrail implementations: What compliance frameworks are built in? GDPR, CCPA, brand safety tiers, pharma restrictions, alcohol advertising rules.
• MCP feature completeness: Tools-only implementation or full protocol (Resources, Prompts, Sampling, UI)?
• Industry endorsements: Third-party attestations matter. IAB Tech Lab interoperability certification. Privacy advocacy groups validating GDPR implementation. Industry consortiums confirming vocabulary compliance.
• Filtered discovery: Enterprises query: "Show me advertising servers supporting IAB taxonomy v2, implementing GDPR guardrails, with full MCP feature support." Registry returns 12 qualified servers instead of 500 possible servers.
• Extension mechanism: The official registry preserves custom metadata under the _meta property. Martech sub-registries add domain extensions without breaking the standard schema.
• Private enterprise pattern: Organizations mirror public martech sub-registries, add internal servers, and apply org-specific policies. Consistent API surface with upstream.
• Current state: The official registry is in preview (breaking changes may occur). Sub-registry OpenAPI spec is stable for development. First public martech sub-registries should emerge in Q1 2026 as the official registry reaches general availability.
• Why this matters for vendors: Publish once to the official registry. Martech sub-registries automatically discover and categorize your server. IAB Tech Lab endorsements appear in sub-registry listings without separate submissions. Enterprises find you when they query for their requirements.

What's needed: Industry collaboration on:

• Standard domain classifications for martech and adtech
• Vocabulary taxonomy references (IAB, custom)
• Guardrail capability declarations
• Endorsement schemas for IAB Tech Lab, privacy groups
• MCP feature support badges

Without martech-specific sub-registries, enterprises test your MCP server manually. With them, you're discoverable based on actual capabilities.

Implementation Realities

Host support is limited: Of 23 mainstream MCP clients, 15 support only Tools, 4 support two features, zero support all five.

Proxy pattern works today: Deploy local proxy MCP server that intercepts vendor responses before clients see them. Works with Claude Desktop, Cursor, any MCP host without waiting for updates.

Start with Resources + Sampling: Create immediate value (workflow continuity) and easiest to add if you're already implementing Tools.

Vocabulary can be incremental: Publish your terminology as a Resource. Proxy servers handle translation. Contribute mappings to community registries over time.

Guardrails benefit everyone: Compliance failures hurt vendors as much as customers. Standardized guardrail tools reduce your liability and increase customer trust.

Sub-registries are urgent: Without martech-specific discovery, enterprises can't efficiently evaluate 500+ servers. We need domain classification now.

The Strategic Choice

Two paths forward:

Path 1: Keep wrapping REST APIs in tools-only servers. Wave the MCP flag while building independent protocols. Wait for industry standards. Incremental adoption, low risk, slow differentiation, eventual fragmentation.

Path 2: Implement full MCP features now. Publish vocabularies as Resources. Support Sampling for context queries. Add MCP UI components. Build extensions to MCP itself, not parallel standards. Participate in martech sub-registry development: fast differentiation, higher initial effort, and category leadership.

FinTech chose Path 2. Adtech and Martech are choosing Path 1, while marketing departments are choosing Path 2. The gap widens monthly.

The protocol has evolved and continues to evolve to give us everything we need. We're just not using it ... yet.