Model Context Protocols, or MCPs, have become the new standard for accessing data through different sources with AI tools. At this point most companies have released an MCP Server that allows AI chat interfaces like ChatGPT or Claude to interact with their software. Becoming increasingly more common are MCP Clients, which allow their product to become that chat interface to communicate with other tools.
The ubiquity of MCPs has made it extremely easy to connect different systems and integrate AI between these systems.
At this point, I’m having multiple conversations every single day with companies evaluating their tool, data and AI strategy. One common belief I’ve been hearing is that even if data is not consolidated in one central location, it’s enough to be able to access them on demand via MCPs or even APIs.
While MCPs make it easier, there are hidden costs to relying completely on them that don’t get talked about enough. The best way to build a unified context layer that is scalable and leads to consistent outcomes is a true hybrid context strategy that combines MCP data access with curated first-party data sources.
Let’s first talk about the hidden costs, and then we’ll get into what a hybrid context strategy may look like.
The hidden costs of MCPs
Latency
If every query has to round-trip to an external system, responses slow down. And it compounds. Ask a question that needs data from three different MCP servers, and now you're waiting on three separate network calls instead of one lookup. Say someone asks an AI assistant to summarize a customer's account status by pulling from Salesforce, Zendesk, and a billing system. That's three round-trips before you get a single answer. If any one of those servers is slow, or down, or rate-limiting you, the whole response stalls waiting on the slowest link.
This matters more as usage scales. A single query with a two-second delay feels fine. A hundred concurrent users all triggering the same round-trip, hitting the same external API, is a different problem entirely.
Token usage
Re-fetching the same context over and over is wasteful. Every MCP call returns raw data that has to get parsed and stuffed into the context window. If ten people ask about the same customer account today, that's ten separate fetches of the same record, ten times the tokens, ten times the cost. Multiply that across a team asking about the same handful of accounts every day, and you're paying to look up the same thing over and over instead of paying once and reusing it. Tokenmaxxing is fun and games until someone has to pay the bill.
It's not just about money. Tokens spent re-fetching known information are tokens you don't have for actual reasoning. A context window has a ceiling. Filling it with redundant lookups means less room for the parts of the conversation that actually need the space and impacts the quality of the result.
Access fragmentation
Connections like MCP usually have to be established per person, and the call itself often only works when someone explicitly invokes it or has it configured in advance. That creates inconsistency you don't see coming. One teammate has their Snowflake and Salesforce connectors set up. Another only has Salesforce. Ask both the same question, and you get two different quality answers, not because the AI reasoned differently, but because the access is uneven.
Permissions make this worse. Even when two people both have a connector set up, they often don't have the same access underneath it. Say five people on a team have Salesforce connected, but only two can see pricing and discount data. Ask all five the same question about a deal, and you get five different answers, not because the AI got confused, but because it could only see what each person was allowed to see.
This is the part that's easy to miss in early demos. Everything works when you're the one testing it with every connector live and full permissions. It breaks down the moment you scale to a team where neither is universal.
What does a hybrid context strategy look like?
So if centralizing everything is not realistic, what actually works?
Think of it less as choosing between MCPs and structured data, and more as letting each one do what it's good at. MCPs handle the parts that change constantly and need to stay fresh. A curated layer handles the parts that get asked about again and again, where speed and consistency matter more than having the absolute latest number.
Say you're building an AI agent to flag customers whose renewal is coming up but whose usage is dropping. The renewal date and contract terms live in Salesforce. Usage data lives in Snowflake. But the context that actually helps someone act on this, like past conversations with the customer, notes from the last check-in call, who owns the relationship, what was promised last quarter, that context usually lives nowhere structured at all. It's scattered across Slack threads and someone's personal notes, if it's written down anywhere.
This is where a curated layer earns its keep. Instead of pulling raw Salesforce and Snowflake data fresh every single time, you sync the pieces that matter into a structured layer built for people and AI to both use. The master data still lives in Salesforce. Nothing moves. But a shaped, organized version of what's needed sits in a layer that's fast to query and doesn't require a live round-trip every time someone asks a question.
Then MCPs step in for what they're actually good at: reaching into systems on demand for the piece that has to be current right now. Real-time product engagement numbers from your data warehouse. The latest token usage numbers. Something that would go stale if you tried to cache it.
The hybrid part is that these two things work together instead of competing. The structured layer holds the accumulated context, the relationships, the history, the parts of the work that don't change minute to minute. MCPs fill in the live, volatile pieces on top of that foundation. You get speed and consistency where it counts, and freshness where it actually matters, instead of paying the full cost of a live fetch for every single query.
The part that's easy to underestimate here is durability. Models change. The tools you use to build AI agents will look different in two years. But the structured layer you build, the relationships between customers and contracts and notes and follow-ups, that keeps compounding no matter what model sits on top of it. You're not betting on one vendor or one model staying relevant. You're building something that outlasts the tool.
How to decide what should be curated and what should be accessible through MCPs?
Not everything needs to live in the curated layer. Structured data has a cost too, someone has to build and maintain that structure, so the question is what's worth it.
A rough test: if you're asking the same question about the same thing more than once a week, it probably belongs in the curated layer. Contract terms, account ownership, relationship history. Things that don't change by the hour but get referenced constantly.
If the answer changes by the minute and being slightly stale would actually cause a problem, leave it as a live MCP call. Usage metrics from this morning. Whether a support ticket got resolved an hour ago. Pulling that fresh every time isn't wasteful, but rather it's the only way to make sure we can trust that the data is current.
The mistake I see teams make is picking one extreme. Either they try to mirror everything, which turns into its own data project with its own maintenance burden, or they route everything through MCPs, which is the latency and cost problem from earlier, just deferred.
So the move is simple: curate what's stable and gets asked about often, and leave live what's volatile and needs to stay current. And once that curated layer exists, it becomes the foundation your AI actually builds on. When agents and people pull from the same structured context, you can stack an orchestration and collaboration layer on top. Agents can hand work off to each other without re-fetching the same records every time. And people and AI finally work from the same context, instead of each piecing together their own version of it.