Somewhere right this very moment, a CFO is looking at that Claude invoice and asking questions that nobody wants to answer.
Most 2026 AI budgets were set in the fall of 2025, before agentic tools totally rewrote the consumption curve.
Since then, the stories have piled up. There are enterprises exhausting annual AI budgets in a quarter, boards demanding monthly token variance reports, Deloitte publishing a CFO guide to token economics (or what they called, rather cutely, “tokenomics”) for a line item that didn't exist on finance radar two years ago.
For their part, Gartner's March 2026 analysis found that agentic workflows consume between 5 and 30 times more tokens per task than a standard chatbot interaction.
Per-token prices keep falling.
Total spend keeps climbing.
That makes the volume the bill.
So when your team proposes pointing Claude directly at Salesforce over MCP, the architecture question and the finance question have become one in the same.
Where the tokens actually go
Connect an agent to Salesforce through raw MCP and you're paying for four things before any useful work happens. Those four horsemen include:
Tool definitions ride along on every request
MCP loads the full schema of every available tool (names, descriptions, parameter definitions) into the model's context window with each message. Read: this isn't a one-time cost. It’s more like a toll on every turn. GitHub's official MCP server carries roughly 17,600 tokens of tool definitions per request. Multi-server setups routinely hit 20,000 tokens of overhead before the agent reads a single word of your actual question. Complex enterprise tools can cost 1,000 tokens each just to describe.
Discovery burns tokens by design
An agent with API access to your org doesn't actually know your org. It knows how to ask. So it asks… describing objects, listing fields, pulling automation inventories, tracing permission structures.. and every one of those exploratory calls returns metadata the model has to read, reason over, and hold in context. In a mature Salesforce org with thousands of fields and hundreds of flows, the agent is running an archaeology dig and charging by the hour to rent the backhoe.
Responses come back bloated
Salesforce APIs return complete records. The agent needed three fields; it got fifty, as raw JSON, flowing through the context window at full token cost. Response bloat routinely consumes more context than tool schemas do, and it gets less attention because it's buried in the middle of the workflow instead of sitting in a config file.
And then the session ends, and the agent forgets everything
This is the part that turns a cost into a tax. The model carries no memory between conversations. Zero. None. Just like a human returning from a long vacation to the Maldives, every new session re-runs discovery from zero. The org knowledge your agent expensively assembled on Tuesday is gone by Wednesday, and you pay to rebuild it once more. Across a team running dozens of sessions a day, you are purchasing the same understanding of your own system over and over, forever and ever.
The part Anthropic agrees with (there is a part)
This isn't a hostile read of MCP. (We love it. We have our own.)
Anthropic's own engineering team has written about the pattern: as connected tools multiply, upfront tool definitions and intermediate results passing through the context window drive up both cost and latency, and the fix is to move data processing outside the model's context entirely… letting the model receive compact, relevant results instead of raw payloads.
That's the correct architecture in the end. It's also a pat description of a context layer. The question for a Salesforce team now is whether building and maintaining a continuously synced, deterministic model of your org's metadata, dependencies, automations, and permissions, engineered to hand agents precise answers instead of raw dumps… is your engineering team's job.
What changes with a context layer in place
Sweep maintains that living model of your org outside the context window. When an agent needs to know what updates a field, which automations fire on a record change, or why a user can't edit an opportunity, it gets a traced, compact answer, the finished reasoning, at a fraction of the token cost of the raw metadata that produced it.
The economics follow directly:
- Discovery happens once, in Sweep's infrastructure, and stays current as the org changes.
- Agents stop paying the rediscovery tax at the start of every session. Responses shrink, going from JSON archaeology to grounded answers.
- The same task completes in fewer turns, because the agent isn't spending half its reasoning capacity holding your schema in working memory..
- A context window stuffed with tool definitions and raw payloads is a context window with less room to think, and degraded accuracy is its own cost when the agent guesses wrong and you pay for the retry.
None of this requires limiting what your team does with Claude. It simply changes what Claude has to burn to do it.
The build vs. buy conversation your CFO is already having
The instinct to wire Claude directly into Salesforce over MCP is reasonable. The protocol is open, the demo is fast, and the first week feels free.
The meter is what arrives later. In tool schema overhead on every message or in discovery loops across every session… or in raw payloads nobody trimmed… or in an invoice that grows with adoption because the architecture makes every user pay full price for context the org already has.
Your org's context is an asset.
Raw MCP access rents it back to you by the token. A context layer means you buy it once.
