You wired an LLM agent into your marketing stack, gave it the CRM’s REST API, and watched it hallucinate a dealstage value that does not exist, retry a failed POST twice, and create three duplicate contacts. The API was fine for a human reading the docs at 2am. It was not fine for a model that only sees what the response payload and the OpenAPI file choose to tell it. Agent-readiness is a different bar than developer-readiness, and most MarTech platforms are still being graded on the old one.

Here is the rubric we use when deciding whether a platform’s API can actually be handed to an autonomous agent, and where the big names currently land.

Criterion 1: Documentation the model can reason from (not just read)

An OpenAPI spec tells an agent the shape of a request. It rarely tells the agent why or when to call an endpoint, or how to interpret what comes back — the exact context a model needs to reason, as the July 2025 arXiv paper “Making REST APIs Agent-Ready” spells out. Specs written for human consumption assume the reader will infer intent. Models do not infer; they pattern-match against whatever text is in the tool description.

Grade an API up when every parameter carries a real description with format, constraints, and an example value, and when responses ship example payloads. Grade it down for enums documented as “see the UI” and error bodies with no example. Speakeasy’s MCP tooling guidance is blunt about the consequence: vague parameter descriptions lead the model to misjudge formats, and missing error examples produce more hallucinations because the agent cannot recognize when it needs to ask for clarification.

Criterion 2: Granular, scoped authentication

An agent acting on your CRM should hold a token that can do exactly what its task requires and nothing else. That means OAuth scopes at the operation level — read:contacts, write:deals — not one god-token that can also delete your pipeline. The direction of travel is clear: Xero moved to granular scopes for apps created from March 2026 onward, changing how permissions get requested and granted specifically so a compromised or confused client cannot exceed its remit.

For agents this is not just security hygiene, it is blast-radius control. A misfiring model with a narrowly scoped token fails loudly on a 403; the same model with a broad token quietly does damage. HubSpot’s remote MCP server enforces OAuth 2.0 today and is moving to OAuth 2.1 with PKCE to align with the MCP specification — the mandatory-PKCE path matters because agent clients are frequently public clients that cannot safely hold a secret.

Criterion 3: Structured, predictable responses

Agents convert model output into API calls and API responses back into model context. Both directions punish ambiguity. The platforms doing this well expose typed tools rather than raw endpoints. Stripe’s Agent Toolkit is the reference example: it surfaces curated operations with clear names, LLM-friendly descriptions, and well-typed parameter schemas, instead of dumping the entire REST surface on the model and hoping.

The complementary discipline is JSON Schema enforcement on the way in. Provider-native structured outputs from Anthropic and OpenAI constrain the model to emit arguments that validate against a schema, which removes the regex-and-pray post-processing that used to sit between the model and your API. If a platform publishes strict schemas for its tool arguments and its response objects, an agent can trust the shape without defensive parsing. If it returns 200 OK with an error message buried in the body, the agent will treat the failure as a success.

Composite operations beat raw CRUD

There is a design tell that separates agent-first APIs from retrofitted ones. Instead of exposing createIssue, assignIssue, and addLabel as three tools the model has to sequence correctly, the better surface offers one manage_incident_ticket operation that orchestrates the calls behind the scenes. Semantically meaningful, higher-level tools let the agent reason about intent rather than choreography — fewer tool calls, fewer chances to get the order wrong.

Criterion 4: Native MCP support

The Model Context Protocol has become the connective tissue between agents and tools, and a platform shipping an official MCP server is signaling that it treats agents as a first-class client. HubSpot now runs two: a remote CRM server at mcp.hubspot.com for read/write access to contacts, deals, and engagements (GA April 2026), and a local Developer MCP for building apps and CMS assets via the CLI (GA February 2026, requiring Developer Platform v2025.2). Salesforce, Stripe, and a growing list of others ship their own.

The value of an official server over a community wrapper is that the vendor owns the tool definitions, keeps them in sync with the API, and standardizes auth. Any MCP-compliant agent connects without you rewriting tool schemas when you switch models or frameworks. When no official server exists, generating one from a clean OpenAPI document is a legitimate path — but it inherits every gap in that spec, so a thin, under-documented OpenAPI file produces a thin, under-documented MCP server.

Criterion 5: Machine-readable operational signals

The last criterion is the one platforms forget: an agent has to survive rate limits, retries, and duplicate side effects without a human watching.

  • Rate-limit headers. Return 429 with a Retry-After header the agent can parse, not a generic error the model interprets as “try a different endpoint.” Read endpoints can be generous; write operations should be tighter, and both should say so in headers.
  • Idempotency keys. Let the client attach a UUID (Stripe’s model) so a retried POST does not create a second contact or fire a second campaign. Agent loops retry aggressively; without idempotency, every network blip risks a duplicate write.
  • Signed, replayable webhooks. HMAC-signed payloads (the Stripe-Signature pattern) and handlers built to be idempotent, so processing the same event twice produces the same result once.

Grade the platform before you trust the agent

Before you hand any MarTech API to an autonomous agent, walk the report card:

  1. Docs — does every parameter and error carry a description and an example the model can pattern-match against?
  2. Auth — can you scope a token to just this task, on a mandatory-PKCE OAuth path?
  3. Responses — are tool arguments and response objects schema-validated, with typed tools instead of raw CRUD?
  4. MCP — is there an official server, or a clean OpenAPI spec worth generating one from?
  5. Operations — parseable 429/Retry-After, idempotency keys, and signed webhooks?

A platform that scores well on documentation and structured responses but ships no idempotency will still let an agent double-charge your workflow. The failures are rarely in the endpoints an agent calls — they hide in the signals the API never bothered to send.