Adobe didn't reveal much about the new Marketo MCP at Summit last week. Public beta lands in June. That was the headline.
We have early access. The headline isn't the one Adobe led with.
The real story is that Adobe used the MCP to expose APIs the public REST endpoints have never supported — and in doing so, quietly removed the single biggest constraint on Marketo automation that's existed since the REST API shipped. (If you haven't connected the MCP yet, our setup guide walks through the gotchas.)
TL;DR: The new Adobe Marketo MCP exposes APIs the public REST endpoints never supported — specifically smart list rule authoring and smart campaign flow step authoring. This post breaks down what's newly possible, what it means for marketing operations, and where the abstraction work still needs to happen.
The wall every Marketo automation tool has hit
Every smart campaign in Marketo has two halves.
The smart list is the audience definition. It's the set of rules that decides which leads qualify — filters like "Job Title contains Director" combined with triggers like "Fills Out Form." It answers who.
The flow is the action sequence. It's the ordered set of steps Marketo runs against each qualifying lead — send email, wait three days, change program status, sync to SFDC, branch on a choice. It answers what happens.
For the entire history of the public Marketo REST API, both halves have been read-only to programmatic access. You can fetch a smart campaign, you can see its rules, you can see its flow steps. You cannot author them. Editing audience logic and editing flow logic have always been UI-only operations.
This is the wall. Every Marketo automation product built in the last decade has hit it. It's the reason "clone a template" became the default architecture for the entire ecosystem — including ours. If you can't author flow steps from scratch, you clone a program where someone has already authored them and you operate on top of that.
It worked. It still works. But it meant the ceiling on what could be automated stopped at the template boundary. Anything that required modifying the audience or changing the cadence was a ticket back to the Marketo admin.
What new APIs does the Marketo MCP expose?
Adobe's MCP exposes both halves. Concretely:
Audience editing
The MCP can now author smart list rules end to end. The capabilities split into three groups: catalog, write, and structure.
Catalog endpoints let an agent discover what's possible before authoring. get_smart_list_rules returns the full library of available rules — every filter and trigger Marketo supports, with their operators and constraints. get_smart_list_rule_by_name does targeted single-rule lookups for cases where you already know what you want. get_smart_list_auto_suggest returns valid value suggestions in the context of a specific smart list — so an agent writing a "Job Title contains" rule can find out what job titles actually exist in the instance instead of guessing.
Write endpoints do the actual authoring. add_smart_list_rule inserts an empty rule at a specific position. update_smart_list_rule fills it with values — the operator, the target values, range bounds for numeric rules. The two pair together: structure first, content second.
Structural endpoints manage the rule set as a whole. update_smart_list_filter_logic switches between all (AND), any (OR), and custom logic like "(1 AND 2) OR 3." reorder_smart_list_rules changes the rule sequence — which matters when custom logic references rules by position. remove_smart_list_rule_constraint drops a single attribute from a multi-constraint rule without deleting the whole rule. delete_all_smart_list_rules wipes everything for clean rewrites.
Flow editing
Same shape, applied to flow steps.
Catalog endpoints. get_smart_campaign_flow_steps returns the library of available flow steps with their valid configurations. get_smart_campaign_flow_step_types returns just the IDs and names — Send Email, Wait, Change Program Status, Add to List, Sync to SFDC, Change Score, and so on. get_smart_campaign_flow_type_by_name is the targeted lookup. get_smart_campaign_rules and get_smart_campaign_rule_by_name cover the trigger and filter catalog at the campaign level. get_smart_campaign_auto_suggest provides context-aware value suggestions — when configuring a Send Email step, it can return the actual list of email assets in the instance.
Write endpoints. add_flow_step inserts a flow step at a specific position in the sequence. update_flow_step_choice configures the values inside a step — which email to send, how long to wait, what status to change to, what list to add to.
This is the pattern across all of it: catalog, lookup, write. The catalog endpoints exist because an agent has to know the schema before it can author valid configurations. The public REST API has never had the catalog endpoints, which is one structural reason it never supported authoring even in principle.
Governance gaps Adobe finally closed
A few smaller endpoints are quietly important for instance management.
get_smart_campaign_used_by returns the list of assets that reference a smart campaign. Forms and emails have had this for years. Smart campaigns didn't, which made impact analysis before deletes or edits a manual process.
get_smart_campaign_scheduled_runs exposes the future scheduled runs for batch campaigns. The public REST Schedule Campaign endpoint lets you write a schedule but doesn't expose a way to read what's currently scheduled.
facet_smart_campaigns and facet_snippets add server-side aggregation. Group by status, folder, channel, year, month — useful for instance audits ("how many active campaigns per workspace," "snippet creation by month") that previously required pulling the full catalog and aggregating client-side.
browse_email_batch_programs, browse_nurture_programs, browse_program_events, and browse_scheduled_programs are convenience filters over the public Get Programs endpoint. The filtering by program type and date range is MCP-side; the underlying data is public. But for an agent that wants to ask "show me all the nurtures that ran in Q1," the difference between one call and a paginated client-side filter matters.
What this changes
The end of the bottleneck where demand gen waits on Marketo admins for last-mile campaign config.
Today the workflow looks like this. Demand gen wants to add a new audience segment to a nurture — say, expand it to include EMEA enterprise accounts. They file a request. The Marketo admin opens the smart list, adds two rules, adjusts the filter logic, retests qualification, and ships it. Best case it takes a day. Worst case it sits in a queue for a week.
With audience and flow editing exposed, that workflow can compress to a conversation. "Add EMEA enterprise to the nurture audience" becomes a request that can be executed against the right APIs, validated, and previewed in minutes. Same for flow changes — "add a 3-day wait before the second email," "branch the nurture if they click the demo CTA," "send a different email to the under-200-employee segment."
The same applies to authoring from scratch. Today, building a new nurture program means cloning a template that someone has already configured. With flow step authoring exposed, an agent can compose a new program's audience and cadence directly from a brief, then hand it back for human approval before activation. That's the architecture behind our Campaign Builder use case — and it's the part of Mary that gets meaningfully more capable when these APIs come online.
The honest caveat
Raw API access is not a usable experience for a demand gen manager.
The configs are dense. Marketo's rule and flow step schemas have hundreds of options each, with non-obvious validation rules — operators that only work on certain attribute types, choices that require specific value formats, constraints that depend on the instance's custom fields. The auto-suggest endpoints help, but they help an agent that already knows the structure. They don't help a human staring at a JSON payload.
The real work — the work that turns these APIs into something a non-admin can actually drive — is abstraction. Translating "expand the nurture audience to EMEA enterprise" into the right sequence of catalog lookups, value suggestions, rule additions, and filter logic updates is not a small problem. It requires understanding the customer's instance, their naming conventions, their workspace governance, their existing smart list patterns, and the specific job-to-be-done behind the natural language request.
That abstraction layer is the work ahead. It's what we've been building toward — and it's why we publish free Claude skills for Marketo teams that turn raw MCP capabilities into things a demand gen manager can actually use.
Why this matters strategically
There's a second-order point worth noting.
Adobe shipped these as MCP tools. Not as REST endpoints. That's a choice. It suggests Adobe sees agentic access as the new front door to Marketo and isn't necessarily planning to backfill the public REST API to match. If that read is right, then the long-term architecture for any Marketo automation product runs through the MCP — not in parallel to it.
For the broader ecosystem, this is the moment the ceiling moved. For the last decade, every team building on top of Marketo has worked around the same set of constraints. Those constraints are coming down in June. What gets built on top of the new surface area will define the next decade of marketing operations tooling.
The wall is gone. The interesting question now is what we build on the other side of it.
Frequently asked questions
What's the difference between the Marketo REST API and the Marketo MCP?
The Marketo REST API is the documented public HTTP interface that's existed for years — it covers reading and writing leads, programs, emails, forms, lists, and most asset metadata. The Marketo MCP is a newer Adobe-hosted server that exposes Marketo capabilities to AI agents over the Model Context Protocol. Most MCP tools wrap public REST endpoints, but a handful expose capabilities the REST API has never supported — most importantly, smart list rule authoring and smart campaign flow step authoring.
Can the Marketo MCP edit smart list rules?
Yes. This is one of the biggest changes. The MCP exposes endpoints to add rules (add_smart_list_rule), fill in their values (update_smart_list_rule), reorder them (reorder_smart_list_rules), change the filter logic between all/any/custom (update_smart_list_filter_logic), remove individual constraints from a rule (remove_smart_list_rule_constraint), and wipe the rule set entirely (delete_all_smart_list_rules). The public REST API has never supported smart list rule editing — it was UI-only until the MCP shipped.
Can the Marketo MCP create new flow steps?
Yes. add_flow_step inserts a flow step at any position in a smart campaign's sequence, and update_flow_step_choice configures the values inside the step (which email to send, how long to wait, what status to change to). Combined with the catalog endpoints (get_smart_campaign_flow_step_types, get_smart_campaign_auto_suggest), this means an agent can compose a complete flow from scratch rather than relying on a pre-built template program. This is the second longstanding REST API gap the MCP closes.
