Governing the cost of an MCP agent inside a Marketo instance

When a stakeholder says they are worried about cost per task, establish which constraint they actually mean before proposing anything. Three separate budgets govern an MCP agent operating against Marketo, and they fail in different ways.

A significant share of what teams first want to hand to an agent is deterministic work wearing an agentic costume. Nightly deduplication, scheduled list pulls, standard reports, and field normalisation have no ambiguity in them — they have rules. Rules belong in a script, a webhook, or a Marketo smart campaign, where they run at effectively zero marginal cost and produce identical output every time.

Reserve the model for what actually requires judgement: interpreting an ambiguous request, reading unstructured content, deciding what a discrepancy means, or composing a recommendation. Sort every candidate task into one of these two buckets before estimating anything. This single step usually removes more cost than every optimisation that follows.

Cost is not driven by how long a task takes. It is driven by how many tokens move, and the two correlate poorly — a task that waits ninety seconds on a bulk export costs almost nothing, while a task that returns four hundred raw person records in twenty seconds costs a great deal. Two structural facts explain most of the bill.

Context compounds. An agent task is a sequence of API requests, and every request carries everything before it: system prompt, all tool schemas, every prior message, every prior tool result. Turns do not add cost linearly — they add it quadratically. Payload shape multiplies that compounding. A Marketo person object with its full custom-field set is roughly an order of magnitude larger than the same record reduced to the six fields a task needs, and that difference is carried forward by every subsequent request in the task.

Rules for the MCP server

• Return shaped payloads, never raw API responsesEvery read tool takes an explicit field list and defaults to a minimal set. Never pass a Marketo REST response through untouched. This is the highest-leverage decision in the entire build.
• Summarise server-side where the agent only needs the shape of the answer“How many people match this filter, broken down by source” should return counts, not records. Push aggregation down to the tool.
• Expose fewer, coarser toolsEvery tool definition is re-sent on every request. Twelve well-designed tools cost less and produce fewer round trips than forty granular ones that mirror the REST API.
• Cap result sets inside the tool, with explicit truncationReturn the first N with a clear note that more exist, rather than letting an unbounded query define the bill. Silent truncation is worse than none — the agent must know it saw a partial set.
• Paginate deliberately, not automaticallyAn agent that transparently follows every page will fetch fifty thousand records because nothing told it not to.
• Keep write tools narrow and explicitSeparate read from write. Narrow write scopes reduce both the blast radius and the amount of context the model needs to hold to use them safely.
• Return errors the model can act onA structured error that says which field was invalid ends the task. An opaque failure produces three more speculative turns, each carrying the full accumulated context.

Model routing

Most Marketo operations work is lookup, mutation, and confirmation. Running that on a frontier model is the equivalent of staffing data entry with a principal architect. Set the routing policy by task class and hold it.

Prompt caching

The system prompt and tool schemas are identical on every request and represent a large fixed cost per turn. Caching them converts that fixed cost to a fraction of the input rate after the first write. Structure the prompt so the stable portion sits at the front, ahead of anything that varies, or the cache will not hit.

Marketo’s API allocations are instance-wide and shared. Nothing reserves capacity for this integration, so the agent competes with the Salesforce sync, the data warehouse extract, and every other connected system.

A stakeholder worried about cost is really worried about the absence of a ceiling. Give them the ceiling and the concern resolves — often more effectively than a better estimate would.

• Per-task turn limitA hard cap on agent round trips. This is the single control that prevents a looping agent from producing a genuinely alarming invoice.
• Per-task token ceilingTerminate and report rather than continue past a defined budget. A task that hits the ceiling is a design signal, not just an expense.
• Monthly spend cap with staged alertingNotify at 60% and 85% of the agreed ceiling. Both thresholds should reach a named owner, not a shared inbox.
• Rate limiter in front of every Marketo callSized well below the instance limits, accounting for other consumers. This protects the client’s operations, not the budget.
• Approval gate on write operationsAny mutation touching production person data proposes rather than executes, until the failure rate is measured and accepted.
• Per-task logging of tokens, calls, and outcomeWithout this the model stays an estimate forever. With it, the estimate is replaced by fact within two weeks.
• A documented kill switchOne action that disables the integration, and a named person who owns it. Enterprise security review will ask; have the answer already.

No estimate should survive contact with real traffic. The purpose of a cost model is to structure the pilot, not to substitute for it.

1. Select 8–12 archetypes covering the real request mixWeighted by expected frequency, not by how interesting they are. The boring high-volume lookup matters more to the bill than the sophisticated audit.
2. Run each three times against the sandboxThree runs establish spread. One run establishes nothing — agent paths vary between executions of the same request.
3. Log input, output, and cache-read tokens per request, plus Marketo call countsPer request, not per task. Task-level totals conceal where the compounding happened.
4. Record the variance, not just the meanBudgets are broken by tail cases. Report a range and the shape of the distribution.
5. Load measured figures into the cost model and re-priceThen set the monthly ceiling from measured p90, not from the average.
6. Re-meter after any tool changeA single change to a tool’s return shape can move the bill by a multiple. Treat tool definitions as cost-bearing artefacts under change control.

The cost conversation is easier to close when the commercial structure matches the technical reality: unknown in week one, measured by week three, capped thereafter.

• A metered pilot as a discrete first phasePriced separately, with the measurement report as its deliverable. This converts the client’s open-ended anxiety into a fixed, small commitment.
• Named cost ceilings, and who is notified when they are approachedSpecify the thresholds and the owner, not just the cap.
• Whose account carries the consumptionClient-owned billing keeps costs transparent and avoids a markup conversation later. Decide this before the pilot, not after.
• Tool definitions as change-controlled artefactsState that changes to tool return shapes require re-metering. This protects both parties from a silent cost regression.
• Explicit exclusionsRetries, maintenance for Marketo API changes, and schema drift as the instance evolves. These are real and recurring; naming them upfront prevents them being read as overruns.
• The review model for write operationsWhat percentage of runs a human checks, who that person is, and when that percentage can be reduced.