To expose AI-ready data through MCP, scope the server’s tool and resource lists to one agent’s use case, refuse calls outside that scope, and send certification, an owner and data freshness with each answer. Atlan’s context layer does this by applying persona, role and domain policies to each MCP tool call (Atlan docs), so an agent reaches only what its identity is allowed to see.
Data is AI-ready for a named job, so the server should show one agent one slice of the estate. According to the MCP specification (2026), the protocol “cannot enforce these security principles at the protocol level,” which leaves access control and data protection to whoever builds the server. Atlan MCP is a hosted server on every Atlan tenant (Atlan docs), and every action respects the permissions already set in Atlan.
| Item | What it means for MCP exposure |
|---|---|
| Unit of readiness | One agent doing one task: the use-case slice |
| What MCP carries | Resources, tools and prompts; resource annotations audience, priority, lastModified |
| How to scope | Lists vary by the caller’s authorization; calls outside the scope are refused |
| Trust signals | Certification status and a named owner, supplied by the context layer |
| Re-check | Evals per use case, data freshness in each result, re-certification on change |
What does “AI-ready” mean when an agent reads data through MCP?
Data exposed through MCP is AI-ready only for a named use case: when the agent receives the meaning, owner, lineage and access rules along with the rows. According to Gartner’s Rita Sallam in Gartner’s AI-ready data guidance, “There is no way to make data AI-ready in general or in advance. The readiness of data for AI depends on how the data will be used.” McKinsey (2026) lands in the same place, advising teams to “define what ‘good enough’ means for each use case based on business needs and the risk profile of the data.”
Analytics-ready data had semantic models and tests, plus an analyst who knew which caveats applied to which report. An agent calling a tool gets the descriptions and the schema, and nobody to ask.
Call the unit of readiness the use-case slice: the assets, meaning, owner, freshness and rules one agent needs for one job. The tests in what makes data AI-ready and AI-ready data apply to that slice, and its meaning, owner and rules live in the enterprise context layer.
What can MCP carry, and what does it leave to you?
MCP carries context in three server features and a set of annotations; the server’s implementer builds access control, and certification and ownership come from the context layer behind it. According to the MCP specification (2026), resources are “Context and data, for the user or the AI model to use,” prompts are “Templated messages and workflows for users,” and tools are “Functions for the AI model to execute.” The server features overview (MCP, 2026) marks prompts user-controlled, resources application-controlled and tools model-controlled, and the tools specification (MCP, 2026) tells clients to treat tool annotations as untrusted unless they come from a trusted server.
The resources specification (MCP, 2026) defines audience, priority from 0.0 to 1.0, and lastModified as an ISO 8601 timestamp. The 2026-07-28 changelog (MCP) removed protocol-level sessions and requires ttlMs and cacheScope on list and resource-read results. Read ttlMs for what it is: a hint for how long a client may cache that response. It says nothing about when the table behind a tool last loaded.
| Readiness signal | Where it rides in MCP | Where it has to come from |
|---|---|---|
| Meaning and shape | Descriptions, inputSchema, outputSchema |
Glossary terms, curated descriptions, documented columns |
| Data freshness | A field in the tool result; lastModified for resources |
Pipeline and quality monitors |
| Scope | Authorization-dependent lists, call-time checks | Use case mapped to scopes and policies |
| Trust and accountability | Fields in the tool result | Certification and a named owner, set by people |
| Write safety | Host consent and a human who can deny | An approval step before any write |
The right-hand column comes from the people and systems behind the server. The MCP-connected data catalog shows that governed payload, and the MCP architecture deep dive covers hosts, clients and transports. Filling that column is context engineering work: stewards write the meaning, monitors supply freshness, owners set certification.
How do you expose AI-ready data to one agent through MCP?
Expose data through MCP in seven steps, from the agent’s job to a re-check. The wider preparation work sits in how to prepare enterprise data for AI agents.
- Name the agent and its task. For example, a finance agent that answers questions about
net_revenuebyfiscal_quarter. Check: a finance owner agrees on the list of questions it must answer. - Pick the slice. Include only the assets that job needs, and keep the tool surface small too. According to Anthropic engineers Adam Jones and Conor Kelly (Anthropic, 2025), “Most MCP clients load all tool definitions upfront directly into context,” and one example in the post dropped “from 150,000 tokens to 2,000 tokens” with a code-execution pattern. Check: every asset maps to at least one question.
- Certify the floor and make the slice filterable. A person marks each asset as verified, and the slice itself is recorded as a tag, a domain or a data product a server can filter on. A free-text note beside a certificate filters nothing. Check: no uncertified asset sits in the slice without a recorded reason.
- Attach an owner. The agent, and the person reviewing its answer, need someone to escalate to; owners and stewards for AI-ready data covers who. Check: every asset returns a named person.
- Scope access to the slice. Map the use case to authorization scopes, and make the server refuse any call outside them. The MCP security best practices recommend a “minimal initial scope set” with “only low-risk discovery/read operations,” then step-up. Check: a call to a tool or asset outside the slice fails, even by exact name.
- Gate writes. Keep the agent read-only by default. The tools specification (MCP, 2026) says a person SHOULD always have “the ability to deny tool invocations.” Check: every proposed write waits for a person, and an unattended agent has no write tools.
- Evaluate, log and re-check. Run the questions as an eval before and after exposure: score each answer against the result the owner expects, count wrong-table picks separately, and agree the pass bar before launch. Log tool usage for audit, as the same specification advises. Check: the eval passes, and the log shows which assets each answer used.
A data contract for AI can hold the slice’s schema and freshness promise, and the AI-ready data checklist covers what each asset must carry before step 3. Lock the server’s scope last: it delivers a verdict the use case already reached.
How do you scope what an agent sees through an MCP server?
Scope comes from authorization: a server can return different tool and resource lists depending on who is calling. According to the tools specification (MCP, 2026), the tool set “MAY vary by the authorization presented on the request,” for example “returning only the tools the caller’s granted scopes permit,” and the resources specification says the same about resources.
A shorter list helps the model choose. Enforcement is the server checking every call, and every asset a call touches, against the caller’s rights, so a guessed tool name or an out-of-slice asset ID gets refused. Authorization itself is optional in MCP; according to the authorization specification (MCP, 2026), a protected server acts as an OAuth 2.1 resource server, tokens must be issued for it under RFC 8707, and it “MUST NOT accept or transit any other tokens.” The guide to building MCP servers for enterprise data covers the setup.
Identity decides what the scope means. A per-user token carries everything that user may see, so narrow it with per-agent scopes; a shared service account carries its grants to every agent that uses it, so give each service identity its own narrow scope. A finance.read token might list search_finance_metrics and get_metric_definition and never see a raw SQL tool. AI agent access control and role-based access control in the context layer cover both patterns.
NIST’s NCCoE still treats dynamic agent authorization as open: its draft concept paper (2026) asks how to establish least privilege for an agent “when its required actions might not be fully predictable when deployed.” An MCP gateway can enforce scopes across servers, and how it differs from a context layer is the point: the gateway decides who may call, and the use-case slice decides what the call returns.
How should certification and ownership shape what an agent picks?
When an MCP search could return five tables that answer a question, certification should filter the results on the server before the model sees them, and a named owner should be where a doubtful answer goes. Left to rank on names and descriptions, the agent treats a stale copy of net_revenue the same as the governed one.
In Atlan, each asset carries one certificate (Verified, Draft, Deprecated or none) with a message beside it, per Atlan’s certificate docs. The certificate says an asset is fit to use, the slice marker from step 3 says for which job, and the owner is the escalation path. Trusted data for AI, data quality for AI agents and AI-ready data lineage cover how those signals are earned and traced.
Research on metadata-driven selection supports filtering, though it did not test certification labels. According to Zhang et al. (2026), a Metadata Reasoner agent kept a 93.5% average F1 score for selecting the right datasets on a synthetic benchmark built from BIRD with redundant and low-quality tables added, and avoided the low-quality data in every case; on the real-world KramaBench datasets it averaged 88.63% F1. Rich metadata still leaves room for error: according to Chen et al. (2025), an enterprise text-to-SQL chatbot built on a knowledge graph of database metadata, query logs, wikis and code had 53% of its responses rated correct or close to correct by expert review. Filtering narrows the choice; per-use-case evals tell you whether the narrowed choice answers correctly.
What goes wrong when teams expose data to agents through MCP?
Design against exposing too much, to too broad an identity. Authentication is the first gap to close: according to Zhou et al. (2026), 40.55% of 7,973 live remote MCP servers expose tools without authentication, and every one of 119 testable OAuth-enabled servers had at least one flaw, 325 in total. The study measured remote servers its authors could reach, so read it as a picture of the ecosystem rather than of your own network.
Poisoned tool descriptions are a separate risk. According to Wang et al. (2025), the MCPTox benchmark built 1,348 malicious test cases on 45 live servers and, across 20 LLM agent settings, found an attack success rate of 72.8% on o1-mini; the highest refusal rate, Claude-3.7-Sonnet’s, was under 3%. According to Hasan et al. (2025), 5.5% of 1,899 open-source MCP servers showed MCP-specific tool poisoning. A data server’s own output deserves the same caution, since descriptions, README text, certificate messages and cell values all reach the model as tool results. Prompt injection attacks on AI agents covers the defenses.
| Mistake | What happens | What to do instead |
|---|---|---|
| One server and one shared account for every agent | Every agent inherits the widest grant and sees lookalike tables | Per-agent scopes and call-time checks on the slice |
| Hidden tools treated as blocked tools | A guessed tool name or asset ID still runs | Refuse every out-of-scope call at the server |
| No data freshness in results | The agent cites last quarter’s numbers as current | Return the last load time; re-certify on breach |
| Free text in results trusted as instructions | Text in a description or cell value steers the agent | Validate tool results before they reach the model |
Every scope in scopes_supported |
Clients request broad tokens up front | Minimal initial scopes, step up later |
The last two rows come from the MCP documents: the security best practices on scopes_supported, and the tools specification, which tells clients to validate tool results before passing them to the model. The enterprise AI agent guardrails checklist and AI agent governance turn these rows into policy. Designing the server around one use case addresses the first three rows; the OAuth flaws are a separate implementation problem.
When is data ready for one agent but not another?
The same table can be ready for a read-only analytics agent and unready for an agent that writes back, because each job sets a different bar.
- Talk-to-data agent. It reads certified metrics and glossary terms and writes nothing. It is ready when real business questions pass at the owner’s bar; see the talk-to-data agent blueprint, text-to-SQL for enterprise and AI-ready data for talk-to-data.
- Coding agent over the warehouse. It reads schemas, column descriptions and lineage to write SQL. It is ready with read-only scopes and lineage down to the columns it edits, as in connecting a coding agent to the warehouse over MCP, and its changes go to code review.
- Operations agent that updates records. It is ready only when its tools cover just the operations it may propose, every write needs owner approval, and each change can be traced and reversed.
ERP data sits at the far end of that range because it carries the most tacit meaning in the estate; AI-ready ERP data for agents works through it.
What should you check before and after you expose data through MCP?
Check these before an agent connects, then keep checking. The AI readiness assessment scores the estate; these score one exposure.
| Criterion | What to look for |
|---|---|
| Call-time denial outside the slice | Direct calls to unlisted tools and out-of-slice assets fail |
| Certification as a filter | Search filters on certification status |
| Owner in results | Asset details return named owners |
| Identity per user or per agent | OAuth as the user, narrowed per agent; one-purpose service identity |
| Write preview and approval | Writes return a preview and wait for a person |
| Audit log with redaction | Each tool call logged, sensitive fields masked |
| Freshness and evals per use case | Last load time in results, a passing eval set |
The catalog-ai-readiness-check agent skill runs the catalog half as a checklist: whether the catalog behind a server has a verified agent interface, where enforcement stops, and whether a definition survives a rename.
Readiness also expires. Re-certify on a schema change, an owner leaving, or a freshness breach: when a column the finance agent reads is renamed, re-run its eval before the next release and pull the certificate if it fails. Context testing for AI agents, context evals vs data quality testing and context observability cover the re-check.
How Atlan approaches AI-ready data over MCP
In Atlan, the context layer decides what an agent receives through MCP. Atlan MCP is, per the Atlan MCP overview (Atlan docs), “a hosted server, available on every Atlan tenant with nothing to install,” and “every action respects the permissions you’ve already set in Atlan.”
- Scope. Per the Atlan MCP security reference (Atlan docs), the server forwards the authenticated identity to Atlan, where the same persona, role and domain policies that govern the UI apply. With OAuth, every call runs as the signed-in user. A service-account API token must carry exactly one persona, which becomes its scope; tokens with more than one are rejected.
- Certify and own. Per the Atlan MCP tools reference (Atlan docs),
search_assetsfilters by certification status, tags, domains, glossary terms and dates, andget_assetsreturns owners with the asset details. - Reach the rows.
query_assetsruns read-only SQL against a connected warehouse, rejects statements that modify data, returns up to 100 rows, and needs query permission on the connection. - Gate writes. Tools that change anything in Atlan “return a preview of the change and wait for your approval before writing.” Admins choose which personas may use write tools, and a read-only mode removes every write, admin and lifecycle tool while keeping search and lineage.
- Audit. Every tool call is logged as a structured event, with arguments and responses redacted before logging.
Joe DosSantos, VP, Enterprise Data and Analytics, Workday, describes the delivery side: “Atlan captures Workday’s shared language to be leveraged by AI via its MCP server.”
Teams setting this up start with how to implement an enterprise context layer for AI, wire it into their agent harness, and build on the data catalog for AI they already run, as extending a data catalog for AI readiness describes.
Why the use-case slice decides readiness over MCP
MCP gives you the hooks: lists that vary by authorization, annotations, schemas. Which table is certified, who owns it, and whether it fits the job in front of the agent come from the context layer, per agent and per task, and that verdict has to be re-earned as the data changes.
The controls you can deploy today: one slice per use case, certified and owned, refused at the server when a call strays outside it, and read-only by default. The open part is the one NIST’s draft concept paper (2026) names: least privilege for an agent “when its required actions might not be fully predictable when deployed.”
FAQs about exposing AI-ready data through MCP
1. What makes data AI-ready for an agent using MCP?
Data is AI-ready for an agent using MCP when it fits a named use case and arrives with its meaning, owner, lineage and access rules. The same table can be ready for one agent and unready for another, so readiness is judged per agent and per task rather than per warehouse.
2. What is the difference between an MCP server and an API for data access?
Both can be described by schemas. MCP standardizes how a host discovers and calls a server’s tools and resources, so any MCP client can use the same server, and the tool names and descriptions are written for a model choosing what to call rather than for a developer reading reference docs. That makes description quality part of data readiness: a vague tool description leads to the wrong call.
3. Does MCP enforce access control on enterprise data?
No. The MCP specification states that the protocol cannot enforce its security principles at the protocol level and tells implementors to build access controls and data protections. Authorization is optional in MCP; when a server uses it, the server acts as an OAuth 2.1 resource server and accepts only tokens issued for it.
4. Is MCP secure for enterprise data?
Authentication, authorization and scoping are necessary, and they are not enough on their own. A 2026 arXiv measurement study by Zhou et al. found that 40.55% of 7,973 live remote MCP servers expose tools without authentication. Beyond that, refuse out-of-scope calls at the server, treat tool descriptions and tool results as untrusted input, keep writes behind approval, and log every call.
5. Should agents see only certified data through MCP?
Make certified assets the default for any agent that answers business questions, and filter search on certification status at the server. Uncertified assets can stay visible to exploratory agents if the status travels with the result, so the agent and the reviewer can see it. Keep uncertified assets out of any workflow that writes back.
6. How do you keep data exposed through MCP fresh?
Send data freshness in the tool result itself: the source’s last successful load or refresh time, taken from your pipeline or quality monitors. MCP’s own fields cover something narrower. Resources carry a lastModified timestamp, and since the 2026-07-28 revision, list and resource-read results carry ttlMs and cacheScope, which tell clients how long they may cache the response. Re-certify when a schema changes, an owner leaves, or a freshness check fails.
7. How does Atlan apply permissions to MCP tool calls?
Atlan MCP forwards the authenticated identity to Atlan, where the same persona, role and domain policies that govern the Atlan UI apply to every tool call. With OAuth, each call runs as the signed-in user. A service-account API token must carry exactly one persona, which sets the scope for that identity; tokens with more than one persona are rejected.
Sources
- Specification, Model Context Protocol (2026-07-28)
- Overview (Server Features), Model Context Protocol (2026-07-28)
- Tools, Model Context Protocol (2026-07-28)
- Resources, Model Context Protocol (2026-07-28)
- Authorization, Model Context Protocol (2026-07-28)
- Key Changes, Model Context Protocol (2026-07-28)
- Security Best Practices, Model Context Protocol
- AI-Ready Data Essentials to Capture AI Value, Gartner
- AI data readiness: The key to scaling impact, McKinsey (2026)
- A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, arXiv (2026)
- MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers, arXiv (2025)
- Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers, arXiv (2025)
- Code execution with MCP: Building more efficient agents, Anthropic (2025)
- An Agentic Approach to Metadata Reasoning, arXiv (2026)
- Text-to-SQL for Enterprise Data Analytics, arXiv (2025)
- Accelerating the Adoption of Software and AI Agent Identity and Authorization (draft concept paper), NIST NCCoE (2026)
- Atlan MCP overview, Atlan Documentation
- Atlan MCP tools, Atlan Documentation
- Atlan MCP security, Atlan Documentation
- Add certificates, Atlan Documentation
