In July we published a rubric for deciding whether a MarTech platform’s API can actually be handed to an autonomous agent: documentation a model can reason from, granular scoped auth, structured and predictable responses, native MCP support, and machine-readable operational signals.
Enough has shipped since to be worth re-running. Two platforms moved decisively, one moved in a direction that improves security while doing nothing for agents, and one design pattern showed up independently in two places — which usually means it is correct.
Salesforce: the biggest move, and the one worth studying
Salesforce shipped two MCP servers in the window. The Data 360 MCP Server went to Developer Preview in May: open source, stdio transport, working with Claude Code, Cursor, and Codex. The Headless 360 MCP Server entered beta in early July as a Salesforce-hosted server, activated in Setup.
Criterion 4 (native MCP): strong pass. These are vendor-owned tool definitions on a hosted surface, which is exactly the thing the original rubric said beats a community wrapper.
Criterion 1 (docs the model can reason from): the most interesting result. Headless 360 exposes a Describe tool that returns technical specifications at runtime — APIs, parameters, dependencies, and the ordered steps for an operation. That reframes the documentation criterion. We graded platforms on whether their static specs carried enough description for a model to pattern-match against. A runtime schema-retrieval tool sidesteps the question: the agent asks for the spec when it needs it, and the spec is generated from the live platform rather than from a document that drifts.
Criterion 2 (granular scoped auth): pass, with the burden moved. Headless 360 MCP transactions run as the authenticated user through an external client app carrying the mcp_api scope, with CRUD, field-level security, sharing rules, profile permissions, and permission sets all applying, and actions attributed to users in the audit trail. The separate Dispatch and Dispatch Read Only tools give a clean read/write split without maintaining two servers.
That is a good design and it relocates the risk rather than removing it. Blast radius is now whatever the integration user’s profile allows. A wide legacy profile hands an agent a wide remit, and an agent’s action set — unlike a scripted integration’s — is not enumerable in advance.
Criterion 3 (structured responses): pass. Typed facade tools rather than raw CRUD, which is what the original argued for.
The facade pattern, arrived at twice
The rubric’s “composite operations beat raw CRUD” note has a stronger form than we gave it, and both Salesforce servers demonstrate it.
Neither maps endpoints one-to-one onto tools. Data 360 exposes three tools — Search, Payload Examples, Execute — in front of roughly 200 API operations. Headless 360 exposes four — Discover, Describe, Dispatch, Dispatch Read Only — in front of the platform’s full breadth. Salesforce’s stated reason for Data 360’s design is that it “saves context window space and improves the accuracy of the AI’s actions.”
Both halves of that matter. A large tool list consumes context before any work begins, and selection accuracy degrades as the list grows. Turning the catalog into data the agent searches rather than tool definitions the agent is preloaded with fixes both at once.
This is the transferable lesson for anyone wrapping an internal API in MCP. Three tools — search, schema, execute — plus a read-only execute variant, is a better default than a generated tool per endpoint. We under-weighted this in July; it belongs at the top of criterion 3.
WordPress: infrastructure, arriving from an unexpected direction
WordPress is not usually graded on this rubric, and after 7.0 “Armstrong” it probably should be.
The Abilities API, introduced in 6.9, provides a common interface that AI agents, workflow automation tools, and plugins can use to interact with WordPress; 7.0 added a client-side counterpart for abilities like navigating or inserting blocks. Alongside it, 7.0 shipped a Connectors API for registering connections to external services — API key management, provider discovery, and a Settings → Connectors screen — plus an AI Client in core for talking to generative models.
Criterion 1: pass. An abilities registry is a machine-readable description of what the platform can do, which is the thing most MarTech APIs communicate only through prose.
Criterion 2: incomplete, and the gap is worth naming. The Connectors screen means the CMS now stores model-provider credentials. Those keys have a meter attached. Ownership, spend caps, and rotation are operational questions the API surface does not answer, and agencies running many client sites should settle them before enabling the screen.
Adobe Marketo: better security, no movement on agent-readiness
Marketo’s changes in the window run the other way.
The SOAP API’s end date has passed — Adobe’s developer documentation states it is unavailable after 31 July 2026 — and access_token query-parameter authentication is being removed, with the current release notes giving 31 August 2026 and requiring the Authorization header instead. (Some Adobe surfaces give 31 July for both; plan against the earlier date.)
Criterion 2: improves. Header-based auth is straightforwardly correct — query-string tokens leak into access logs, proxy logs, and Referer headers. But this is a fix to a long-standing defect, not a step toward granular per-operation scoping.
Criterion 5 (operational signals): mixed, and instructive. Two limits land right behind the deprecations. From 30 September 2026, API calls targeting static lists with 10,000 or more leads fail with error code 1003. Merge Leads requests cap at 25 IDs, with larger operations requiring a split.
Documented limits with a specific error code are genuinely better than silent truncation — an agent can be taught what 1003 means. What is missing is the signal: nothing tells a caller in advance that a list has crossed the threshold. The agent discovers the boundary by hitting it.
There is also a quiet one to watch. Campaign Run ID values previously returned wrapped in double quotation marks and will now return as numbers. Any consumer comparing that field as a string breaks without erroring, which is the failure class agents handle worst.
Criterion 4: no official MCP server.
Where the grades stand
| Platform | Docs | Auth | Responses | MCP | Ops signals |
|---|---|---|---|---|---|
| Salesforce (Headless 360 / Data 360) | Strong — runtime Describe | Pass — runs-as-user, read-only split | Pass — typed facades | Strong — two vendor servers | Not yet assessable (beta/preview) |
| WordPress 7.0–7.1 | Pass — Abilities registry | Incomplete — credential ownership unresolved | Partial | Adapter, not core server | Not assessed |
| Adobe Marketo | Unchanged | Improved — header auth | Unchanged | None | Mixed — coded errors, no advance signal |
Two caveats on reading this. Salesforce’s servers are beta and developer preview respectively — the Data 360 server runs locally, single user per org instance, requiring Java 17+ and Maven 3.9+ — so neither belongs under a production dependency yet, and their operational-signal behaviour under sustained load is simply unknown. And these are the platforms that shipped something verifiable in the window; a platform absent from this table has not been downgraded, it has not been re-examined.
The July conclusion holds and has sharpened. The failures are not in the endpoints an agent calls. They are in the signals the API never bothered to send — and in 2026 the platforms making real progress are the ones that made their own capabilities queryable at runtime rather than documenting them harder.
