Listen on
Many enterprises face the quiet emergence of a new data integration standard that will define AI’s interaction with their systems: Anthropic’s Model Context Protocol (MCP). With over 97 million installs in 16 months and adoption by major AI providers, MCP is quickly becoming the default interface for connecting AI agents to databases, APIs, and SaaS platforms. This rapid standardization means data leaders are no longer asking if MCP matters, but how to build their data strategy around it. Failure to plan risks exploding data costs, poor performance, and significant security vulnerabilities.
James Winegar, CorrDyn’s co-founder with extensive experience in AI and agentic infrastructure, joins Ross Katz to dissect this development. They clarify why MCP reached critical mass so quickly and explore its practical implications for enterprise data architecture. The conversation covers key decision points for data leaders: when to prioritize MCP over traditional command-line interfaces, how to use data warehouses to drive cost-effective and reliable AI interactions, and the complex security implications of connecting AI agents to sensitive systems.
Ultimately, the episode frames MCP as a critical inflection point for competitive advantage. Companies that strategically integrate this protocol will redesign operations for substantial efficiency gains, while those who delay risk falling behind due to escalating costs and stalled innovation.
For a written deep-dive on the operational tradeoffs discussed here (token economics, routing decisions, and the security gaps), read MCP: What It Costs, Where It Breaks, and When to Use It.
Key Takeaways
MCP’s Standardization Requires Immediate Data Strategy Integration
The Model Context Protocol (MCP) has moved from a novel integration method to an industry standard faster than most enterprise infrastructure. With 97 million installs and adoption by major AI providers, data leaders must shift from observing its growth to actively designing data architectures that accommodate it. Ignoring this transition risks operational inefficiency, escalating compute costs, and outdated data access patterns.
Centralized Data Warehouses Drive AI Agent Efficiency and Cost Control
Direct AI agent queries against source systems like ERPs will overwhelm critical business applications and incur massive costs with limited data fidelity. By modeling structured data in a data warehouse, organizations establish a low-cost, scalable, and high-fidelity source for AI agents. This strategy enables agents to perform complex queries reliably while only accessing source systems judiciously for real-time or unstructured data.
Treat AI Agents as Enterprise Employees for Security and Governance
Integrating AI agents into enterprise systems demands a comprehensive Identity and Access Management (IAM) strategy akin to human employees. Authentication, authorization, and accountability (AAA) for agents must propagate across all tool calls and data sources, ensuring agents only access authorized information. Neglecting this security layer by using super-privileged service accounts introduces significant data exposure risks.
Early MCP Adoption Creates a Competitive Edge for Operational Redesign
Companies that strategically incorporate MCP into their data infrastructure can redesign core operational workflows, achieving 5x efficiency gains rather than incremental improvements. This agility allows mid-sized players to outpace larger, legacy-bound organizations in leveraging AI for dramatic cost reduction and enhanced capabilities. Those who delay will face increasing costs and struggle to remain competitive.
Related: CorrDyn helps clients with AI Strategy and Data Engineering to build future-ready data architectures. We also specialize in Data Cost Optimization and effective Technology Strategy for complex enterprise environments.
Full Transcript
Ross Katz: Welcome to Eventual Consistency. I’m Ross Katz from CorrDyn, and today I’m joined by James Winegar. Today we’re talking about a story that’s easy to miss if you’re not paying close attention to the infrastructure layer of AI. But if you are, it’s one of the most consequential developments in the past year. Anthropic’s Model Context Protocol (MCP) just crossed 97 million installs in 16 months. Every major AI provider is now shipping compatible tooling. The vendors building on top of AI are also shipping MCPs. What started as one company’s open standard for connecting AI agents to external data and systems has quietly become the de facto plumbing of the agentic AI world. We work at the intersection of AI systems and enterprise data architecture, so we’ve been watching this play out up close. We’re here to talk about what it means for the companies building on it, the enterprises adopting it, and the data leaders who are going to be asked to make decisions about it soon if they haven’t already. In March 2026, Digital Applied reported that Anthropic’s Model Context Protocol had crossed 97 million installs, reaching that milestone in just 16 months since its release. For context, that’s a faster adoption curve than most enterprise infrastructure standards ever achieve, including some that now underpin the entire internet. MCP is a protocol, an open standard that defines how AI agents connect to external tools, data sources, and services. Think of it as the USB standard for agentic AI. Instead of every AI system needing a custom integration with every data source, MCP creates a common interface that any compliant agent can use to talk to any compliant tool. File systems, databases, APIs, SaaS platforms—if it has an MCP server, an agent can work with it. What makes the 97 million number significant isn’t just scale; it’s who’s behind it. OpenAI, Google, Microsoft, and the major model providers are all now shipping MCP-compatible tooling. This isn’t a proprietary Anthropic play anymore; it’s an industry standard. Industry standards, once they reach critical mass, tend to become permanent infrastructure. For data leaders and enterprise architects, this changes the question from, “Should we pay attention to MCP?” to, “How do we build for a world where MCP is the default interface between AI agents and our data?” James, you’ve been working in AI and in the agentic infrastructure space for a long time. When you saw the 97 million install number and the fact that OpenAI and Google are both now shipping MCP-compatible tooling, what was your read? Is this the moment a standard becomes infrastructure, or is it still too early to call?
James Winegar: It was standardized the first week after it got built because 500 different companies built tooling around that idea, which got them into the ecosystem. The 97 million installs already told you it happened. When we passed a million, it was there.
Ross Katz: What does that mean that it’s happened? Is MCP now a standard, or is it the standard? I guess that’s the follow-up question.
James Winegar: The fundamental reason for an MCP is to integrate 9,000 different tools to 9,000 other tools using Claude, GPT-5.4, or whatever to everything else. Anthropic developed a standard to drive utilization of their platform based on the token economy. Because it worked well enough and handled some edge cases well enough, it was brought to market within a couple weeks across many major players: Microsoft, Google, Anthropic, etcetera. We’ve been seeing it do more since then. But all the original tools that existed are still there. Claude or ChatGPT, for example. They’ve been good at interacting with your terminal, doing work. The CLI-based approach is still there. The natural language approach is still there, and MCP is there. There are different needs in user journeys. When I’m coding, I’m mostly going to be using CLI tools because of the systems I’m integrating with. When I’m doing data engineering, I’m mostly going to be using the MCP to talk to our different data warehouse vendors that we work with. When I’m doing research, I’m just going to be talking in natural language to Claude. All three of those interfaces still exist. We added MCP for parts where the CLI isn’t as rich and robust as it was.
Ross Katz: First, what problem was MCP meant to solve? To dive deeper into what you were saying: If you wanted to integrate AI with all the different SaaS vendors your company uses—Slack, email, wiki, Confluence, Notion, for example—that ordinarily would have required you to create API wrappers with custom tooling that your team would have to maintain. Part of the goal here is to create a way for AI to know what the access patterns are for each system it will use, and what tools are available to use them. Previously, for more coding-focused tools, command-line interfaces (CLIs) would expose similar functionality. You would type --help, and it would tell you what tools are available. One thing that interests me to dive into is that we have CLIs for some tools. We have MCPs for other tools, and sometimes both a CLI and an MCP option are available. What is your perspective on when people should use one or the other?
James Winegar: It’s up to the vendors to decide, because it takes effort from the vendor to build a CLI or an MCP. The MCP is good for getting something to market quickly, especially where the ecosystem surface area is relatively straightforward and small. Take Slack. I could make it more complicated, but roughly speaking, I have channels and messages. I need to be able to search those: public, private, direct messages. There aren’t that many tools; perhaps 15 in the Slack MCP. Don’t quote me on that. But then you have the Databricks CLI, which probably has 1,000 tools. That’s too much for an MCP context to handle because of the way the interface works. Then you have Google’s CLI, which is a monstrosity in terms of its size. You can’t do anything with it using the MCP. You run out of context window just doing a single call. What’s the purpose of this MCP? I can imagine a world—though it’s not happening right now—where we have multiple MCPs to support different workflows within a given technology vendor. With PostHog, they have a lot of different products that are fairly independent of each other. I could imagine an event analytics PostHog MCP, and then an actual data warehouse MCP within PostHog. We’ve seen examples like MotherDuck, where their MCP is a tight loop because there are 12 tools in it. But I could also imagine a world where they make an administrative MCP for various administrative actions, like security controls, which you don’t want in the loop for your regular user. If you get to the point where you have five MCPs, should you be making a CLI that supports the full breadth of these things, because you can do the --help on top of it? It doesn’t take long to get a good MVP of an MCP out, but it takes a long time to build a good CLI, even with AI tooling to support these companies, because you end up in a place where people are interfacing with it instead of machines. I can update my MCP tomorrow; the LLM will figure out those things and make appropriate actions because all the context is there. If I change my CLI, because people have written scripts, it will cause breaking changes. I can’t be as agile with it. Startups will be more MCP-focused until they reach a level of maturity where they say, “Okay, we have five MCPs. We can’t be doing this.” At that point, they have a design definition based on that, and they can build a CLI to support the different workflows that exist.
Ross Katz: Pulling apart the pieces of what you said, the beauty of the data warehouse that already has the data integrated and modeled is that any question you ask about the integrated systems can be run at relatively low cost across all the history in your datasets, and with very high fidelity because you’ve already validated exactly how those queries should be run. You’ve also already exposed to AI exactly how to run those queries or what it needs to query to get the answer to a specific type of question. In doing that, you’ve effectively scaffolded AI. You’ve given it the context it needs to get the right answer. The other thing you touched on, which I want to dig deeper into, is that we have companies with both structured and unstructured data. They have these long-horizon questions, like the one you brought up: “Who are my customers in good standing who fit the criteria I want to rope into this marketing campaign?” But also, you might have real-time information you want to gather about those customers. This is an interesting proof point in terms of how to think about it. What we would recommend based on recent conversations is: get your structured data nicely modeled in the data warehouse so you can get an idea of who the customer universe is. Then you also give Claude, ChatGPT, or Gemini the ability to reference where to find that customer in Salesforce, Zendesk, and the ERP system. This way, for the specific universe of customers needing real-time or additional unstructured information about those entities, Claude then has either the MCP or CLI available in its context to judiciously gather that context. This is versus querying the universes of customers in your ERP and trying to do that work across a variety of disintegrated systems. That’s the picture that came to me as I was hearing you talk. What do you think about that, or what would you add?
James Winegar: Your ERP is going to fall over under that load. Your ERP is usually business-critical to your operations. If you’re manufacturing, you’re running SAP. You can’t be running wild queries against it to gather all customer information. You have to move it somewhere else. Or you’re paying $10 million a year for S/4 HANA when you should be paying one. Because of the amount of compute you’re pushing against it. A lot of this ties back to the economics of the problem. There are some questions you can’t answer with reasonable fidelity quickly using LLM tools to call out to the source systems. There’s a whole security aspect to discuss from that viewpoint. But it’s going to cost me tons of money to do that. I might get answers quicker, but I’m trading time to information for the fidelity of the answer and the cost of getting that answer. If I push the data into a data warehouse, pick your poison on how to get there. If I’m in the data warehouse and have done data modeling there based on my latency requirements, then I’m able to ask those questions in that ecosystem. I’ve decreased the cost on runtime expense by trading the engineering time it takes to get all that loaded. As a proxy of that, the fidelity of my answer should also go up. Because I’ve tested, done all these transformations, tested outputs, run audits, etcetera, to make sure that when we make changes, it doesn’t break our understanding of what revenue means.
Ross Katz: I would also add that your scalability dynamics look a lot better. As you go from 10 users to 100 users to 1,000 users, you’ve said to me recently that a cost problem is just a performance problem hiding in plain sight. When you increase the performance of those queries, you’re also making it much more scalable to get that high-fidelity answer to more people across your company.
James Winegar: From the data ecosystem viewpoint, a cost problem is usually a performance problem. If I optimize the workflow or the query, I implicitly reduce cost. SAP is a good example here. The way SAP is fast is that it basically loads everything into memory, and you’re paying big money for that system to just run with all the data in memory. That’s fast, but you’re paying for it. Any way you can reduce the complexity by doing various modeling activities. The schema in SAP is horrendous to look at. Get it downstream into your data warehouse. Get it denormalized so you’re not doing 55 joins at a time just to get a customer record. Then maybe get some orders to determine LTV. If I’ve already aggregated LTV and I do that once a day, I’m in a good spot for understanding what’s going on. I’ve reduced my cost dramatically. Where’s the trade-off? This gets back to what I said at the start of this conversation: what’s the trade-off between cost and time, and where do I need to tune the knob? There’s no correct answer for everybody. There’s not even a correct answer within a particular organization. Depending on the question I’m trying to answer, I might lean one way or the other. Always having the option to do it in the warehouse is a good thing, but also having the option, where it makes sense, to call out against the source systems is useful. The next topic is accessing those source systems—giving the MCP or CLI access to them. These source systems, like an ERP, basically hold the data motion of an entire organization. People should only be able to access what they are authorized to. I shouldn’t have access to all customer information for some of our clients in their SAP instance. When I log in, should I be able to see all those client records or not? Let’s say I have an SAP login and I don’t have access. When I use these LLM-based tools, it should authenticate as me or authorize as me. If it goes out to SAP trying to pull customer records, it says, “You don’t have access to pull these customer records.” Then I’m unable to do that analysis because I’m not supposed to access that data. Controlling that authentication and authorization pipeline within MCP is complicated because it depends on the implementation of every single MCP. It depends on the implementation of every single CLI. Google Workspace, Google Cloud, AWS, Azure—they all have their CLI tool, which also inherently provides authentication and authorization. The role-based access control and IAM should be propagated through using the tool calls with the CLI to capture the information into the context. But not every MCP has robust OAuth-based or human-based authentication. Sometimes it authenticates as a service account, which might have super-privileged access. Understanding the implications of that is a big deal. Ross and I were talking recently about a customer where we have metadata in the data warehouse and files in OneDrive and SharePoint for that customer. Using the MCP to query which files we care about, and then doing RAG against those files by calling out to OneDrive or SharePoint. How do we make sure that user can access some of those files? Because those files are privileged access. Where is the line? Do you do that on a file basis? Do you do that on individual metadata rows within the data warehouse? What makes sense? It depends. For that particular customer, we’re going to do it on file storage for OneDrive and SharePoint because there’s not a good way to know who should really get access as the data team to those individual files within the data warehouse. They’ll manage that access there. RAG will short-circuit and say, “Okay, I can’t get that file.” Then it will be able to go on from there for the users.
Ross Katz: That’s interesting. It makes me think that what we’re leading toward is a unification of the authentication layer. When I think about the process automation work we’ve done historically in a pre-AI world, we were provisioning service account credentials in each platform that workflow needed to access. For example, “this service account inside your cloud platform has access to these services.” But hearing you describe that, it makes me think that the way you’re going to issue credentials for particular agents doing particular workflows is going to look very similar, or basically be in the exact same platform that you’re issuing credentials to your employees. This is because you’re trying to manage and govern across all the systems your organization touches—what is allowed and what is disallowed for this particular entity, whether that be a human or an AI agent. Am I thinking about that correctly?
James Winegar: I think about it in terms of acronyms: AAA and IAM. AAA is authentication, authorization, accountability. Who am I, what can I do, and what did I do? IAM is identity access management. How do I provision access? If I’m sufficiently large, my IAM strategy needs to be tight to only give access to particular resources. Onboarding an AI agent employee means creating a user that’s a service account type, then giving them access to a group, which handles all the permissioning across everything else. With Google Cloud, if I’m a member of the supply chain analyst group, I get all the supply chain analyst capabilities. Tied into all that is my SIEM. That all has to be integrated throughout everything.
Ross Katz: That’s interesting. I’d love to dive deeper, but we’re running out of time. Looking at the last question: it’s 2028. MCP is as foundational to enterprise AI as REST APIs are to the web today. What does the world look like for a data team that prepared well versus one that treated this as someone else’s infrastructure problem?
James Winegar: Well, do they have a job in this scenario? If you didn’t prepare well, your costs have exploded. To the point we talked about earlier. Performance is a cost lever. If a data team hasn’t taken on the work, they’re not going to be competitive in the market because their cost to do things is going to be higher, not just from a labor standpoint, but also from the compute standpoint. Unless they have crazy margins, I don’t know if that company will be. Also, I don’t think it’s 2028. I think it’s a little further out. But the capabilities will create this AI agent employee, where the AI agent employee does most of the work. Potentially, most people doing white-collar work will be in a manager-type role, reviewing work done by 20 agents. That’s enough throughput that you’re mostly in a review phase, creating the feedback loop into the system. MCPs versus CLIs versus natural language is the way they integrate across everything. MCPs are that go-to-market, quick integration pathway. Naturally, as you evolve with enough complexity, you’re going to need to move towards a CLI-oriented workflow. Or a selective MCP, which reduces the context volume the same way CLIs do. Then eventually, “Hey, I have this MCP V2.” Maybe I don’t need to build a CLI. But as MCPs evolve, you have your framework to build a CLI accordingly, because you’re trying to figure out what boundaries need to exist and why. Then, how do I drive the IAM authentication into everything? This is where FOMO is a driving factor. Somebody’s scared they’ll get left behind because they don’t want to be like Blockbuster, a case study in business school. What happens when you don’t innovate? You don’t want to be in the innovator’s dilemma, where you’re the person spending all the capital to innovate. Instead, you’re looking for your vendors to help you get there, because for most businesses—unless you’re Fortune 500 or Anthropic—you’re in a landscape where a lot of this stuff is commoditized. You’re mostly a sales and marketing engine with operational efficiencies. You’re trying to run as lean as reasonably possible within your slice of the market. We’re expecting the vendors to help everything along the way. They’re investing in AI, they’re investing in all these things. But what’s their incentive model to do those types of things? If you look at a lot of these platforms, they have per-user pricing. They’re actually not incentivized to help you be operationally efficient. They’re not incentivized to let you become more operationally efficient. Instead, they’re incentivized for you to be bloated in a certain context. Or they need to change their pricing model, which is a constant problem because what’s our value-add versus our unit cost? It’s hard to reframe those pricing models once they exist in the market. Under the hood, they’re not going to build their own foundational model. They’re going to call Claude and ChatGPT. Their unit economics are tied to utilization rates, which probably aren’t tied to humans as tightly as they are right now. There are some market dynamics that have to evolve based on norm changes. There’s a lot of money tied up in these market dynamics that isn’t concentrated in the five, six companies—maybe 15—that are really doing AI-first orientation. Those 15 companies are the ones really taking the big piece of the pie. Everybody else is paying rent against it. We’ll see how it evolves. Every VC or PE is dreaming of a world where they flipped the operating model. There’s a person who’s a SME running it. They have 20 AI employees doing the thing. Because error rates will go down, costs of doing business will go down. At that point, your unit economics have also changed. What was my employee cost versus my token cost? How do I drive that? But that switch isn’t going to be rapid enough to change all the pricing models of the existing ecosystem in a way that drives everything towards that kind of inevitable doom-and-gloom future. All that to say, I’m not the crystal ball reader, but there’s a lot of money outside the AI race that’s incentivized on humans doing work. Whereas the opposite is true on the AI side. How do we take humans out of the loop? If we take humans out of the loop, then the unit economics are better for us, and we can raise prices. But as long as humans are in the loop, they’re capped on how much they can actually charge in efficiency gains for AI, in general, because humans are in the loop. You can only get so much more out of a person. You’re seeing somewhere between 10 and 30% on average in efficiency gains. Particular people might be 2x or 3x, but in general, across the board, we got a 15 to 30% boost. Quite a bit less than the Industrial Revolution. You have to start making the comparisons. What’s happening right now is people are betting that if you take humans out of the loop, then the multiplier goes up to 50x. Then I can squeeze margin out of that. Let’s say the cost base was 100 grand. But the current AI pricing would be 500 bucks. If I’m Anthropic, I’m charging 50, 60 grand then. Because I can, because the market will bear. But how do you get between where they are now and where they need to be? Also, getting all these organizations to adopt it while keeping society intact. It’s an interesting problem statement. To head toward the end, we’re doing this segment: What We’re Watching. James, beyond the MCP itself, is there one adjacent signal in the agentic infrastructure space that you think data leaders should have on their radar right now? We’re incentivized to help people get their data together. What I think about is: How do we help people get more value out of getting their data together more efficiently so they can determine what question they want to ask at the fidelity level they want to ask? That’s where I spend most of my time. The tooling in this space is pretty much, “Look, there are five players in that space.” They’re competing with each other, stealing ideas from each other. They’re going to do their thing. We need to stay on top of that, figure out how it applies to our customers’ workflows, and make sure our customers are competitive in the market based on these capabilities. That’s my viewpoint. I don’t work at Anthropic. I don’t make a trillion dollars if the unit economics flip over. Instead, we make our money by helping our customers be more productive, leveraging these tools more effectively. A lot of what we’ve done in the agentic AI space has been a 15-minute consultation. They answer a question they never would have been able to answer before, with 80/20 fidelity. They were on their way to solve an operational issue they had. I was working with a property management group dealing with problems. I told them to throw all their reviews into ChatGPT or Claude. Ask it to summarize and find their biggest problem. Pest control was their biggest problem after that. Now I’m going to do a study on our pest situation to figure out what we need to do. Historically, that was a $100,000 project. I spent five minutes talking to the guy, and he spent five minutes getting an Excel spreadsheet together from Airbnb and Vrbo. Then it was done. The rate of change is increasing dramatically, and high-level operators are the most effective people in this change. Where I’m leaning is that to be competitive in the market, you need to become the high-level operator or strategist that’s actually taking advantage of these capabilities. You’re not aiming for a 15% increase, but a 5x increase. Then your value proposition is much higher. If you’re sitting on that side of the Pareto curve, then you’re in a good spot.
Ross Katz: What’s been on my mind lately is the idea that many big enterprises have a lot of momentum and stickiness behind platforms that predated the current AI and agentic AI revolution. This moment represents an opportunity for companies that understand where the value comes from in their business to redesign around AI at a speed larger players couldn’t possibly hope to match. This is because larger players have all that momentum built up around the legacy way of doing things. It’s one of those moments where smaller or medium-sized players have opportunities that larger players don’t have, if they’re able to understand the value and seize the moment from an investment perspective, and put themselves in a position to take advantage of the efficiency gains that can be had.
Ross Katz: That’s it for this episode of Eventual Consistency. If you want to talk about your data challenges, or you think we got something wrong and want to tell us how, you can find us at corrdyn.com. That’s C O R R D Y N.com. We’re back in two weeks and we’ll try, as always, to be a touch more consistent. Thanks for listening.
