An AI agent is only as useful as the data it can reach safely. A model can reason and summarize, but it cannot answer a real operational or research question without access to the systems where facts actually live. MCP matters here because it gives agents a standard way to connect to data sources, tools, documents, and APIs, so a team does not start a new integration project for every source. Anthropic describes the protocol as "a USB-C port for AI applications," and that framing captures the ambition: one interface, many kinds of data behind it.
| Data type | Example | Access model | Governance need | Semantic need |
|---|---|---|---|---|
| Public research | PubMed, arXiv, Semantic Scholar | MCP server, open | Low (attribution, rate limits) | Low (structured metadata) |
| Public government | data.gov, ClinicalTrials.gov | MCP server via OpenAPI-to-MCP gateway | Medium (consent, PII) | Medium (schema variety) |
| Public web | Wikipedia | MCP server | Low | Low |
| SaaS enterprise | Stripe, Notion, Linear, GitHub | MCP server per vendor | Medium (per-user auth) | Low (defined SaaS schemas) |
| Enterprise warehouse | Snowflake, Databricks, BigQuery, Redshift | MCP server + semantic layer | High (RBAC, RLS, CLS) | High (metric definitions, joins) |
| Enterprise transactional | Postgres, MySQL, Oracle | MCP server + semantic layer | High | High |
Read the two right-hand columns. Public data is where MCP shines as a discovery protocol: the governance and semantic requirements are modest, and the value is breadth. Enterprise warehouse data is where governance and semantics are the actual product. The same protocol spans both, but the work each end needs is very different.
The two-axis map of AI-ready access
A simple two-by-two organizes the whole landscape. On one axis, the data is public or enterprise. On the other, it is reached through a direct MCP server or through MCP plus a governance and semantic layer.
- Public, direct. The open data commons: PubMed, arXiv, Semantic Scholar, OpenAlex, Wikipedia. Largely open, high value for research agents, light governance.
- Public, governed. Consent-scoped and regulated public data such as clinical trials, where access is open in principle but provenance, consent, and methodology matter.
- Enterprise, direct. The well-populated SaaS quadrant: Stripe, Notion, Linear, GitHub each ship an MCP server, often with per-user auth but little semantic modeling.
- Enterprise, governed. Warehouses and transactional systems behind a governed semantic layer. This is where enterprises spend the most and where correctness and access control are non-negotiable.
The lesson of the map is that "AI-ready" means something different in each quadrant, and a serious data platform strategy has to decide which quadrants it lives in.
Why public data needs an agent-ready layer
Public data is enormously valuable and often awkward for machines to use well. Government portals, statistical tables, PDFs, spreadsheets, geospatial layers, and public APIs all expose real information, but they were built for human analysts, not autonomous workflows. A person can open a portal, read the methodology, download a file, and chart it. An agent needs a structured way to discover what exists, understand what it means, retrieve it safely, and cite the result.
This is where the ecosystem has moved quickly. MCP servers now exist for major research corpora, PubMed, arXiv, Semantic Scholar, OpenAlex, Crossref, and ClinicalTrials.gov among them, and for public-web sources like Wikipedia. Open-source projects such as paper-search-mcp follow a free-first strategy across scholarly sources, and academic work is now cataloging national-scale efforts: a 2026 paper describes a Brazilian public-data MCP server spanning around 70 sources across economy, legislation, judiciary, elections, health, and education. The official MCP Registry and the community directory mcpservers.org are the current sources of truth for what is live, and both are worth checking before you depend on a specific server.
The OpenAPI-to-MCP pattern is the reusable template
Most public agencies and most enterprises do not need to hand-build MCP servers. They already have REST APIs, and the reusable move is to wrap them. Gateway tooling such as AWS Bedrock AgentCore Gateway auto-converts an OpenAPI specification into MCP tools, so a data.gov-style endpoint becomes an agent-callable tool without rewriting the source system. This is the same pattern examined in APIs vs MCP vs A2A: you do not throw away the REST estate, you expose it as governed MCP tools. For a public agency, it is the fastest path from "we publish an API" to "agents can use our data safely."
Why enterprise data needs the same standard, plus more
Enterprise data has the same access problem with far more governance pressure. Inside a company, data is spread across warehouses, SaaS apps, CRMs, ERPs, BI platforms, spreadsheets, documents, and data lakes, each with its own access pattern, its own definitions, and its own permission model. Agents cannot scale across that through one-off connectors. They need a standard interface that also respects identity, permissions, and business meaning. This is why MCP became more than a developer protocol; the breadth of enterprise adoption, from Salesforce and Snowflake to Stripe, Notion, Linear, and GitHub, is the subject of enterprise MCP adoption, with production results reported at firms like Bloomberg and Block. The Linux Foundation stewardship and the more than 10,000 active servers reported in Anthropic's December 2025 ecosystem update, audited in the 2026 adoption statistics, confirm the protocol is now infrastructure, not experiment.
What makes data AI-ready
AI-ready is not the same as "stored in a modern warehouse." It means an agent can find the data, understand it, and use it safely. In practice that is five layers, and the MCP specification, with its Tools, Resources, and Prompts primitives, standardizes access to them without dictating what they contain:
- Discovery: the agent knows which sources and tools exist and when to use them.
- Context: definitions, schemas, relationships, freshness, ownership, and methodology are exposed, not inferred.
- Identity: every request is tied to a user, service, role, or approved workflow.
- Governance: permissions, masking, row-level filters, and policy checks apply before results are returned.
- Semantics: metrics, entities, joins, and approved query paths are defined instead of guessed.
Add observability across all five, the record of what the agent asked, which source it used, what query ran, and what came back, and you have data an enterprise can trust an agent to touch. MCP standardizes reaching these capabilities. The last two, governance and semantics, are the ones that live behind the server.
The danger of raw access, and the pattern that beats it
The fastest way to expose data through MCP is a raw database or file tool. It demos well and it is risky in production, because an agent with raw access can query the wrong table, apply the wrong metric definition, ignore access boundaries, or return sensitive rows, and the query still runs. The failure is not MCP; it is access without context, which is guesswork, and guesswork does not belong in enterprise data workflows.
The pattern that works is to expose governed capabilities rather than raw access: get approved revenue by region and period, explain churn using the governed customer-health model, retrieve policy-compliant aggregates without exposing restricted rows. The agent asks for business intent; a governed layer validates permissions, applies the semantic definitions, compiles the right query, and returns an auditable result. That is the boundary between the two enterprise quadrants of the map, and it is why data catalogs cannot execute AI agents on their own: a catalog helps humans discover assets, but discovery is not execution.
Fix the Context, Not the Model. Whether the source is a public dataset or a governed warehouse, the reliability of an agent's answer comes from the context it is given, the definitions, the provenance, the policy, not from a larger model reasoning over raw access.
How MCP changes the enterprise data stack
In the dashboard era, users consumed curated reports. In the self-service era, they explored governed datasets. In the agent era, AI systems ask questions, retrieve context, generate queries, trigger workflows, and synthesize answers across systems. That calls for a different stack, and the pieces are complementary rather than competing. Data catalogs help humans discover assets. APIs help applications interact with systems. BI tools help people consume dashboards. MCP servers help agents reach tools, data, and workflows. Semantic layers help agents use business meaning correctly. The category error that produces brittle deployments is treating any one of these as a replacement for another, MCP as a new catalog, or a semantic layer as a new BI tool. Each answers a different question: what exists, how to call it, how to view it, how an agent reaches it, and what it means. For warehouse data specifically, that last question is where warehouse-native options such as Databricks Genie and standalone layers like Cube compete, and where the protocol's own roadmap keeps hardening the transport underneath them.
What enterprise teams should evaluate
Before making data available to agents through MCP, the questions that separate AI-ready access from simple connectivity are consistent across public and enterprise sources:
- Which sources are approved for agent access, and how does the agent learn their freshness and provenance?
- Is every request tied to the user's identity and role?
- Are row-level security and masking enforced before execution, not after?
- Are business metrics defined in a governed semantic layer rather than inferred per query?
- Can the system explain which source and logic produced a given answer?
- Do unauthorized or ambiguous questions fail safely?
- Are all tool calls, generated queries, and returned results auditable?
For public data, the emphasis falls on provenance, freshness, and citation. For enterprise data, it falls on identity, policy, and metric consistency. The protocol is the same; the weight of the requirements is what shifts as you move across the map.
Where governance and semantics come in, and where Colrows sits
The two overlays that turn access into trust are exactly the subjects of the two blogs this one hands off to. Governance is what keeps enterprise data safe once agents can reach it: identity propagation, RBAC, row and column security, and audit, the control model laid out in governance in an MCP world. Semantics are what make the answer correct: one approved definition of each metric, proven joins, and deterministic SQL, the argument made in full in why MCP is not enough without a governed semantic layer, where the dbt 2026 benchmark shows the same models moving from 84 to 90 percent on raw text-to-SQL to 98 to 100 percent when grounded in a semantic layer. Both overlays are also why the future of enterprise data access looks less like a connector and more like a governed brain, the thesis behind YC's Company Brain Request for Startups and our own analysis of it.
In the map's bottom-right quadrant, governed enterprise warehouse data, Colrows is one implementation: the semantic execution layer behind your MCP fleet. It exposes enterprise data across 16-plus warehouses through an MCP-compatible governed semantic layer, enforcing policy and compiling deterministic SQL, so agents get correct, authorized, explainable answers. It is one honest cell of a much larger landscape. Public data breadth, SaaS connectivity, and governed enterprise semantics together make up AI-ready access, and no single product owns all four quadrants.
Frequently asked questions
Is there an MCP server for PubMed, arXiv, or Semantic Scholar?
Yes. MCP servers exist for major research corpora including PubMed, arXiv, and Semantic Scholar, alongside OpenAlex, Crossref, and ClinicalTrials.gov. The official MCP Registry and community directories such as mcpservers.org are the places to confirm what is currently live.
Can AI agents query government data via MCP?
Yes, either through purpose-built public MCP servers or by wrapping existing government REST APIs. Gateway tooling such as AWS AgentCore Gateway auto-converts an OpenAPI specification into MCP tools, so an agency can expose data.gov-style endpoints to agents without rewriting the source systems.
How do I make my data AI-ready?
Expose it through an MCP server, add governance so every request carries a user identity with RBAC and audit, and for warehouse data overlay a semantic layer that defines metrics and valid joins. AI-ready means discoverable, governed, and meaningful, not just connected.
What is the difference between public and enterprise MCP access?
Public data usually needs light governance and mostly benefits from good metadata and provenance. Enterprise warehouse data needs compile-time governance, identity propagation, and a semantic layer for metric consistency, because the same question must return the same authorized answer every time.
How many MCP servers exist today?
Anthropic's December 2025 ecosystem update reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads, and the official MCP Registry API listed 9,652 latest server records as of May 2026.
Does Wikipedia have an MCP server?
Yes. Wikipedia is among the public-web sources exposed through MCP servers, alongside research and government data. Check the MCP Registry for the current implementations and their maintainers.
Can I convert my existing REST APIs into MCP servers?
Yes. Gateway tools such as AWS Bedrock AgentCore Gateway auto-generate MCP tool definitions from an OpenAPI specification. You wrap the existing API rather than rebuilding it, which is the reusable pattern for both enterprises and public agencies.
What makes enterprise data harder than public data for AI agents?
Governance, identity, meaning, and metric consistency. A public-data agent mostly needs to retrieve and cite a trusted source. An enterprise agent must enforce who may see which rows, apply the approved definition of each metric, and prove the join, all before returning an answer.
