A client asked us a reasonable question last month. They wanted to connect an MCP server to their Marketo instance so their operations team could hand off routine work to an agent — lookups, list maintenance, campaign QA, the reporting requests that arrive by Slack and eat an afternoon. Before approving anything, their finance partner wanted a number: what does each task cost?
It is the right question. The way most teams try to answer it produces a number that will not survive the first invoice.
Why time-based estimates fail
The instinct is to estimate by duration. If a task takes roughly ninety seconds, and we know the hourly cost of the model, we can multiply. That reasoning is familiar because it is how we price human work, and it is almost entirely wrong for agents.
Cost is driven by tokens, not by elapsed time, and the two correlate poorly. A task that spends ninety seconds waiting on a Marketo bulk export costs almost nothing — the agent is idle. A task that completes in twenty seconds but returns four hundred person records of raw JSON costs many times more. Estimate on the clock and you will be wrong in both directions, which is worse than being consistently wrong in one.
Three budgets, not one
Before pricing anything, establish which constraint the stakeholder actually means. Three separate budgets govern an MCP agent operating against Marketo, and they fail in different ways.
- Token spend. The one everyone asks about. Failure looks like an invoice larger than forecast — visible, recoverable, and rarely catastrophic.
- Marketo API quota. Most subscriptions are allocated 50,000 calls per day, with a burst limit of 100 calls per 20 seconds and a maximum of ten concurrent calls. Critically, that capacity is shared by every API service and user in the instance — the agent competes with the Salesforce sync, the data warehouse extract, and every other connected system. Failure here looks like quota exhaustion at four in the afternoon, campaigns not firing, and no obvious culprit.
- Seat capacity. If the workload runs through subscription seats rather than the API, the constraint becomes per-seat limits enforced on rolling windows. Failure is silent and intermittent: the workload simply stops mid-run.
This matters because a workload can be entirely affordable and still be unshippable. We have seen instances already consuming seventy percent of their daily API quota before anyone proposed adding an agent. In that environment, token cost is the smaller problem, and the conversation is about capacity planning, not pricing.
Where the cost actually comes from
Two structural facts explain most of an agent’s bill, and neither is under the user’s control at runtime. Both are decided when the integration is designed.
Context compounds
An agent task is not one API request. It is a sequence of them, and every request carries everything that came before it: the system prompt, every tool schema exposed by the MCP server, every prior assistant message, and every prior tool result. Turns do not add cost linearly — they add it quadratically. A six-turn task does not cost six times a one-turn task. It costs closer to fifteen times.
This is why the number of tools an MCP server exposes is a cost decision. Forty granular tools that mirror the REST API are re-sent on every single request, and they invite more round trips than twelve well-designed ones.
Payload shape multiplies it
A Marketo person object carrying its full custom-field set is roughly an order of magnitude larger than the same record reduced to the six fields a task actually needs. That difference is then carried forward by every subsequent request in the task, so it compounds against the quadratic above.
In our own modelling, a single archetype — exporting and summarising a 500-record smart list — costs about seven times more with unshaped payloads than with an explicit field list. Nothing about what the agent was asked to do changed. Only the shape of what came back.
Model tier
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. Routing high-volume, low-ambiguity tasks to a smaller model and reserving the frontier tier for genuine judgement work — QA, audits, impact analysis — typically removes more than half of what remains.
The task that should never reach the agent
Before any of this, there is a cheaper move available, and it is the one most often skipped.
A significant share of what teams first want to hand to an agent is deterministic work wearing an agentic costume. Nightly deduplication, scheduled exports, standard reports, field normalisation — these have no ambiguity in them. They have rules. Rules belong in a script, a webhook, or a native Marketo smart campaign, where they run at effectively zero marginal cost and produce identical output every time.
Reserve the model for what genuinely requires judgement: interpreting an ambiguous request, diagnosing why a program is misbehaving, reading unstructured content, or drafting a recommendation a human will review. Sorting every candidate task into one of those two buckets, before estimating anything, usually removes more cost than every optimisation that follows.
Meter, then model
Every figure above is a starting assumption, and assumptions presented to a budget owner without their caveats are a liability. The purpose of a cost model is to structure a pilot, not to substitute for one.
A two-week metering protocol replaces the guesswork:
- Select eight to twelve task archetypes that cover the real request mix, weighted by expected frequency — the boring high-volume lookup matters more to the bill than the sophisticated audit.
- Run each three times against a sandbox instance. Three runs establish spread; one establishes nothing, because agent paths vary between executions of the same request.
- Log input, output, and cache-read tokens per request, plus Marketo call counts. Task-level totals conceal where the compounding happened.
- Record the variance, not just the mean. Budgets are broken by tail cases.
- Set the monthly ceiling from the measured ninetieth percentile, not the average.
Then give the stakeholder the thing they are actually asking for. A stakeholder worried about cost is usually worried about the absence of a ceiling. A hard per-task turn limit, a per-task token cap, a monthly spend ceiling with alerting at sixty and eighty-five percent, and a documented kill switch will resolve the concern more effectively than a more precise estimate ever would.
The reframe that ends the conversation
Cost per task is the wrong denominator on its own. The right comparison is agent cost against the fully loaded cost of the operator doing the same work by hand — with build effort and human review time both charged honestly against the agent, not quietly excluded to make the case look better.
When a task that consumes twenty minutes of a senior operations resource is executed by a governed agent for a fraction of a dollar, and the build pays back inside a quarter, the question stops being whether to proceed. It becomes which tasks to onboard first, and what has to be true before a write operation runs without a human checking it.
That is a materially better conversation than arguing about credits.
Two things you can use
We built the model we use for this engagement into an interactive tool, along with the framework behind it.
- The MCP cost model — prices a real task mix across all three budgets, and shows how much of the bill each governance lever removes. Replace the default archetypes with your own tasks and measured turn counts.
- The governance framework — the tool-design rules, routing policy, Marketo-specific constraints, controls, metering protocol, and the commercial terms that follow from them.
If you are evaluating an MCP integration against Marketo, HubSpot, or Salesforce Marketing Cloud and want the estimate grounded in measurement rather than assumption, we run this as a discrete, fixed-scope pilot before anything touches production.
Leave a Reply