What MCPs mean for Data & Analytics Providers
Asymmetrix analyzes the opportunities and challenges of MCP development for data businesses
In this week’s newsletter, we analyze the value MCPs offer Data & Analytics providers - and their clients - and the structural risks they introduce. We also present our first-ever survey on MCP Adoption in Data & Analytics.
Asymmetrix is the source of truth for stakeholders in the Data & Analytics industry. Bankers, investors, equity research analysts and consultants rely on our data to stay informed on trends and transactions in the sector and to analyze Data & Analytics deals.
Feel free to reach out directly to h.crean@asymmetrixintelligence.com to learn more about a subscription or book a meeting via Calendly.
MCP Adoption Survey for Data & Analytics Executives
As MCPs gain traction across the industry, Asymmetrix wants to understand how Data & Analytics teams are really using it. Our very short survey explores adoption patterns and the challenges practitioners are facing on the ground. All respondents will receive a copy of the full report analyzing the results of the survey, giving you an early look at how your peers are approaching MCP and where the industry is headed.
The survey takes less than 3 minutes. All responses are anonymous.
Last Week on Asymmetrix
Each week, Asymmetrix publishes several research reports covering companies, sectors and deals in the Data & Analytics industry - available for subscribers only.
Below are just some of the reports published in the past week:
Company Analysis - VC-backed US-based transaction data provider;
Sector Analysis - Price Reporting Agencies and Pricing Data Providers: White Spaces and Emerging Benchmarks;
Company Analysis - Private US-based Aviation compliance Data & Analytics business;
Deal Perspective - Observed, Not Estimated: Ampere Analysis Acquires PlumResearch.
What is MCP and why does it matter now?
The Model Context Protocol (MCP) is an open standard that provides a universal interface for AI models to discover, authenticate with, and query external tools and data sources. Conceived by Anthropic engineers David Soria Parra and Justin Spahr-Summers and released in November 2024, MCP was designed to solve a practical integration problem: before it existed, every AI application needed bespoke connectors for every data source, creating what Anthropic described as an “N×M” integration challenge. MCP collapses that into an “N+M” problem – build one server, connect to any compliant client. The analogy most commonly used is USB-C for AI: a single connector that works across platforms.
The protocol gained legitimacy rapidly. In March 2025, OpenAI formally adopted MCP across its products, including the ChatGPT desktop app. Google DeepMind, Microsoft and AWS followed. In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI. Alongside Anthropic’s donation of MCP, Block contributed its AI agent framework goose and OpenAI contributed its instruction format standard AGENTS.md. MCP is now governed as a vendor neutral open standard under the Linux Foundation. By early 2026, Forrester predicted that 30% of enterprise app vendors would launch their own MCP servers during the year, and Gartner projected that 40% of enterprise applications would include task-specific AI agents by year-end.
For Data & Analytics executives, the implication is structural. MCP is not an API upgrade. APIs are deterministic: a known application sends a defined request and receives a structured response. MCP serves “probabilistic consumers” – AI agents that dynamically discover available tools, decide which to call based on a user’s natural-language query, and chain multiple data sources together in ways the provider may never anticipated. The data no longer arrives in a context its provider controls. It arrives in a context the AI model constructs.
How are Data & Analytics businesses using MCP?
The adoption pattern across D&A providers is remarkably consistent: expose existing API-accessible datasets through an MCP server, authenticate via OAuth 2.1, and let AI agents pull data on demand. The technical lift is modest – MCP sits on top of existing APIs rather than replacing them – but the strategic implications are significant. The table below selectively maps the current state of MCP adoption among some notable Data & Analytics providers.
First, we can see that early movers are some financial data providers: FactSet, Daloopa, Aiera, and Morningstar recognised before most that their institutional clients were building AI-augmented research workflows and needed structured data piped directly into those systems. Second, the MCP servers being built are overwhelmingly model-agnostic – a single server works with Claude, ChatGPT, Gemini, or any compliant client. This is not proprietary lock-in; it is an open distribution channel. Third, the holdouts – most notably Bloomberg and LSEG – share a common trait: deeply entrenched, terminal-centric delivery architectures where the workflow itself is the product, not just the underlying data. Unlike API‑first or emerging agent‑integrated models, their platforms are designed as closed environments that tightly couple data, analytics, and user workflows, creating high switching costs and strong client lock‑in.
What is the value proposition for clients?
The client case is straightforward: MCP eliminates the manual assembly of data from disparate sources into AI workflows. A portfolio manager who previously needed to open FactSet, pull consensus estimates, switch to an earnings transcript platform, cross-reference with SEC filings, and then synthesise a pre-earnings brief can now prompt a single AI agent that chains together FactSet fundamentals, Aiera transcripts, Daloopa source-linked financials, and third-party news – all in one session. Daloopa’s benchmark quantified the stakes: agents pulling from structured MCP-connected databases achieved close to 90% accuracy regardless of which frontier model they used (Claude Opus 4.5, GPT-5.2, or Gemini 3 Pro), while the same models using only web search ranged from 20% to 71%. The data layer, not the model, was the binding constraint.
For clients, an additional benefit is economic: the client pays for the AI tokens, not the data provider. For example, when a financial analyst queries Daloopa’s MCP through Claude, the LLM inference cost sits on the client’s Anthropic bill. Data provider earns its subscription revenue from the underlying data access, while the compute cost of generating the response – which would otherwise require the data provider to build and operate its own AI agent infrastructure – is borne by the AI platform. This is a structurally efficient arrangement: the data provider monetises its content without absorbing the inference economics, and the client gets a unified AI workspace rather than a fragmented stack of point solutions.
The hard questions: seven issues D&A executives must confront
MCP’s surface-level appeal – wider distribution, lower integration friction, meet-the-client-where-they-are – obscures a set of thornier strategic and operational questions that will determine whether this protocol creates or destroys value for data businesses.
Quality control: mixing curated research with AI-generated output
The most immediate risk for premium data providers is the loss of control over how their content is presented. When an analyst reads a Morningstar research note directly, the provider controls the context: the formatting, the caveats, the methodology disclosures and the branding. When an AI agent retrieves Morningstar data via MCP and weaves it into a synthesised output alongside web-scraped information and other data feeds, the provenance of each claim becomes opaque. The agent may accurately retrieve a fair-value estimate but strip the surrounding qualifications. It may combine a provider’s data with a lower-quality source in ways that produce misleading outputs. The data provider’s brand is implicitly attached to the AI’s answer, even though the provider had no role in constructing it.
Daloopa has addressed this partially through source-linking: every data point returned via its MCP includes a hyperlink to the original filing. Aiera emphasises traceability and attribution. But these are provider-side mitigants. The broader question – whether AI-generated outputs that blend multiple MCP sources preserve or erode the quality signal that premium data commands – remains unresolved. For providers whose brand is synonymous with analytical rigour, this is not a theoretical concern.
Pricing: what exactly do you charge for?
Most Data & Analytics providers with live MCP servers have adopted the simplest approach: MCP access is bundled with the existing data subscription. If you pay for FactSet, you get MCP access to FactSet data. The MCP layer itself is not a separate line item. This makes adoption frictionless but leaves revenue on the table if MCP-connected agents drive significantly higher query volumes or enable new use cases that the original subscription was not priced to cover.
The alternative models are also emerging:
usage-based pricing (charge per MCP tool call or per data point retrieved),
tiered access (MCP-basic included with subscription, MCP-premium for higher throughput or additional datasets), or
workflow-based pricing (charge for the output the agent produces – a completed research brief, a compliance report – rather than the raw data calls).
Each carries trade-offs. Usage-based pricing aligns cost with consumption but creates unpredictable client bills. Workflow-based pricing captures more value but requires the provider to define and measure “workflow units” that may not map neatly onto existing metering infrastructure. For now, the market is mostly settling on bundled access, but as agent-driven consumption scales, pricing will evolve.
Visibility: what does the data provider see?
In a traditional API model, the data provider sees the exact query: which endpoint was called, with what parameters, by which user. In an MCP model, the provider sees the tool call that the AI agent constructed, which reflects the model’s interpretation of the user’s natural-language prompt – not the prompt itself. A user might ask: “Compare Apple’s margin trajectory against its three closest competitors over the last five years.” The MCP server receives a series of structured data requests, but the provider does not see the original question, the broader conversation context, or how the retrieved data was ultimately used in the agent’s output.
This visibility gap has implications for product development (providers cannot observe which workflows their data supports most), for compliance (data usage auditing becomes harder), and for pricing (consumption patterns are partially obscured). Some providers are instrumenting their MCP servers to log tool-call metadata for analytics, but the fundamental asymmetry – the AI model sees everything; the data provider sees only its slice – is intrinsic to the architecture.
Connector fatigue: will clients really plug in fifty MCPs?
The MCP ecosystem already lists over 10,000 public servers. For enterprise clients, the theoretical promise of connecting any data source to any AI agent is compelling; the practical reality of managing authentication, permissions, version updates, and quality assurance across dozens of MCP connections is considerably less so. At scale, managing integrations across dozens of external tools becomes operationally complex. Beyond roughly 10–50 integrations, enterprises typically require a centralized orchestration layer to handle authentication, rate limiting, permissions and governance. In an MCP-based architecture, this takes the form of a gateway layer that abstracts multiple MCP endpoints into a unified interface, enabling consistent agent interaction, monitoring, and control across providers.
For data providers, this raises a distribution question: will clients connect directly to your MCP server, or will they access it through a middleware platform (CData, Truto, Composio) that abstracts multiple MCPs behind a single interface? If the latter, the middleware becomes the customer-facing relationship, and the data provider risks becoming a background input – visible to the agent, invisible to the end user.
Incumbent advantage: does more data win when the AI chooses?
In a world where AI agents dynamically select which MCP tools to call, the question of how agents make that selection becomes competitively critical. If a client has connected both S&P Capital IQ and a smaller specialist data provider – say, Modo Energy for battery storage analytics – which does the agent call for a given question? The answer depends on how well the MCP server describes its own capabilities (its tool descriptions and metadata), how the AI model’s routing logic weighs relevance against breadth, and potentially on which servers the client has configured as defaults.
As described in academic research of MCP-Augmented Large Language Models:
In the MCP framework, tool descriptions function as the “semantic interface” between the LLM and data. No matter how accurate or high-quality your underlying database is, an LLM cannot access it if it does not select the right tool or parameterizes the query incorrectly;
A data repository might contain perfect records, but if the description for a tool like “query_customer_db” does not specify that it expects an ISO-formatted date or an exact string ID, the LLM will guess. This introduces friction between the model’s internal reasoning and the clean data layer, which can paradoxically cause automated MCP access to reduce overall agent accuracy if the prompt instructions inside the schema are poorly engineered.
This introduces a new form of competitive dynamics that is closer to SEO (Search Engine Optimization) than to traditional data sales. The quality of your MCP server’s tool descriptions – how precisely they communicate what data is available and what questions they can answer – may matter as much as the quality of the data itself. A smaller provider with better-described, narrowly scoped tools may be selected over a larger provider whose MCP server is poorly documented. Conversely, incumbents with massive, well-structured datasets that cover broad query spaces may benefit from a “surface area” advantage: the more questions a single MCP can answer, the more often the agent will route to it.
The competitive calculus is not yet clear, and it will depend heavily on how AI model providers develop their tool-selection algorithms.
Marketing in the age of MCP: do you still need a website?
If the primary consumption interface for data shifts from a provider’s own platform (terminal, portal, dashboard) to an AI assistant, the traditional marketing funnel – website traffic, product demos, free trials – becomes partially disconnected from the actual usage surface. A prospect may never visit your website; they may discover your data because an AI agent recommends connecting your MCP server, or because their firm’s IT team has pre-configured it. The brand-building and differentiation that providers invest in through their own interfaces – the design of their dashboards, the presentation of their research, the user experience – may be stripped away when data is consumed through an intermediary.
This does not mean websites become irrelevant, but their function shifts from being the primary delivery surface to being a marketing and credentialing layer. Some providers may choose to maintain standalone AI agent interfaces – their own chatbot or research assistant built on their data – purely for demonstration and marketing purposes, even if most actual consumption happens through third-party MCP integrations. The parallel from earlier technology cycles is instructive: even after APIs became the primary delivery mechanism for many SaaS products, the website remained essential for acquisition and trust-building. MCP may follow the same pattern.
Token economics: the structural cost advantage of MCP
One of MCP’s underappreciated structural features is its impact on inference cost allocation. When Forrester or any data provider builds its own AI-powered research assistant, it bears the cost of LLM inference: every query a user runs generates a token bill that the provider must absorb or pass through. This creates a tension between usage growth and margin preservation that has constrained many data providers’ AI ambitions.
MCP inverts this equation. When a client queries a provider’s data through Claude or ChatGPT, the client’s AI platform subscription covers the inference cost. The data provider incurs only the marginal cost of serving the MCP request – effectively, an API call. This is a meaningful structural advantage: it allows data providers to participate in AI-powered workflows without building and financing their own AI infrastructure. The trade-off is control: the provider gives up ownership of the user experience in exchange for lower cost and broader distribution. But for many D&A businesses, particularly mid-market providers without the resources to build competitive AI agents, this trade-off is rational.
Evolution or revolution? MCP in context
It is tempting to frame agentic protocols such as MCP as a paradigm shift in how data businesses operate. The more precise characterisation is that MCP is the latest – and potentially most consequential – layer in a delivery-mechanism evolution that has been underway for two decades. Bulk data feeds gave way to APIs, which gave way to embedded analytics, which are now giving way to AI-native consumption via MCP. Each transition expanded the addressable surface for data consumption while increasingly reducing the provider’s control over presentation and context.
The API comparison is particularly instructive. In the early 2010s, data providers faced a similar question: should we give programmatic access to our data, knowing that it enables uses we cannot control? The answer, for most, was yes – because the distribution and revenue benefits outweighed the risks. APIs became the dominant delivery channel for data businesses, powering fintech applications, quant strategies, and enterprise integrations that would have been impossible through terminal-only delivery. MCP is the same question, posed by a more powerful consumer. The difference is that API consumers were deterministic applications built by engineers who understood the data schema. MCP consumers are probabilistic reasoning engines that interpret data contextually and may use it in ways the provider may never anticipated. This raises the quality, attribution, and disintermediation risks discussed above to a degree that APIs never did.
The verdict is that MCP is not a replacement for existing delivery channels – it is an additional one, and refusing to participate carries a clear opportunity cost. The providers that moved first (FactSet, Aiera, Daloopa) are already capturing mindshare among AI-augmented research teams. The providers that are holding back (Bloomberg, LSEG) may be right to proceed cautiously – their terminal-centric value propositions are defensible for now – but the window for “cautious observation” is narrowing as agent-native workflows become the default at an increasing number of institutional clients.
Should I build an MCP? A framework for Data & Analytics executives
The protocol is open, the build cost is modest, and the downside of inaction – being invisible to the fastest-growing consumption channel for data – is increasingly difficult to justify. So, the answer for most Data & Analytics providers may be yes, but with deliberation that requires answers to three further questions:
First, which datasets should be exposed? Not all content is equally suited to agent- or other AI‑based interfaces. Structured, query friendly data (fundamentals, pricing, events, filings) translates directly into API and tool-call workflows due to its deterministic schema and low ambiguity. In contrast, narrative research and nuanced analysis depend heavily on context, framing, and presentation, making them difficult to compress into structured outputs without losing signal. As a result, data providers should prioritize exposing structured datasets first, while delivering narrative content via retrieval and summarization layers as agent tooling matures;
Second, how will you maintain quality attribution? Source-linking (as Daloopa and Aiera do) should be considered a minimum requirement. Without it, your data may become undifferentiated input to an AI output – valuable to the end user, invisible as a branded contribution;
Third, how will pricing evolve? As an option, data providers may bundle MCP access with existing subscriptions to drive adoption but instrument its MCP server to capture granular consumption analytics from day one. The data collected on agent-driven usage patterns will be essential for designing consumption-based pricing models when the market is ready for them.
The providers that treat MCP as a strategic distribution investment within holistic data delivery strategy – rather than a technical checkbox – will be the ones that capture the most value from the agentic era. MCP protocol is free. The data is not.
📜 Interesting Content
AI for Value Creation: Deploying AI to drive growth and protecting your business from the threat it poses - Collingwood
Credit scores are flawed. FICO has a new model that adds cashflow data. It might just offer the boost you need - Fast Company
MCP has been a key component of LSEG’s AI strategy since last year. It is not accurate to describe LSEG as an MCP holdout