Engineers building AI agents typically reach for vector databases when they need memory. For agents operating over enterprise data, this is the wrong starting point. Your data catalog already holds six types of memory — business glossary, data lineage, ownership records, certification status, schema documentation, and query history. Activating these as agent memory via MCP takes hours, not weeks. This guide covers three integration paths and documents the accuracy improvements that result: teams see up to a 38% improvement in AI-generated query accuracy once catalog metadata is in the loop.
Quick overview
| Time to complete | 2–4 hours (catalog already populated) or 1–2 days (catalog sparse) |
| Difficulty | Intermediate |
| Prerequisites | Active data catalog, agent framework, API key |
| Tools needed | Docker or uv, catalog admin panel, MCP-compatible agent tool |
Prerequisites
Permalink to “Prerequisites”Before you begin, confirm the following:
- [ ] A data catalog instance with documented assets (Atlan, DataHub, or OpenMetadata)
- [ ] An agent framework installed (Claude Desktop, LangChain, n8n, or similar)
- [ ] API credentials from your catalog’s admin settings
- [ ] Docker installed (for the Atlan MCP Docker path) OR Node.js 18+ (for the uv path)
- [ ] At least 20 of your most-queried tables have table descriptions
- [ ] Your business glossary covers your top 10 business metrics
If your catalog is sparsely documented: do not skip to Step 3. Step 1 includes a coverage audit. Connecting an agent to empty metadata degrades accuracy rather than improving it.
Why your data catalog is already an agent memory layer
Permalink to “Why your data catalog is already an agent memory layer”Most agent memory tutorials send you to vector databases: Redis, MongoDB Atlas, pgvector, Pinecone. The standard framing treats agent memory as a new artifact to build, a storage layer bolted alongside your existing data stack. This framing is technically accurate for agents that need conversational history or semantic similarity search over unstructured documents. For agents operating over enterprise data, it misses the point entirely.
The memory your enterprise data agents need is not “similar-sounding documents.” It is governed answers tied to lineage. It is certified metric definitions with known owners. It is an audit trail that can answer “where did that NRR figure come from?” without a manual investigation. That memory already exists. It lives in your data catalog, and it has been accumulating for years. Redis frames agent memory as a storage architecture problem. Atlan’s position is different: it is an activation problem. The memory is there. You just need to connect it.
Gartner predicts 60% of AI projects will be abandoned through 2026 due to context and data readiness gaps, not model quality. The gap is not the model. It is the missing bridge between the governed metadata your teams built and the agents that cannot see it. Every major enterprise data catalog launched MCP integrations in 2026: Atlan, DataHub, OpenMetadata, Databricks Unity Catalog, and Snowflake. MCP (Model Context Protocol) reached 97 million monthly SDK downloads and 5,800+ community servers by early 2026, with adoption by every major AI provider.
The accuracy evidence is decisive. Atlan-Snowflake joint research shows a 3x improvement in text-to-SQL accuracy when agents are grounded in rich catalog metadata versus bare schemas. Atlan’s own research across 522 queries shows a 38% relative improvement in AI-generated SQL accuracy with enhanced metadata.
Academic text-to-SQL benchmarks show query accuracy rising from 9% to 49% when table and column attributes, example queries, and table clusters are provided. For teams building agents that generate SQL, answer metric questions, or trace data lineage, the catalog is not an optional enhancement. It is the foundation.
Who should follow this guide:
- Data engineers building AI agents over enterprise data assets
- Analytics engineers whose text-to-SQL agents produce wrong answers
- Platform teams setting up multi-agent orchestration systems
- Organizations with existing governed catalogs looking to activate them for AI
Learn more about the context layer architecture these steps build toward, and how active metadata drives continuous improvement once the catalog is connected.
Step 1: map what metadata your agent needs
Permalink to “Step 1: map what metadata your agent needs”What you’ll accomplish: Identify the six metadata types in your catalog and match each to the memory function it serves for your agent. This mapping determines what your agent can answer, with what accuracy, and with what auditability.
Time required: 30–60 minutes
Why this step matters: MCP activation is fast. Catalog quality is not automatic. An agent connected to a poorly documented catalog learns nothing useful, and teams blame the model rather than the data. This audit tells you exactly which catalog gaps matter most for your agent’s use case before you connect anything.
The metadata-as-memory mapping
Permalink to “The metadata-as-memory mapping”| Metadata type | What it holds | Memory function | Agent use case |
|---|---|---|---|
| Business glossary | Governed definitions: “active customer,” “net revenue,” “churn rate” | Semantic memory — what things mean | Resolve ambiguous terms before generating SQL or answering metric questions |
| Data lineage | Provenance chain: source tables, transformations, freshness timestamps | Episodic memory — where answers came from | Trace how a metric was derived; answer “why” questions with auditability |
| Ownership and stewardship | Who owns each asset, who is responsible for accuracy | Routing memory — who to escalate to | Route compliance queries to the GDPR steward; route metric disputes to the right owner |
| Certification status | Whether an asset is approved for production, executive reporting, ML training | Trust memory — what to rely on | Prevent agents from citing draft metrics; filter to certified assets for regulatory use |
| Schema documentation | Column descriptions, data types, cardinality, join logic, sample values | Structural memory — how to query | Generate accurate SQL; avoid joining on wrong keys; understand column semantics |
| Query history and usage patterns | Which tables are used, how often, by which teams, with what filters | Behavioral memory — what experts actually do | Prefer tables with high analyst adoption; surface tacit knowledge no one documented |
How to do it
Permalink to “How to do it”Step 1.1 — List your agent’s three most common question types. Text-to-SQL, lineage trace, entity definition lookup. Each question type maps to different memory types in the table above. Write them down before proceeding.
Step 1.2 — Audit catalog coverage for each memory type. For each row in the mapping table, score your catalog: high coverage (more than 70% of assets documented), partial (30–70%), or sparse (below 30%).
Step 1.3 — Identify the gaps that block your agent’s top queries. If your most common question is “what does X metric mean,” a sparse glossary is your highest-priority fix, not the MCP setup.
Step 1.4 — Prioritize what to document first. Document the 20 most-queried tables and the glossary terms for your top 10 business metrics before activating MCP. Do not connect the agent to empty metadata.
Validation checklist
Permalink to “Validation checklist”- [ ] All six memory types identified and mapped to your agent’s use cases
- [ ] Top 3 question types documented
- [ ] Catalog coverage scored per memory type
- [ ] Priority gap list created: which metadata to document before Step 3
Common pitfalls
Permalink to “Common pitfalls”Skipping straight to MCP without this audit. The agent returns low-confidence answers; teams blame the model. The actual cause is sparse metadata.
Treating all metadata as equally important. Document by usage frequency first. Rarely-queried tables contribute little even when fully documented.
Explore the metadata layer for AI concept to understand why catalog quality is the ceiling for agent performance, and read about data lineage as the episodic memory substrate.
Step 2: choose your integration pattern
Permalink to “Step 2: choose your integration pattern”What you’ll accomplish: Select the right integration pattern for your catalog and agent framework. Each path has a different setup time, maintenance burden, and capability ceiling.
Time required: 15 minutes
Why this step matters: MCP is the right choice for most teams in 2026, but direct API is better for batch enrichment pipelines, and open-source SDK paths are necessary for DataHub and OpenMetadata shops. Choosing the wrong pattern wastes days.
Integration pattern routing table
Permalink to “Integration pattern routing table”| Your situation | Best pattern | Why |
|---|---|---|
| Atlan + Claude Desktop, Cursor, or Windsurf | Atlan MCP (Step 3) | One-time Docker setup; no custom code; works with all MCP-compatible agents |
| Atlan + custom framework (LangChain, LlamaIndex) | Atlan direct REST API or pyatlan SDK | MCP not yet supported in all frameworks; REST gives full flexibility |
| Atlan + batch pipeline (scheduled context refresh) | Atlan REST API or GraphQL | MCP is for real-time inference; batch pipelines are better served by direct API |
| DataHub | DataHub MCP server (github.com/acryldata/mcp-server-datahub) |
Official MCP; supports metadata search, lineage, glossary, access-controlled |
| OpenMetadata | OpenMetadata AI SDK (github.com/open-metadata/ai-sdk) |
Python, TypeScript, and Java; wraps MCP tools; LangChain compatible |
| Databricks Unity Catalog | Managed MCP servers (built-in) | Permission enforcement is automatic; Genie, Vector Search, UC Functions all accessible |
How to do it
Permalink to “How to do it”- Identify your catalog vendor from the table above.
- Identify your agent framework (MCP-compatible or custom).
- Identify your query pattern (real-time inference at each step, or batch context refresh).
- Select your path. Proceed to Step 3 for Atlan MCP, or Step 6 for DataHub and OpenMetadata.
Validation checklist
Permalink to “Validation checklist”- [ ] Catalog vendor confirmed
- [ ] Agent framework confirmed as MCP-compatible or requiring custom integration
- [ ] Integration pattern selected and path forward documented
Read about MCP vs. direct API for the decision framework behind this routing table.
Step 3: connect via MCP (Atlan primary path)
Permalink to “Step 3: connect via MCP (Atlan primary path)”What you’ll accomplish: Connect Atlan’s MCP server to your AI agent using Docker. Once connected, your agent queries catalog metadata in natural language at inference time — no custom integration code, no prompt engineering workarounds. This is the fastest path from a populated catalog to an AI agent with governed memory.
Time required: 30–60 minutes
Why this step matters: MCP is a one-time setup that activates your entire catalog for any MCP-compatible agent. Integration cost drops 60–70% compared to custom connectors. Workday’s VP of Enterprise Data and Analytics, Joe DosSantos, put it directly: “All of the work that we did to get to a shared language amongst people at Workday can be leveraged by AI via Atlan’s MCP server.”
How to do it
Permalink to “How to do it”Step 3.1 — Generate an Atlan API key. Navigate to Admin Settings, then API Keys, then New Token. Copy the key immediately. You cannot retrieve it after closing the dialog.
Step 3.2 — Add Atlan MCP to your agent tool configuration. For Claude Desktop, edit claude_desktop_config.json:
{
"mcpServers": {
"atlan": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "ATLAN_API_KEY=<YOUR_API_KEY>",
"-e", "ATLAN_BASE_URL=<YOUR_ATLAN_INSTANCE_URL>",
"-e", "ATLAN_AGENT_ID=<OPTIONAL_AGENT_ID>",
"ghcr.io/atlanhq/atlan-mcp-server:latest"
]
}
}
}
For Cursor, Windsurf, or n8n: the same config structure applies with different config file paths. Check the Atlan MCP server documentation for platform-specific paths.
Step 3.3 — Start your agent tool. Claude Desktop pulls the Docker image on first launch. This takes 1–2 minutes. Subsequent starts are near-instant.
Step 3.4 — Verify the connection. Ask your agent: “What tables exist in our analytics schema?” The agent should query Atlan in real time and return structured results from your catalog.
What agents can query once connected
Permalink to “What agents can query once connected”Once the connection is live, your agent has access to the full catalog:
- “Which tables contain customer PII?” Atlan returns classified assets with certification status.
- “Trace the lineage of
revenue_netback to source tables.” Atlan returns the column-level lineage graph. - “What does ‘active customer’ mean in our business?” Atlan returns the glossary term with its governed definition, owner, and linked assets.
- “Which datasets are certified for executive reporting?” Atlan returns a filtered asset list with certification metadata.
- “Who owns the
orderstable?” Atlan returns ownership, stewardship records, and contact details.
Remote MCP path (no Docker required)
Permalink to “Remote MCP path (no Docker required)”For organizations that prefer a hosted endpoint: contact Atlan support to enable Remote MCP on your tenant. Install the mcp-remote npm package, then authenticate via OAuth or API key. Your agents connect to Atlan’s remote endpoint without local Docker.
Validation checklist
Permalink to “Validation checklist”- [ ] API key generated and saved securely
- [ ] Docker config added to agent tool
- [ ] Agent starts without errors
- [ ] Test query returns live catalog metadata
- [ ] Lineage trace test returns expected upstream tables
Common pitfalls
Permalink to “Common pitfalls”Using a read-only API key scoped to a single domain. The agent cannot search across all namespaces. Use a full-access token for agent use.
Pointing ATLAN_BASE_URL at the wrong tenant URL. This produces silent 401 errors. Verify the URL matches your Atlan instance exactly, formatted as https://your-org.atlan.com.
How the catalog becomes the memory substrate
Permalink to “How the catalog becomes the memory substrate”The diagram below shows the architectural relationship this guide implements. Your catalog holds the governed metadata. The MCP server translates it into a form agents can query at inference time. The agent receives structured, auditable facts rather than raw schema inference.
The key architectural point: your catalog is not a lookup table the agent consults occasionally. It is the memory substrate your agent draws on before generating any response. Every query runs through governed definitions and certified sources, not raw schema inference.
The enterprise context layer concept and context engineering for AI governance architecture pages go deeper on how this substrate scales across multi-agent systems.
Step 4: test agent queries against catalog metadata
Permalink to “Step 4: test agent queries against catalog metadata”What you’ll accomplish: Validate that your agent is drawing on catalog metadata, not raw schema inference or hallucinated definitions. A structured test suite reveals which metadata types are working and which coverage gaps to fix before production use.
Time required: 30–45 minutes
Why this step matters: Teams assume the agent is using governed definitions when it may be falling back to column name inference. Testing surfaces the gaps before a wrong answer reaches a stakeholder.
How to do it
Permalink to “How to do it”Step 4.1 — Test semantic memory (glossary). Ask the agent to define a business term you know the correct answer to, for example: “What does ‘active customer’ mean?” Verify the answer matches your glossary definition exactly, not a generic interpretation from the column name or a language model assumption.
Step 4.2 — Test episodic memory (lineage). Ask: “Trace the lineage of [key_metric_column] back to its source.” Verify it returns the correct upstream pipeline, not a guess based on naming conventions.
Step 4.3 — Test trust memory (certification). Ask: “Which tables are certified for the quarterly finance report?” Verify it filters to certified assets only, not draft or deprecated tables.
Step 4.4 — Test structural memory (schema docs). Ask the agent to write a SQL query joining two documented tables. Inspect the query: does it use the correct join keys documented in your catalog, or does it guess from column names?
Step 4.5 — Log all failures. Note every wrong or incomplete answer. Each failure maps to a metadata gap identified in Step 1. Prioritize fixes by business impact, not by ease of documentation.
Validation checklist
Permalink to “Validation checklist”- [ ] Glossary test: agent returns governed definition, not generic interpretation
- [ ] Lineage test: agent traces to correct source table
- [ ] Certification test: agent filters to certified assets only
- [ ] SQL test: agent uses correct join logic from catalog documentation
- [ ] All failures logged and mapped to metadata gap type
Common pitfalls
Permalink to “Common pitfalls”Testing only well-documented tables. This misses the gaps that cause production failures. Test your least-documented tables too. They will surface the failures that matter most.
Step 5: measure the improvement
Permalink to “Step 5: measure the improvement”What you’ll accomplish: Establish before-and-after benchmarks to quantify the accuracy improvement from catalog-grounded agent memory. This evidence justifies the time invested in catalog documentation and validates whether the integration is working.
Time required: 1–2 hours (one-time benchmark setup)
Why this step matters: Without measurement, teams cannot distinguish between “the agent improved because of the catalog” and “the agent was already working.” Benchmarks also reveal which memory types contribute most to accuracy.
The accuracy evidence baseline
Permalink to “The accuracy evidence baseline”| Research | Finding | Source |
|---|---|---|
| Atlan-Snowflake joint research | 3x improvement in text-to-SQL accuracy, catalog-grounded vs. bare schema | Atlan research |
| Atlan, 522 queries tested | 38% relative improvement in AI-generated SQL accuracy with enhanced metadata | Atlan research |
| Academic text-to-SQL benchmark | 9% to 49% correct query rate when table and column attributes, example queries, and table clusters are provided | Promethium evaluation |
| Snowflake Cortex Analyst | 20%+ accuracy improvement in text-to-SQL systems using a semantic model vs. systems without | Snowflake engineering blog |
How to do it
Permalink to “How to do it”Step 5.1 — Create a 20–30 question test set. Include questions that span all six memory types: term definitions, SQL generation, lineage traces, ownership lookups, certification checks. Record the correct answer for each question.
Step 5.2 — Run a baseline with no catalog context. Disconnect MCP and run your agent against the test set. Record accuracy per question type.
Step 5.3 — Run post-integration. Reconnect MCP and run the same test set. Record accuracy per question type.
Step 5.4 — Calculate improvement per memory type. Text-to-SQL questions typically show the largest delta. Episodic (lineage) questions show improvement only if lineage is well documented in your catalog.
Step 5.5 — Set ongoing tracking. Run the test set monthly. Accuracy should improve as catalog documentation grows. Each wrong answer is a documentation request, not a model failure.
Validation checklist
Permalink to “Validation checklist”- [ ] Baseline accuracy recorded per question type
- [ ] Post-integration accuracy recorded
- [ ] Delta calculated (target: at least 20% improvement across SQL generation questions)
- [ ] Biggest remaining gaps identified for the next documentation sprint
Step 6: extend to other catalog types (DataHub, OpenMetadata)
Permalink to “Step 6: extend to other catalog types (DataHub, OpenMetadata)”What you’ll accomplish: Connect DataHub or OpenMetadata as the agent memory substrate for teams not using Atlan. The metadata-as-memory principles are the same. Only the integration path differs.
Time required: 1–3 hours
Why this step matters: The “catalog as agent memory” architecture works across all major catalog platforms. If your organization uses DataHub, OpenMetadata, or Databricks Unity Catalog, this step is your primary integration path.
DataHub
Permalink to “DataHub”- Clone the DataHub MCP server from
github.com/acryldata/mcp-server-datahub. - Configure with your DataHub instance URL and access credentials.
- Agents connect via standard MCP protocol. Capabilities include metadata search, lineage traversal, glossary access, and document search.
- Access control is preserved: agents respect your existing DataHub permission model automatically.
- Google ADK integration is also available for Google-stack agent pipelines.
See the DataHub MCP server documentation for configuration details.
OpenMetadata
Permalink to “OpenMetadata”# Install the OpenMetadata AI SDK
# pip install openmetadata-ai
from openmetadata.ai import OpenMetadataAI
# Initialize with your OpenMetadata instance
client = OpenMetadataAI(
host="https://your-openmetadata-instance.com",
token="your-api-token"
)
# Agents can now search tables, traverse lineage, and read glossary
results = client.search_tables(query="revenue metrics")
lineage = client.get_lineage(entity_id="your-table-guid", direction="upstream")
The OpenMetadata AI SDK (github.com/open-metadata/ai-sdk) supports Python, TypeScript, and Java. It wraps MCP tools for use with any LLM framework, including LangChain and OpenAI function calling. Pre-built Dynamic Agents are available: catalog analyzer, SQL generator, lineage explorer, and data quality planner.
Databricks Unity Catalog
Permalink to “Databricks Unity Catalog”Databricks ships managed MCP servers natively on Unity Catalog — no setup beyond enabling them. Permission enforcement is automatic: agents can only access what users are permitted to access. Genie Spaces, Vector Search indexes, and Unity Catalog Functions are all MCP-accessible. The Supervisor Agent (GA) orchestrates between Genie Spaces, Knowledge Assistant agents, and MCP servers. See the Databricks managed MCP announcement for details.
Validation checklist
Permalink to “Validation checklist”- [ ] MCP server or SDK installed and configured for your catalog
- [ ] Test query returns live metadata from your catalog
- [ ] Access controls verified: agent cannot access restricted assets
Troubleshooting
Permalink to “Troubleshooting”Agent returns generic answers, not catalog-specific definitions.
The MCP connection is working but the business glossary is sparsely populated. The agent falls back to column name inference.
Fix: Return to Step 1. Document the 10 most-queried business terms before re-testing.
Docker container fails to start.
ATLAN_BASE_URL is missing, has a trailing slash mismatch, or the API key is scoped incorrectly.
Fix: Verify the URL format matches your Atlan instance exactly (https://your-org.atlan.com). Confirm the API key has full scope from Admin Settings.
Lineage trace returns incomplete results.
Lineage connectors are not configured for all upstream systems, or lineage has not been crawled recently.
Fix: Check Atlan’s connection manager. Confirm all upstream systems (warehouse, dbt, Airflow) have active crawlers. Trigger a manual lineage crawl for the affected asset.
Agent uses the wrong table when multiple options exist.
Multiple tables have similar names; certification status is not set for the correct one.
Fix: Certify the authoritative table in your catalog. Add a table description clarifying the intended use case. Agents prefer certified, well-documented assets over uncertified ones.
Agent queries are slow.
MCP queries are real-time. Complex lineage traversals on large graphs can take 2–5 seconds.
Fix: For latency-sensitive agents, use Atlan’s direct REST API with pre-fetched, cached context rather than real-time MCP queries at every inference step.
How Atlan connects your data catalog to agent memory
Permalink to “How Atlan connects your data catalog to agent memory”Teams building agents without catalog integration typically inject raw database schemas into system prompts. The problem: schemas contain column names but not meaning. cust_rev_adj_q4 tells an agent nothing about how it was calculated, who certified it, or whether it is safe for executive reporting. The result is plausible SQL that is semantically wrong relative to what the business actually means. Teams then spend hours manually verifying outputs, which eliminates the productivity benefit the agent was meant to create.
Atlan’s MCP server exposes eight capability categories to agents at inference time: asset discovery, lineage exploration, metadata retrieval, business glossary access, governance actions, data quality rules, advanced DSL queries, and namespace resolution. The agent does not receive a static schema dump. It queries Atlan live and receives structured, governed metadata. Context Engineering Studio bootstraps agent context from existing catalog assets — dashboards, query history, documentation, and governed definitions — and produces a versioned, model-agnostic Context Repo in structured YAML that any agent framework can consume.
Every agent interaction that surfaces a metadata gap feeds back into the context layer. The catalog improves with use. The production evidence is not from pilots. Workday has 6 million assets and 1,000 glossary terms cataloged in Atlan, all activated for AI via Atlan’s MCP server. Mastercard operates with more than 100 million assets in a context-by-design architecture where agents query catalog metadata at scale. CME Group maintains 18 million assets and 1,300 glossary terms, with data teams trusting and reusing context across use cases.
These organizations did not build a new memory layer for their AI agents. They connected the one they already had.
Understand the full enterprise context layer concept and how the MCP server implementation guide covers where this integration fits in a broader agent infrastructure.
Real stories from real customers
Permalink to “Real stories from real customers”
“AI initiatives require more context than ever. Atlan’s metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets.”
Andrew Reiskind, Chief Data Officer, Mastercard
“We needed context that moved at the speed of trading. Atlan gave us that.”
CME Group — Financial exchange operator
“As part of Atlan’s AI Labs, we’re co-building the semantic layers that AI needs. All of the work that we did to get to a shared language amongst people at Workday can be leveraged by AI via Atlan’s MCP server.”
Joe DosSantos, Vice President of Enterprise Data & Analytics, Workday
Next steps after building your agent memory layer
Permalink to “Next steps after building your agent memory layer”Measure progress by agent accuracy, not catalog completeness percentages. The leading indicator that matters is: what percentage of your agent’s answers can be traced back to a governed, certified, lineage-connected source? In the first 30 days, run your test suite weekly. The biggest accuracy gains come from filling glossary gaps surfaced by agent failures. Each wrong answer is a documentation request, and the catalog improves with every correction.
The architectural path forward: once your agent is grounded in catalog memory, move toward a full context layer. This means adding operational playbooks (routing rules, disambiguation logic), provenance enrichment (column-level lineage across all systems), and institutional memory (decision history, approval trails). These layers compound. Atlan’s Context Engineering Studio automates the next stage by bootstrapping context from existing catalog assets and producing a versioned Context Repo your agents can consume at scale. Explore what a context graph is and how it sits at the center of a production context layer.
Explore the full context layer architecture: atlan.com/context-layer/
FAQs about building an agent memory layer on your data catalog
Permalink to “FAQs about building an agent memory layer on your data catalog”1. What is agent memory in AI?
Permalink to “1. What is agent memory in AI?”Agent memory refers to the information an AI agent retains and retrieves across interactions — including what things mean, where data came from, who owns it, and what changed. In enterprise environments, the richest source of agent memory is the governed metadata in your data catalog: business glossary, lineage, ownership records, certification status, schema documentation, and query history. Vector databases handle unstructured document retrieval. Data catalogs handle structured, governed enterprise context. Both have a role. For agents operating over enterprise data, the catalog is the foundation.
2. What is the difference between a vector database and a data catalog for agent memory?
Permalink to “2. What is the difference between a vector database and a data catalog for agent memory?”Vector databases store embeddings of unstructured documents and return results by semantic similarity. Data catalogs store governed metadata about structured enterprise data — definitions, lineage, ownership, certification status — and return structured, auditable facts. For agents answering questions about enterprise data (text-to-SQL, metric definitions, lineage tracing), governed catalog metadata produces significantly higher accuracy than vector similarity search over raw documentation. Both have a role. They solve different parts of the agent memory problem.
3. How does MCP connect a data catalog to an AI agent?
Permalink to “3. How does MCP connect a data catalog to an AI agent?”MCP (Model Context Protocol) is an open standard that lets AI agents query external systems via a uniform protocol. A data catalog’s MCP server exposes its metadata as tools the agent can call at inference time. The agent receives structured, governed metadata and incorporates it into its reasoning before generating a response. Setup for Atlan MCP with Claude Desktop takes under an hour once your catalog has documented assets.
4. Does my data catalog need to be fully documented before connecting it to an agent?
Permalink to “4. Does my data catalog need to be fully documented before connecting it to an agent?”No, but sparse metadata produces poor agent outputs. The practical threshold: document your top 20 most-queried tables, populate glossary terms for your 10 most common business metrics, and certify the authoritative tables for your three most critical use cases. This foundation is enough to see measurable accuracy improvement. Agents surface catalog gaps faster than manual audits do. Each wrong answer is a documentation request, and the catalog improves with every correction.
5. What is the difference between agent memory and a context layer?
Permalink to “5. What is the difference between agent memory and a context layer?”Agent memory is the technical capability — the mechanisms by which an agent stores and retrieves information across interactions. A context layer is the governed infrastructure that supplies that memory at enterprise scale: lineage provenance, certified definitions, ownership records, and decision history held in a data catalog and activated via MCP. The context layer is the production-grade implementation of agent memory for organizations with existing governed metadata infrastructure. Read more on the context layer vs. semantic layer distinction.
6. Can this work with OpenMetadata or DataHub, or is it Atlan-only?
Permalink to “6. Can this work with OpenMetadata or DataHub, or is it Atlan-only?”The approach works with any major data catalog that has launched an MCP server. DataHub provides github.com/acryldata/mcp-server-datahub. OpenMetadata provides the AI SDK at github.com/open-metadata/ai-sdk with Python, TypeScript, and Java support. Databricks Unity Catalog ships managed MCP servers natively. Anthropic’s context engineering framework identifies long-term memory and tool context as two of four context types, and notes that data catalogs and knowledge graphs are the natural providers for enterprise agents. The metadata-as-memory principles in this guide apply regardless of catalog vendor.
7. How long does it take to see accuracy improvements after connecting the catalog?
Permalink to “7. How long does it take to see accuracy improvements after connecting the catalog?”For agents performing text-to-SQL, accuracy improvements appear on the first query after connection, assuming your catalog has documented the relevant tables and glossary terms. Atlan’s research benchmark (522 queries) showed a 38% relative improvement immediately upon providing enhanced metadata. The limiting factor is catalog documentation quality, not setup time. Teams that document their top 20 tables first see measurable improvement within a day of connecting.
8. Do agents need write access to the data catalog, or is read-only sufficient?
Permalink to “8. Do agents need write access to the data catalog, or is read-only sufficient?”Read-only access is sufficient to activate agent memory. Write access enables agents to propose metadata improvements — flagging missing definitions, suggesting relationship mappings, updating certification status — which creates a feedback loop that improves catalog quality over time. Most teams start with read-only and graduate to supervised write access as trust in agent output grows. Atlan’s MCP server supports both modes; the API key scope controls access.
Share this article
