For most agent architectures, connecting to the data source is assumed to be the harder of the two problems. Yet the real issue for agents is not connecting to the systems, but discovering what data lives within them.
Every API assumes the caller knows what they want to request. For applications with well-defined workflows, this is fine. For agents, though, there is a problem: agents must begin one step earlier. They have to figure out what data they need before they can begin to request it.
This is the problem that the Context Store was built to solve.
The discovery gap Let's imagine that the agent is tasked with answering the following question:
Which enterprise customers opened support tickets this week and are up for renewal?
Currently, the agent will have to call Salesforce to retrieve the company account information, Zendesk for the support tickets, Stripe for billing status, and possibly another vendor to access records on conversations between company reps and those customers. Each API returns a significant amount of data for the agent to parse, most of which it will never use. On top of that, the Meridian customer in Salesforce may be the same customer returned from Zendesk's API, but the agent has no way of knowing that without making additional calls to reconcile them.
The agent has a discovery problem. It can reach the systems, but it cannot see across them.
The Context Store solves this by replicating and indexing data from all connected systems into one searchable layer. The agent discovers what it needs in milliseconds, without exploratory API calls.
The benchmarks We benchmarked the Agent MCP against the native MCP servers of five vendors, using the same model and tasks.
The savings on the number of tokens used were significant for each vendor. Zendesk managed up to 90% fewer tokens, Gong managed up to 80%, Linear managed up to 75%, and Slack managed a significant 49%. Salesforce managed to save up to 16% of tokens, which makes sense as their native SOQL system is quite robust.
For queries that required the agent to pull data from a variety of systems, the Context Store managed up to 90% cost savings over the native MCP servers of the vendors.
The benchmarks performed on Granola and Linear showed that the agents consumed 10 times fewer context tokens than were returned from the API. At 5,000 tokens, the Agent MCP outperformed the third-party APIs at 65,000 tokens to perform the same tasks.
The benchmark harness is public for anyone who wants to reproduce the tests.
Why lower token consumption matters One of the well-documented challenges in large language model research is that every frontier model degrades as its context window fills up. Chroma's Context Rot study evaluated 18 frontier models and found that every single one lost accuracy as context length increased. Some dropped from 95% to 60%. Stanford's Lost in the Middle study found similar results: when relevant information was buried in the middle of a prompt, accuracy fell by 30% or more.
Agents do not have a 200,000-token brain. They have a 200,000-token window. The more context you feed into that window, the harder it becomes for the model to retain and retrieve the portions it actually needs to perform a task.
By requesting fewer tokens from APIs through the Context Store, the agent gains tens of thousands of tokens of headroom for reasoning. This directly reduces API costs for your organization, because the per-request savings compound across every task the agent runs over the course of a day. And if you're on a usage-based plan with Claude or ChatGPT, fewer tokens per task means you get more useful work out of the same allocation.
Why can't I just use the vendors' MCP servers? The benchmarks above speak to this directly. The Context Store delivers 75% to 90% fewer tokens on single-system lookups alone.
Most vendors' native MCP servers are thin wrappers around their APIs. They forward the agent's request, then return the full response payload with no field projection or search optimization. Whatever the API sends back, the agent receives in full.
The Context Store takes a different approach. It pre-indexes the data within each system and returns only the fields the agent needs, in a typed JSON format that the agent can query, filter, and sort without additional parsing.
One context, every path The Context Store is the product. The MCP , the Python SDK , and Automations are different paths to the same solution. Whether you are a developer integrating with the SDK, a RevOps manager building workflows in Claude, or an operations team member using the Airbyte UI, you are querying the same underlying layer.
A few caveats Our benchmarks used five connectors against native MCP servers and six tasks against third-party MCPs and raw APIs. This is not an exhaustive evaluation, and we know that. But the advantages of the Context Store are architectural, not circumstantial. The benchmark harness is public for anyone to reproduce.
A system that returns typed JSON with only the relevant fields will always outperform one that forwards raw API payloads. That holds regardless of which vendor or model you test against.
Agents need more than access to APIs. They need a unified, searchable layer that lets them discover context efficiently.
