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, ahead of Adobe Summit (19-22 April), where it was spotlighted as a flagship component of Adobe's "CX Enterprise" positioning and its agentic AI vision. On 22 April the docs were marked "closed beta". The May 2026 release notes then listed the server as "open beta" with a phased rollout from 22 May, Adobe's 3 August 2026 blog post repeated the label and made the access model explicit ("access starts with a request rather than a settings toggle"), and the developer docs were refreshed on 7 and 12 August with a new operations catalogue, a simplified authentication section, an IMS-token option, and setup instructions for two more clients. As of 18 August 2026 the docs still carry a "Limited Availability" badge and a request form. There is no general-availability announcement.

The product itself is straightforward in scope. It is an HTTP-based Model Context Protocol server, hosted by Adobe, that exposes a curated set of Marketo Engage REST operations. Adobe still describes it as "more than 100 operations"; the catalogue of 7 August names 133 tools in twelve categories: forms, smart campaigns, programs, smart lists, snippets, leads, emails, folders, static lists, bulk export, tokens, and channels and tags. Forms and smart campaigns are by far the largest groups. An AI client speaking MCP calls those tools through a single endpoint, authenticated per request with credentials tied to your Marketo instance.

What Adobe has done here is take a slice of 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 and from the API user behind the LaunchPoint service. Think of the MCP server as a translator layer with a curated vocabulary, not a new integration surface.

Three headers, or an IMS token: the fourth header is gone

Start with the thing that changed. When this guide was first published, Adobe's documentation said "all four headers" were required on every request and then named only three, and early configurations (including the ones in the first version of this guide) carried a fourth X-Marketo-Endpoint header pointing at the instance's REST host. The August 2026 documentation drops that. Every configuration example now sends exactly three Marketo headers, the "all four" sentence is gone, and the only trace of the endpoint left is one line in the security section noting that the REST API endpoint travels in headers. There was never much reason for it: a Marketo REST host is derived from the Munchkin ID (https://XXX-XXX-XXX.mktorest.com/rest), so the server can work it out on its own.

Adobe also documents a second way in. Instead of Marketo client credentials you can send an Adobe IMS bearer token in the Authorization header plus your IMS organisation ID. Adobe does not yet explain how to mint that token for Marketo specifically; if your subscription is administered through the Adobe Admin Console, your Adobe developer team will recognise the pattern from other Adobe APIs. Send the headers for one method or the other on each request, not both.

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 where the client allows it (Claude Desktop's bridge is the exception, and is called out below).
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, emails and snippets, list membership for triage work, smart campaign activation separately. Adobe's own governance notes describe permissions as flowing from "the Marketo API-only user assigned to the customer's LaunchPoint service", so the role on that user is the real control. 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 still handles with tact. Not every MCP client supports custom HTTP header authentication in the same way. Some take headers natively in a config file. One needs a local bridge. One needs its vendor's support team. Two of the biggest enterprise assistants do not accept custom headers at all without something in front of the server.

The matrix below reflects Adobe's documentation of 12 August 2026 plus the client vendors' own docs. Test it in your environment before committing production workflows.

Adobe's August blog post also names Windsurf and Google Gemini as supported, and beta participants report the Gemini CLI connecting with the standard three headers. Any client that speaks streamable HTTP and lets you attach static headers should work; the ones above are the ones Adobe or the vendors have documented.

Configuration examples

The configs below cover the most common enterprise paths. Each references environment variables wherever the client supports it, 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}"
      }
    }
  }
}

Adobe's docs show the CLI form instead, which writes the same entry for you. Note that your shell expands the variables when you run it, so the values land in Claude Code's config in plain text; if that matters, prefer the JSON above.

claude mcp add --transport http marketo 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}"

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}"
      }
    }
  }
}

Cursor uses the same mcpServers shape as the Claude Code JSON above, in .cursor/mcp.json or via Settings → MCP.

OpenAI Codex (app, CLI, IDE extension)

Adobe's docs walk through the Codex settings UI: Settings → MCP Servers → Add Server, paste the URL, add the three headers, save. If you prefer a file, Codex reads ~/.codex/config.toml (or a project-level .codex/config.toml), where env_http_headers maps header names to environment variable names so the secrets stay out of the file.

[mcp_servers.marketo]
url = "https://marketo-mcp.adobe.io/mcp"

[mcp_servers.marketo.env_http_headers]
"X-Marketo-Client-Id" = "MKTO_CLIENT_ID"
"X-Marketo-Client-Secret" = "MKTO_CLIENT_SECRET"
"X-Marketo-Munchkin-Id" = "MKTO_MUNCHKIN_ID"

Claude Desktop (Adobe's bridge, not the UI and not the HTTP transport)

Two things do not work here, and earlier versions of this guide got one of them wrong. The Connectors UI (and claude.ai on the web) only accepts OAuth, so it cannot carry the Marketo headers. And claude_desktop_config.json only launches local stdio servers: a "type": "http" entry with a headers block, which is what Claude Code and Cursor accept, is ignored by Claude Desktop and has been reported to be stripped from the file on save. What works is a small local process that speaks stdio to Claude Desktop and HTTPS to Adobe. Adobe now provides one: download marketo-mcp-bridge.zip from the Claude Desktop section of its docs, unpack it, put marketo-mcp-bridge.mjs somewhere stable, install Node.js v18 or later, and point the config file at it. On macOS the file lives at ~/Library/Application Support/Claude/claude_desktop_config.json, on Windows in %APPDATA%/Claude/.

{
  "mcpServers": {
    "marketo-mcp": {
      "command": "node",
      "args": ["/path/to/marketo-mcp-bridge.mjs"],
      "env": {
        "MARKETO_MCP_PROD_CLIENT_ID": "<your-client-id>",
        "MARKETO_MCP_PROD_CLIENT_SECRET": "<your-client-secret>",
        "MARKETO_MCP_PROD_MUNCHKIN_ID": "<your-munchkin-id>"
      }
    }
  }
}

One caveat: Claude Desktop's env block holds literal values, not references, so this is the one config in this guide where the secret sits in a file. Restrict the file's permissions, or wrap the bridge in a short launcher script that reads the three values from your secret store and exports them before starting Node.

Community equivalent. Before Adobe shipped its bridge, the mcp-remote adapter did the same job and it still does. It runs as a small local process that bridges stdio-based MCP to the remote HTTPS endpoint while injecting headers via --header arguments, and it expands ${VAR} references itself, which keeps the secrets out of the file:

{
  "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}"
      ]
    }
  }
}

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.

Per-instance enablement. Adobe switches the server on per Marketo instance; that is what the Munchkin ID allowlist is. Requests for an instance that has not been enabled are rejected with a 403, and Adobe's troubleshooting advice is to "contact your Marketo MCP administrator to enable MCP access for your Munchkin Account ID". Request enablement only for the instances you intend to reach. For a multi-instance footprint this is where segregation between production and sandbox starts: enable the sandbox first.

Client-side tool allowlisting. Every documented client lets you enable a subset of MCP tools rather than the full set, and Adobe's own advice is to deselect the APIs you do not want the assistant to reach. 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 what it did before granting write access to anything. Be realistic about what "review" means here. Marketo does not give you a per-call log of the MCP server's activity: Admin → Web Services (and the REST usage endpoint behind it) show daily API call and error counts per API user, and Audit Trail records asset and admin changes attributed to that user. Adobe keeps its own structured, masked server logs for operations and compliance, not for you to browse. A dedicated API user per use case is therefore the only way to attribute what happened, which is one more argument for the setup above. Treat the first week as a staging period whether or not you have a separate sandbox instance.

What Adobe commits to, in its own words. The server forwards the credentials you send on each request and "does not store or cache them"; each request "uses its own set of credentials" in a tenant-isolated environment; the server does not "use, host, or run any AI or machine learning models" and does not "train on or learn from any data, including your customer data"; and Adobe's August blog post states that Adobe "doesn't use any MCP server prompts for model training". Those are useful sentences to have in a vendor-risk file. They do not change the fact that the assistant on the other end of the connection is your responsibility, not Adobe's.

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. List every active smart campaign, when it last ran or is next scheduled, and what it is used by. Campaigns that have not run in months and are used by nothing are the usual 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 content audit. Pull the content of live emails and check for broken personalisation tokens, missing unsubscribe links, or unusual sender patterns. Email templates themselves are not in the tool set, so this works at the email level. 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, through smart lists. Baseline figures that many teams keep in spreadsheets for reasons of habit rather than necessity. Watch the REST quota while you do it: every MCP call is a REST call, and a large snapshot can burn a surprising share of the daily allowance.

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

Four 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, schedule and trigger smart campaigns, approve emails, forms and programs, clone programs, and add people to lists, all through the underlying REST permissions. Person records themselves cannot be created or updated through the current tool set, which removes one class of accident but not the expensive ones. 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 catalogue equals the runtime. Adobe's operations page is documented intent: some listed tools are deliberately disabled, others are still being enabled, and Adobe has said it will add private API capabilities over time. Have your client list the tools it actually receives, pin the ones a workflow depends on, and re-check after each Adobe update. Building on a tool that turns out not to be there is a slower way to discover this than reading the list.

Do not assume the M365 Copilot path is shorter than it looks. Building a declarative agent, in Copilot Studio or with the Microsoft 365 Agents Toolkit, to wrap the Marketo MCP is a real project: authentication configuration, a proxy or wrapper for Marketo's three-header scheme, agent publishing, licensing for end users. If your enterprise is standardised on M365 Copilot, wait for Microsoft's direct MCP 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 or Agents Toolkit 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

Marketo audit: the European checklist nobody runs → 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 →