Skip to content

Connect Atlan to Claude: Provision Users and Manage SSO Mappings

Learn how to connect Atlan to Claude using a managed MCP server. Automate user provisioning, RBAC updates, and SSO group mappings with AI agents.

Uday Gajavalli Uday Gajavalli · · 10 min read
Connect Atlan to Claude: Provision Users and Manage SSO Mappings

If you need to connect Atlan to Claude to automate user provisioning, manage active metadata access controls, or synchronize SSO group mappings, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and Atlan's REST APIs. You can either build and maintain this infrastructure yourself, dealing with the constant churn of API updates, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on /connect-atlan-to-chatgpt-manage-user-roles-and-group-governance/ or explore our broader architectural overview on /connect-atlan-to-ai-agents-automate-access-and-group-membership/.

Giving a Large Language Model (LLM) read and write access to a complex data governance ecosystem like Atlan is a serious engineering undertaking. You have to handle API token lifecycles, map intricate JSON schemas to MCP tool definitions, and ensure Identity and Access Management (IAM) controls remain strictly enforced. Every time Atlan updates a resource requirement, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Atlan, connect it natively to Claude, and execute complex data catalog administration workflows using natural language.

The Engineering Reality of the Atlan API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable, standardized way for models to discover tools, implementing it against a specific vendor's API requires understanding their unique architectural decisions.

If you decide to build a custom MCP server for Atlan, you own the entire API lifecycle. Here are the specific engineering challenges you will face when wrapping Atlan for AI agents:

GUID Resolution and Chained References

Atlan heavily relies on globally unique identifiers (GUIDs) to establish relationships between entities. If you ask an LLM to "add Jane to the Admin role," the model cannot simply pass the string "Admin" in the API payload. It must first query the roles endpoint to resolve the human-readable string "Admin" into its corresponding role GUID, and then pass that GUID into the user creation payload. You must architect your MCP server to expose these lookup endpoints as discrete tools and instruct the LLM on how to chain them together, or build complex orchestration logic into a single monolithic tool.

Strict Attribute Schemas and Path Structures

Because Atlan is built upon the foundations of Apache Atlas, its data model is highly extensible but strictly enforced. When creating an Atlan group, attributes like alias and isDefault cannot be simple strings or booleans - they must be formatted as arrays of strings. Furthermore, internal names must be entirely lowercase alphanumeric characters separated by underscores, and group paths must be prefixed with a forward slash (/). If you pass raw OpenAPI specs to an LLM without adding explicit validation context, the model will frequently hallucinate invalid JSON structures or violate these naming constraints, resulting in HTTP 400 Bad Request errors.

Explicit Rate Limit Handling

Data governance platforms often enforce strict concurrency and request limits to protect database stability. Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Atlan API returns an HTTP 429 Too Many Requests, Truto passes that error directly back to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification (see https://truto.one/docs/api-reference/overview/rate-limits). The caller - in this case, your AI agent framework or Claude client - is entirely responsible for implementing its own retry logic and exponential backoff.

Creating the Atlan MCP Server

Truto derives tool definitions dynamically from the integration's documented API resources. This documentation-driven approach means tools are generated on the fly, accurately reflecting the current state of the Atlan API.

You can create an MCP server for your Atlan integration using either the Truto UI or the API.

Method 1: Via the Truto UI

For teams who prefer visual configuration, the Truto dashboard provides a straightforward path to generating an MCP server:

  1. Log in to your Truto dashboard and navigate to the Integrated Accounts section.
  2. Select your connected Atlan account.
  3. Click on the MCP Servers tab.
  4. Click Create MCP Server.
  5. Select your desired configuration (name, allowed methods, tags, and expiration).
  6. Copy the generated MCP server URL. You will use this URL to connect Claude in the next phase.

Method 2: Via the API

For platform engineers building multi-tenant AI products, MCP servers should be provisioned programmatically. You can create a server by making a POST request to /integrated-account/:id/mcp.

The API validates the configuration, generates a secure, hashed token, stores it in a distributed edge storage system, and returns a ready-to-use URL.

curl -X POST https://api.truto.one/integrated-account/<atlan_integrated_account_id>/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Atlan IAM Provisioning",
    "config": {
      "methods": ["read", "write"],
      "tags": ["users", "groups", "sso"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response will contain the unique URL required for the MCP connection:

{
  "id": "mcp_srv_98765xyz",
  "name": "Atlan IAM Provisioning",
  "config": { 
    "methods": ["read", "write"], 
    "tags": ["users", "groups", "sso"] 
  },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/t_a1b2c3d4e5f6..."
}

Connecting the MCP Server to Claude

Once you have the Truto MCP URL, you need to register it with your Claude client. The URL itself acts as the authentication vector - it encodes the integration tenant and tool scope.

Method A: Via the Claude UI

If you are using an Enterprise or Team plan with managed connectors (or ChatGPT's equivalent settings), you can add the URL directly through the interface:

  1. In Claude, navigate to Settings -> Integrations.
  2. Click Add MCP Server.
  3. Provide a name (e.g., "Atlan Governance Tools").
  4. Paste the URL copied from Truto (https://api.truto.one/mcp/...).
  5. Click Add. Claude will instantly execute a handshake to discover the available Atlan tools.

Method B: Via Manual Config File

For developers using the Claude Desktop application, you can configure the MCP server by modifying the JSON configuration file. Since Truto MCP servers communicate over HTTP using Server-Sent Events (SSE), you use the standard @modelcontextprotocol/server-sse transport.

Locate your claude_desktop_config.json file (typically found in %APPDATA%\Claude\ on Windows or ~/Library/Application Support/Claude/ on macOS) and add the following:

{
  "mcpServers": {
    "atlan-governance": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/t_a1b2c3d4e5f6..."
      ]
    }
  }
}

Restart Claude Desktop. The application will initialize the connection and the Atlan tools will appear with a hammer icon in your input bar.

Hero Tools for Atlan IAM

When you connect Atlan via Truto, dozens of proxy APIs are immediately mapped to MCP tools. Here are the highest-leverage operations for automating user provisioning and SSO governance.

1. list_all_atlan_roles

Before you can provision a new user or modify an existing one, you must acquire the internal role GUID. This tool lists all available workspace roles in Atlan.

Contextual usage: LLMs should be instructed to call this tool first whenever a user requests a role assignment by name (e.g., "Admin" or "Member"), caching the ID for subsequent write operations.

"I need to promote John Doe to a workspace admin. Please list all Atlan roles so we can find the exact ID for the Admin role."

2. create_a_atlan_user

This tool invites a new user to Atlan by passing an array of user objects.

Contextual usage: You must provide an email, role, and roleId. The role string must strictly match $admin, $member, or $guest. LLMs handle the array structuring automatically when provided with the correct schema by Truto.

"Now that we have the Admin role ID, please invite sarah.connor@example.com to Atlan as a workspace $admin."

3. create_a_atlan_group

This tool provisions a new group in Atlan. Because Atlan's backend enforces rigid data types, this tool expects a specific nested structure.

Contextual usage: The internal name must be unique, lowercase, and use underscores instead of spaces (e.g., data_science_team). Attributes like alias and isDefault must be formatted as arrays of strings.

"Create a new Atlan group called 'Data Engineering'. Make sure the internal name is formatted correctly as data_engineering, and add 'Data Eng Team' to the alias array."

4. atlan_users_add_to_groups

Once users and groups exist, this tool bridges the gap by linking a user to one or more groups.

Contextual usage: You must supply the user's ID (which can be obtained via list_all_atlan_users) and an array of target group IDs. It returns an empty 204 response on success.

"Take Sarah's user ID and add her to the 'data_engineering' group you just created."

5. list_all_atlan_sso_group_mappings

For enterprise environments, managing groups manually is an anti-pattern. You should map Identity Provider (IdP) groups (like Okta or Entra ID) directly to Atlan groups. This tool retrieves existing maps for a given SSO alias.

Contextual usage: Requires the sso_alias parameter, which corresponds to your configured IdP connection in Atlan.

"Fetch all current SSO group mappings for our IdP alias 'okta_main' to see if the Data Engineering group is already mapped."

6. create_a_atlan_sso_group_mapping

This tool links an external IdP group to an internal Atlan group, enabling automated provisioning upon user login.

Contextual usage: You must provide the sso_alias alongside the identity provider mapping configuration. This requires precision, as misconfigurations can lock users out of their expected workspaces.

"Create a new SSO group mapping for 'okta_main'. Link the Okta group 'okta-data-eng' to the Atlan group 'data_engineering'."

For the complete inventory of Atlan tools - including updates, deletions, and member lookups - visit the Atlan integration page for comprehensive schema details.

Workflows in Action

When AI agents have access to these primitive tools, they can orchestrate complex, multi-step administrative workflows that would normally require an IT administrator to navigate through several UI screens or write custom Python scripts.

Workflow 1: New Data Engineer Onboarding

When a new hire joins, IT teams need to ensure they have the correct workspace access. You can prompt Claude to handle the entire lifecycle.

"We have a new hire, David. His email is david.smith@company.com. Please invite him to Atlan as a member, find the 'data_engineering' group, and add him to it."

Here is how Claude executes this request autonomously:

sequenceDiagram
    participant User as User
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant Atlan as Atlan API

    User->>Claude: "Invite David..."
    
    Claude->>Truto: call tool: list_all_atlan_roles
    Truto->>Atlan: GET /api/service/roles
    Atlan-->>Truto: Return role IDs
    Truto-->>Claude: Role ID for $member
    
    Claude->>Truto: call tool: create_a_atlan_user
    Truto->>Atlan: POST /api/service/users
    Atlan-->>Truto: 204 Success
    Truto-->>Claude: User invited
    
    Claude->>Truto: call tool: list_all_atlan_users
    Truto->>Atlan: GET /api/service/users?filter=david.smith
    Atlan-->>Truto: Return User ID
    Truto-->>Claude: David's User ID
    
    Claude->>Truto: call tool: list_all_atlan_groups
    Truto->>Atlan: GET /api/service/groups
    Atlan-->>Truto: Return Group IDs
    Truto-->>Claude: data_engineering Group ID
    
    Claude->>Truto: call tool: atlan_users_add_to_groups
    Truto->>Atlan: POST /api/service/users/{id}/groups
    Atlan-->>Truto: 204 Success
    Truto-->>Claude: User added to group
    
    Claude-->>User: "David has been invited as a member and added to the data_engineering group."

What the user gets back: Claude confirms that David has been invited, explicitly stating that it retrieved the necessary Role ID and Group ID in the background to fulfill the request.

Workflow 2: Automated SSO Migration

During an IdP migration or a security audit, you might need to remap how external groups map to internal Atlan access.

"We are migrating our analytics team to a new Okta group. Find the existing SSO mapping for the Atlan group 'analytics_core' under the 'okta_legacy' alias, delete it, and create a new mapping under 'okta_main' linking the external group 'okta-analytics-new' to 'analytics_core'."

Step-by-step Execution:

  1. list_all_atlan_sso_group_mappings: Claude queries mappings for okta_legacy to find the specific mapping ID tied to analytics_core.
  2. delete_a_atlan_sso_group_mapping_by_id: Claude removes the stale link, preventing authorization conflicts.
  3. list_all_atlan_groups: Claude fetches the internal group ID for analytics_core.
  4. create_a_atlan_sso_group_mapping: Claude constructs the strict JSON payload linking okta-analytics-new to the fetched group ID under the okta_main alias.

What the user gets back: A complete summary of the migration, noting the deleted mapping ID and confirming the successful creation of the new SSO bridge.

Security and Access Control

Exposing enterprise IAM tools to an LLM requires strict boundary setting. Truto's MCP architecture provides multiple layers of access control built directly into the server URL generation process:

  • Method Filtering: By passing config.methods: ["read"] during server creation, you can generate a strictly read-only MCP server. This allows an AI agent to audit roles and group memberships without the risk of accidentally deleting an SSO mapping or altering permissions.
  • Tag Filtering: You can restrict the LLM's context exclusively to IAM tools by passing config.tags: ["users", "groups"]. This prevents the model from hallucinating calls to metadata tagging endpoints if you only want it managing identities.
  • Secondary Authentication (require_api_token_auth): By default, possessing the MCP URL grants access. By setting require_api_token_auth: true, the protocol handler mandates that the MCP client (like Claude) also passes a valid Truto API token in the Authorization header, ensuring URLs leaked in logs remain useless to unauthorized users.
  • Time-To-Live (expires_at): You can bind MCP servers to a strict TTL. Once the expiration timestamp is reached, an automated cleanup scheduler permanently purges the token from the edge storage network, instantly invalidating the connection - ideal for temporary contractor access or time-boxed audit workflows.

Streamlining Enterprise Data Governance

Managing users, roles, and SSO mappings in active metadata platforms is traditionally a high-friction process requiring deep domain knowledge of the platform's specific REST idioms. By connecting Atlan to Claude through a dynamically generated MCP server, you abstract away the complexities of GUID lookups, strict string-array schemas, and pagination mechanics.

Instead of writing custom Python scripts to bridge your IdP and your data catalog, you can rely on Truto's protocol handling to execute natural language prompts safely and reliably. This fundamentally changes how IT and data engineering teams operate, shifting their focus from tedious API orchestration to high-level governance strategy.

FAQ

How do I give Claude access to Atlan?
You can provide Claude with access to Atlan by deploying a Model Context Protocol (MCP) server that translates Claude's tool calls into Atlan API requests. Using a platform like Truto, you can generate this server dynamically and paste the connection URL directly into Claude's settings.
Can Claude update Atlan SSO mappings?
Yes. By exposing Atlan's SSO mapping endpoints as MCP tools, Claude can create, update, or delete identity-provider group mappings, allowing you to manage access control across your organization via natural language.
How does Truto handle Atlan rate limits?
Truto passes rate limit errors (HTTP 429) directly to the caller and normalizes the upstream rate limit information into standard headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller or AI agent is responsible for handling retries and backoff.
What is the internal name requirement for Atlan groups?
Atlan requires group internal names to be unique, entirely lowercase, and contain only alphanumeric characters and underscores. Claude can automatically format group names to meet these constraints when using an appropriately configured MCP tool.

More from our Blog