Express — 
Data Platform for AI Agents: 7 Capabilities to Demand
A data platform for AI agents must do 7 things: connect, abstract, govern, deliver, act, observe, secure. Use this checklist to evaluate any vendor or stack.
The short answer. The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024 and donated to the Linux Foundation’s Agentic AI Foundation in 2025, that lets AI agents discover and call tools and data sources at runtime. For enterprise data teams, MCP servers are the new contract layer between agents and governed data, a discovery-first alternative to writing one-off API integrations per agent.
What MCP is, and why data teams should care
MCP began as Anthropic’s open spec for connecting AI assistants to tools without bespoke glue. It now has co-stewardship from OpenAI, Block, Google, Microsoft, AWS, and Cloudflare. Anthropic reports more than 10,000 public MCP servers and 97 million monthly SDK downloads.
By Q1 2026, 78% of enterprise AI teams with fifty or more practitioners had at least one MCP-backed agent in production, up from 31% a year earlier. Enterprise adoption among organizations of 250+ employees sits near 89%.
For data teams, the protocol matters because it inverts who knows the schema. APIs assume the client knows what to call. MCP assumes the agent will ask, at runtime, what tools exist, and the server will tell it.
MCP server vs API: the load-bearing differences
| Dimension | API | MCP server |
|---|---|---|
| Designed for | Code written by humans | Agents choosing tools at runtime |
| Discovery | Static docs (Swagger) | tools/list returned dynamically |
| State | Stateless requests | Session-based, capability-scoped |
| Failure mode | 4xx / 5xx | Tool refusal with structured context |
| Scaling pattern | Decades of HTTP at scale | Tool overload, prompt budget pressure |
| Best for | Programmatic integrations | Agentic, multi-tool workflows |
MCP tool budget visualizer, how many tools can your agent’s context actually hold?
Drag the sliders to see how much of the agent’s context window is burned on tool descriptions before reasoning starts.
0 tk16,000 tk32,000 tk
Tools list 9,600 tkSystem 800 tkHistory 6,400 tkFree for reasoning 15,200 tk
Healthy. Plenty of context left for the actual query and history.
MCP tools exposed64
1500
Avg tokens per tool description150
50500
Model context window32k
Tool descriptions, system prompt (~800 tk), and conversation history (~6,400 tk) all compete with the actual reasoning for context. As MCP catalogs grow, scoping and intent-filtered tool discovery become non-negotiable.
The compact rule of thumb: APIs are the right answer when you write the program. MCP is the right answer when the AI is the program.
How enterprises are deploying MCP in 2026
Four patterns dominate.
- Managed MCP gateways. Composio and others aggregate hundreds of SaaS tool actions behind one MCP endpoint. Good for SaaS sprawl. Less good for governed enterprise data.
- Hosted remote MCP servers. SaaS vendors expose their own catalogs (Salesforce, Snowflake, Databricks, AWS Bedrock) as MCP-callable surfaces. Tight coupling to that vendor’s stack.
- Custom internal MCP servers. Sixty-four percent of large enterprises now run at least one. Flexibility is the appeal; on-call rotations and security review are the cost.
- Data-platform MCP servers. A managed MCP layer sitting on a governed data fabric, vendor-neutral, source-agnostic, with built-in governance. This is the category Nexla occupies.
Which MCP deployment pattern fits you?
Adjust your situation. The match score updates per pattern, top score is recommended.
# of data sources to expose15
1100
Governance level required
Agent write paths needed?
Deployment context
Recommended pattern
–
–
Pros
Cons
Scoring is illustrative; real deployments often combine patterns (e.g., a data-platform server for governed enterprise data plus a managed gateway for SaaS sprawl).
What an enterprise-grade MCP server actually needs
Most MCP servers in the wild are toy projects. Enterprise teams should expect, at minimum:
- Authentication and tool-level RBAC. Different agents see different tools. A support agent should not see a tool that drops a production table.
- Dynamic discovery without overload. Hundreds of tools blow out the agent’s prompt budget. Servers need scoping, namespacing, and intent-filtered listings.
- Lineage and observability. Every tool call traceable to a data product, a user, and a prompt run.
- Quotas and rate limits. Agents loop. Servers need to throttle.
- Write paths, not just reads. The most valuable MCP servers let agents author new pipelines, not just call existing ones.
The “MCP server vs data platform” question
Most MCP servers expose pre-built APIs as tools. Few let agents compose new data flows.
Nexla creates dynamic MCP access across 550+ enterprise sources, including systems that lack native MCP support such as SAP, Coupa, Workday, and IBM DB2. The same server presents governed Nexsets (Nexla’s data products with semantic abstraction), applies built-in access controls and audit logging, and unifies disparate systems behind a single MCP endpoint. Built-in governance, zero-trust security, and identity travel with every call, so agents get a single tool surface without compromising on enterprise controls.
Build, buy, or both
A reasonable starting point in 2026: buy your enterprise data MCP layer, build the agent-side orchestration. The MCP server is plumbing, it needs governance, uptime, audit, and a connector library that’s expensive to rebuild. Your agent reasoning is your differentiation.
FAQ
What is MCP in one sentence?
An open protocol that lets AI agents discover and call tools and data sources at runtime, without hand-coded API clients.
Is MCP a replacement for our APIs?
No. MCP usually wraps APIs. The protocol gives agents a discovery and call interface; the API underneath still does the work.
Who governs MCP now?
The Linux Foundation’s Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI in late 2025.
Do I need an MCP server if I already have a data fabric?
Yes. The data fabric organizes data; the MCP server makes it agent-callable. They compose; they do not substitute.
Next step
Pick one agent use case that today depends on hand-coded API glue. Re-implement that integration behind an MCP server. The exercise will surface every gap in your current data governance, cheaper now than at scale.
