Enterprise teams continue to opt for the cost control and accuracy benefits of central MCP connectivity over source-native MCP servers
Source-native Model Context Protocol (MCP) servers were thought to make a connectivity layer unnecessary. If Salesforce, SAP, and ServiceNow each publish their own server, the reasoning goes, an agent can talk to each system directly, and the need for a data modeling tier disappears.
The traffic says otherwise. Across CData Connect AI, MCP tool calls grew by more than 70% from Q2 to Q3 2026, during the same quarter that native coverage expanded sharply. Every source we examined saw its Connect AI traffic rise, including the ones whose vendors shipped a production-ready server. Understanding why is the difference between agents you can trust, and those that rack up token bills with confidently wrong results.
Native MCP servers are becoming common
The coverage picture changed quickly this year. In June, 54% of MCP tool calls through Connect AI went to a source whose vendor had made a first-party server generally available. By the end of September, that has jumped to 67%. Counting every first-party server in any state, including previews and early access programs, this reaches 76%.
This trajectory promises to continue as more vendors ship new servers every quarter. For an architect evaluating whether to standardize on native connections, the decision has moved past breath of coverage and into quality, efficiency, and trust in results.
So the traffic should have moved
If availability were the binding constraint, one would expect demand for a data access layer to soften as native options appeared. It didn't soften anywhere.
The reasons become clear once the focus moves from counting servers to looking at what each one actually is. "Has a native MCP server" turns out to describe four very different situations, only one of which an enterprise can deploy without conditions (but not without limitations).
First, the 24% with no native option
Roughly a quarter of Connect AI’s MCP traffic goes to sources with no first-party server of any kind. It's tempting to read that as vendor indifference, but the engineering reality is more interesting.
An MCP server needs a stable, enumerable set of tools. The vendor has to know, in advance, what entities exist and what operations are valid, because those definitions are what the model reasons over. This assumption breaks in three specific ways:
The data model belongs to the customer, not the vendor. On platforms where customers build their own applications, tables, fields, and relationships differ in every tenant. There is no fixed tool surface to publish, because the schema is defined after the software ships. The same problem appears in enterprise resource planning (ERP) systems carrying years of per-customer extension, where two deployments of the same product share a product name and little else.
There is no vendor at all. Open-source databases have no commercial entity to publish, version, or support a server. The widely used community reference implementation for one major open-source database was archived in May 2025 and never replaced. Protocols have the same problem in sharper form: REST and OData describe a shape, not a product, so there's nothing for a first-party server to attach to.
The surface is too large to enumerate. Some enterprise suites expose thousands of objects. Publishing them as tools would flood a model's context before it read the question, so vendors in this position tend to ship an integration gateway or an agent framework instead of a general server.
Given such constraints, these challenges can only be solved by a layer that discovers schema at runtime instead of requiring the vendor to declare it in advance.
The 76% with varying degrees of native connectivity
The remaining traffic goes to sources where a first-party server exists. Grouped by what you'd actually have to do to run it in production, that cohort splits four ways:
9% is a repository, not a service
Several well-known vendors have published official MCP server code to a public repository, and nothing more. The server runs as a local process on a workstation or a container you provide. You register your own OAuth application, distribute credentials to every endpoint that runs it, and handle one tenant per process.
For a pilot, that's fine. For a deployment, it means every laptop running an agent becomes a credential holder and an operational dependency, with no central place to see what ran or to revoke access. There's no hosted endpoint, no service-level agreement, and no support path when it breaks. Several of these projects are still on 0.x releases with no stated support commitment.
15% is real software that you operate
This group is stronger. The server is supported, documented, and shipped by the vendor as a platform feature or a module within the application. The catch is that the customer deploys and runs it.
That pulls a set of familiar obligations back onto your team: hosting, patching, network exposure, identity wiring, and capacity. Version gating adds a second cost. When MCP support arrives only in the newest major release of an ERP, standing up the server means completing an upgrade first. The server is free, but the project in front of it is costly.
30% is hosted, supported, and metered below production
The largest group inside the 76% is the most surprising. These servers are genuinely well-built. The vendor hosts them, authenticates properly, and inherits the application's own permissions. They're also sold with action quotas measured in thousands of calls per account per year.
Agent workloads don't behave that way. A single analytical conversation can issue dozens of calls, and fluctuating volume becomes difficult to forecast. In the data behind this analysis, the highest-volume source in the estate ran roughly 16 times its native annual entitlement in a single quarter. Quota exhaustion isn't a billing event in that situation, it's a hard failure in the middle of a workflow.
Often, teams discover this only after a pilot succeeds and usage scales.
The 22% that seemingly had it all
That leaves the group that matters most to this decision. Around 22% of MCP traffic goes to sources with a native server that is hosted, generally available, commercially supported, and governed by the application's own permission model. By every criterion above, these customers could have connected directly.
They route through Connect AI anyway. This is the clearest evidence of what a native server is and isn't designed to do.
A native MCP server governs one application, which is the right scope for the vendor but the wrong scope for the enterprise. An agent working a real problem crosses systems, and the gap between one source and many drives three key components to break.
Governance stops being enforceable. Connecting agents to 10 systems through 10 native servers means 10 permission models, 10 consent flows, and 10 audit trails that don't reconcile. Answering who accessed what, and under which policy, becomes a reconstruction project. With Connect AI, you can define role-based access control once and apply it across every connected source, organize access by team workspace, and read a single audit trail covering every agent call. Guardrails apply to the agent, not to each connection separately, so a policy change takes effect everywhere at once.
Context stays trapped in one source. Native servers return their own application's schema and their own field names. When a user asks about customer retention across a customer relationship management (CRM) system and a billing platform, the model has to infer that two differently named identifiers describe the same entity. Models are good at that inference but they are not reliable at it, which is how quiet semantic errors enter an answer. Connect AI resolves entity relationships and business definitions before the model runs through semantic definitions, and the virtual data layer allows joins across sources in a single query. Your agent operates on resolved inputs rather than guessing at them, which is what trust in agent accuracy necessary for enterprise adoption.
Token spend accelerates as connection count grows. Every native server loads its own tool definitions into the context window. Ten servers can mean hundreds of tool definitions consuming context before the agent sees the question, which inflates token spend on every call and degrades tool selection as the list grows. With Connect AI, you can expose a small set of universal tools that work across all connected sources, route requests to an appropriately sized model, and keep context windows tight. The result is significantly lower spend per prompt and better tool selection, because the model chooses among a handful of options rather than hundreds.
What stays true as coverage closes
More vendors will publish native MCP servers, and more of those will be well-built. This trend will continue, but it doesn't change the architecture problem, because a native server is scoped to a single application by design.
Without a gateway built on a foundational data connectivity and context layer, teams connecting agents across the enterprise will keep running into the same limits:
Context windows overloaded by tool definitions before the question is asked
Tool bloat that degrades model accuracy as each new source is added
Models inferring semantic relationships that no accessible system has defined
Governance applied per connection instead of per policy
Audit trails that are shallow, inconsistent, and impossible to reconcile across sources
See what a governed AI gateway looks like
CData Connect AI connects agents to hundreds of data sources through one governed layer, with centralized access control, cross-source joins, and semantic definitions resolved before the model runs. Get started with Connect AI today, or sign up for our 14-day free trial.
