Marketo MCP server, set up for enterprise

What Adobe actually shipped

On 15 April 2026, Adobe published documentation for a hosted Marketo MCP server on Experience League. The timing is not incidental. Adobe Summit opens in Las Vegas on 19 April, with at least one session dedicated to Adobe MCPs on the agenda. The Marketo entry has arrived ahead of the keynote, quietly, in the developer documentation.

The product itself is straightforward in scope. It is an HTTP-based Model Context Protocol server, hosted by Adobe, that exposes more than one hundred Marketo Engage operations across eight object domains: forms, programs, smart campaigns, leads, emails, snippets, lists, and folders. An AI client speaking MCP can call those operations through a single endpoint, authenticated per request with custom HTTP headers tied to your Marketo instance.

What Adobe has done here is take the existing Marketo REST API and dress it in a protocol that AI tools already speak. The REST API itself has not changed. Rate limits, permissions, and concurrency constraints all inherit from the underlying instance. Think of the MCP server as a translator layer, not a new integration surface.

The four headers Adobe mentions and the three it names

Start with a factual note that will save time during setup. Adobe's documentation explicitly states that "all four headers" are required on every request to the MCP server. The same page then lists only three headers by name in its configuration examples. The fourth header is the Marketo REST endpoint for your instance, typically expressed as X-Marketo-Endpoint, which points your requests at the correct Marketo REST host for your Munchkin ID.

In practice, every working configuration includes all four. Adopt that pattern from the start, even if Adobe's examples suggest otherwise.

The API user you actually want

This is the single most important decision in the setup, and the one most teams rush through. The MCP server does not authenticate as Adobe. It authenticates as whatever Marketo user is behind the LaunchPoint service you register. Every operation it performs inherits that user's role and permissions.

That means the question is not "how do I make it work" but "what do I want it to be allowed to do." A shared Marketo admin account handed to every AI tool in the organisation is the wrong shape of answer.

The setup that works in practice:

1. Create a dedicated Marketo user named for the purpose (for example mcp-readonly@yourcompany.com or mcp-assistant@yourcompany.com). Do not reuse a human user.
2. Assign a least-privilege role. For first rollout, a read-only role is correct. You can read assets, list leads, inspect smart campaigns, and observe behaviour for days before deciding what to grant write access to.
3. Create a LaunchPoint service under Admin → LaunchPoint → New Service → Custom, linked to the dedicated user. This generates the Client ID and Client Secret you will use in the MCP headers.
4. Store credentials as environment variables, not plain text. Adobe's own docs explicitly recommend this, and every config example below uses that pattern.
5. Split by use case if needed. A separate API user and LaunchPoint service for read-only exploration versus one for authorised write operations is entirely reasonable. The Marketo side cost is effectively zero. The governance benefit is real.

When you are ready to grant write access, do it role by role: asset read-write for operations that clone or edit forms and emails, lead database read-write for triage work, smart campaign activation separately. Do not assume "MCP needs admin" is a real constraint. It rarely is.

Client compatibility: what actually works today

This is the section that Adobe's documentation skips for reasons of tact. Not every MCP client supports custom HTTP header authentication in the same way. Some support it natively in their config files. Some support it only through an adapter. Some support it only when an admin enables developer mode. One major enterprise client does not support it at all without a wrapper.

The matrix below reflects the state at the time of writing. Test it in your environment before committing production workflows.

Configuration examples

The three configs below cover the most common enterprise paths. Each uses environment variables so no credential is written in plain text. Replace the variable names with your secret-management tool of choice.

Claude Code (CLI)

Claude Code supports remote MCP servers with custom headers natively. Place this in a .mcp.json at the project root or in your user-level settings.

{
  "mcpServers": {
    "marketo": {
      "type": "http",
      "url": "https://marketo-mcp.adobe.io/mcp",
      "headers": {
        "X-Marketo-Client-Id": "${MKTO_CLIENT_ID}",
        "X-Marketo-Client-Secret": "${MKTO_CLIENT_SECRET}",
        "X-Marketo-Munchkin-Id": "${MKTO_MUNCHKIN_ID}",
        "X-Marketo-Endpoint": "${MKTO_REST_ENDPOINT}"
      }
    }
  }
}

VS Code with GitHub Copilot

Add to .vscode/mcp.json in your workspace or to the user-level MCP configuration. Identical structure to Claude Code.

{
  "servers": {
    "marketo": {
      "type": "http",
      "url": "https://marketo-mcp.adobe.io/mcp",
      "headers": {
        "X-Marketo-Client-Id": "${env:MKTO_CLIENT_ID}",
        "X-Marketo-Client-Secret": "${env:MKTO_CLIENT_SECRET}",
        "X-Marketo-Munchkin-Id": "${env:MKTO_MUNCHKIN_ID}",
        "X-Marketo-Endpoint": "${env:MKTO_REST_ENDPOINT}"
      }
    }
  }
}

Claude Desktop (config file, not the UI)

The Claude Desktop web UI for custom connectors only supports OAuth. For header-based authentication with Marketo, edit the config file directly. On macOS it lives at ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, it is in %APPDATA%/Claude/. Current Claude Desktop builds support the same "type": "http" direct configuration as Claude Code and Cursor, which is the simplest path and the one Adobe's docs now show.

{
  "mcpServers": {
    "marketo": {
      "type": "http",
      "url": "https://marketo-mcp.adobe.io/mcp",
      "headers": {
        "X-Marketo-Client-Id": "${MKTO_CLIENT_ID}",
        "X-Marketo-Client-Secret": "${MKTO_CLIENT_SECRET}",
        "X-Marketo-Munchkin-Id": "${MKTO_MUNCHKIN_ID}",
        "X-Marketo-Endpoint": "${MKTO_REST_ENDPOINT}"
      }
    }
  }
}

Legacy fallback. On older Claude Desktop builds that predate native HTTP MCP transport, the mcp-remote adapter is the standard workaround. It runs as a small local process that bridges stdio-based MCP to the remote HTTPS endpoint while injecting headers via --header arguments. If the direct config above does not register the server, switch to this pattern:

{
  "mcpServers": {
    "marketo": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://marketo-mcp.adobe.io/mcp",
        "--header", "X-Marketo-Client-Id:${MKTO_CLIENT_ID}",
        "--header", "X-Marketo-Client-Secret:${MKTO_CLIENT_SECRET}",
        "--header", "X-Marketo-Munchkin-Id:${MKTO_MUNCHKIN_ID}",
        "--header", "X-Marketo-Endpoint:${MKTO_REST_ENDPOINT}"
      ]
    }
  }
}

Three governance moves before exploration

If this server is going to be allowed near production workflows, three things should be in place before the first write operation fires.

Munchkin ID allowlist. Adobe's MCP server enforces an allowlist at the account level. Requests using an unauthorised Munchkin ID are rejected with a 403. Confirm that only the instances you intend to reach are in scope. For a multi-instance Marketo footprint, this is where segregation between production and staging starts.

Client-side tool allowlisting. All four supported clients (Claude Desktop, Claude Code, Cursor, VS Code) let you allowlist specific MCP tools rather than enabling the full set. Use this. For read-only exploration, the list of permitted tools should be explicit and narrow. Expand deliberately.

Read-only first, write access on request. Start with a read-only API user, observe behaviour for a week, and review call logs before granting write access to anything. The observability comes from Marketo's own API audit trail under Admin → Integration → Web Services. Treat the first week as a staging period whether or not you have a separate sandbox instance.

Five tasks worth running first

Once it is wired in and the API user is read-only, these five tasks reliably demonstrate value without touching live assets.

1. Asset inventory and triage. Ask the model to list every email program or smart campaign touched in the last 90 days, grouped by owner. Useful before an audit, a migration, or a team transition.
2. Smart campaign hygiene. Pull every active smart campaign with no recipients qualified in the last 30 days. These are usually candidates for archival.
3. Form field review. Generate a matrix of every form with its field count, mandatory fields, and progressive profiling settings. Good input for a consent and data-minimisation review.
4. Email template audit. Identify templates with broken personalisation tokens, missing unsubscribe links, or unusual sender patterns. A standing QA task that is tedious manually and trivial for an MCP-equipped model.
5. Lead database snapshot. Count leads by country, by score band, by lifecycle stage, by CRM-sync status. Baseline figures that many teams keep in spreadsheets for reasons of habit rather than necessity.

None of these require write access. All five produce output that a marketing operations lead can act on in the same session.

What not to do yet

Three places where the current state of this stack does not yet justify production reliance.

Do not connect real-time customer journeys to AI-triggered writes. The MCP server lets an AI client activate smart campaigns, modify lead records, and send emails through the underlying REST permissions. That capability, in the hands of a non-deterministic model, belongs in a sandbox until your organisation has reviewed error-handling, retry logic, and audit expectations.

Do not assume the M365 Copilot path is shorter than it looks. Building a Copilot Studio declarative agent to wrap the Marketo MCP is a real project: authentication configuration, OAuth vault setup, agent publishing, licensing for end users. If your enterprise is standardised on M365 Copilot, wait for Microsoft's direct MCP connector experience to mature, or build a small internal proxy rather than over-investing in a wrapper that may be obsoleted.

Do not share one API user across teams. The Munchkin allowlist segregates instances but not teams. If marketing operations, revenue operations, and a central data team will all use the MCP, give them distinct LaunchPoint services and distinct API users. The audit trail will thank you.

Where this fits

For most enterprise Marketo users, the Marketo MCP server does not change what is possible. It changes who can do it, and how quickly. A marketing operations analyst who previously needed a developer or a specialised Marketo admin to produce an asset inventory or a smart-campaign audit can now ask for one in natural language and get a usable answer back in seconds. That is a meaningful shift in the distribution of operational capability, even if the underlying API has not moved.

The strategic question above the setup question is whether this capability belongs in a set of named service accounts governed by marketing operations, in a Copilot Studio agent governed by the central IT platform team, or in a chat connector governed by whoever happens to be the workspace admin that day. That choice is more consequential than which AI tool sits in front of it. The MCP server is a surface. The governance sits underneath.

If you are thinking about how AI access to Marketo fits into your broader Adobe or MarTech governance posture, IDADAY advises on exactly this question: where strategic and technical decisions about AI-enabled marketing operations should sit, and how to avoid building capability faster than the governance around it.

Related analysis

Adobe Data Breach 2026: Why Marketo, AEP, and AJO B2B Users Should Read Their Support History → Why Enterprise AI Value Starts Below the AI Layer → The AI Mandate Foundation Problem →