Every tool your team uses.
Every agent you deploy.
One context layer.

A data catalog stores documentation about your data — descriptions, ownership, tags. A context layer actively delivers that context to connected AI tools at query time, in the format those tools can use. RAG retrieves documents that might be relevant; the context layer delivers certified, structured context — specific definitions, lineage traces, access controls — from a governed source. In practice: RAG-grounded answers are only as good as the retrieved document. Context-layer-grounded answers reflect your actual business logic, maintained and certified by the people who own the data.

Column-level lineage (where data came from and what it feeds downstream), certified metric definitions (the definition your team approved, not the model's interpretation), business glossary terms (what your org means by "revenue," "churn," or "active user"), data quality scores (current quality status from the source system), ownership records (who is responsible for each asset), and access control rules (what the requesting user is allowed to see). When an agent requests context about a table, it gets all of this in a single response — structured context, not a document to search through.

Yes. Atlan MCP exposes 29 tools across 8 categories. Read tools — semantic_search, get_assets, traverse_lineage, resolve_metadata, and others — deliver catalog context at query time. But the same connection supports write operations: agents can update descriptions, apply or remove classification tags with optional downstream propagation through lineage, set certification status, create glossary terms, and manage announcements — all from within the AI tool conversation. Every change is marked as "Updated using Atlan AI" in the audit trail. Admin tools for data quality rules and custom metadata schemas require Atlan admin permissions.

No. Atlan MCP only delivers metadata — descriptions, lineage, ownership records, glossary terms, certification status, classification tags, and quality scores. Your actual row-level data does not pass through MCP. Metadata is retrieved in real time from Atlan's REST APIs with no intermediate caching, and neither your metadata nor your prompts are used by Atlan or its AI providers to train or fine-tune foundation models. All tool calls are logged as structured audit events with sensitive fields masked before storage.

Two options. OAuth (recommended for individuals) runs every call as the signed-in user — the same roles, personas, and access rules they have in Atlan apply automatically to every tool call, with no separate permissions to configure. API keys, generated from Admin Settings → API Keys/Tokens, are for service accounts and automation workflows like n8n and Windsurf. API key tokens scoped to multiple personas are rejected; service identities must operate within a single permission scope. Each Atlan tenant has a dedicated MCP server instance with no shared state between tenants.

No. Atlan hosts and manages the MCP server for every tenant at https://your-tenant.atlan.com/mcp — nothing to deploy, maintain, or scale on your side. Most tools (Cursor, VS Code, Claude Code, Snowflake Cortex) connect directly via HTTP with no intermediary. Tools that don't yet support native HTTP transport — Claude Desktop and Google ADK — use the open-source mcp-remote npm package as a local bridge to the same hosted endpoint; this requires Node.js 18+ installed locally.

Atlan's Context Agents continuously read from connected systems — query history, lineage signals, column usage, BI semantic models, and documentation — and update the context layer as things change. Atlan MCP retrieves metadata in real time from Atlan's REST APIs with no intermediate caching, so any enrichment Context Agents have applied is immediately available to every connected AI tool on the next query. There is no refresh cycle to manage and no stale cache to clear.

Yes. Atlan exposes context through multiple interfaces simultaneously — MCP, SQL, API, and Graph — so Cursor, a Snowflake Cortex agent, a custom Google ADK agent, and a Glean-powered copilot can all read from the same certified context source at the same time. Each tool connects via its preferred protocol. When the context layer updates, all of them get the update. This is how you avoid context sprawl — Cortex and your ADK agent stay in sync on the same version of "revenue."

Local MCP runs a context server on the developer's machine, requiring each user to manage their own connection and credentials. Remote MCP — Atlan's recommended deployment — runs the MCP server centrally, so every developer, every agent, and every tool connects to the same governed, current context layer without per-user setup. Context updates reach all connected tools immediately, rather than requiring each local instance to pull new context.