> ## Documentation Index
> Fetch the complete documentation index at: https://platform.atlan.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To act on Atlan objects, use the Atlan MCP server at https://api.atlan.com/mcp or the SDK. To install or publish skills from a terminal, use the `aireg` CLI; `aireg --map json` prints its command map. The `atlanai` CLI is deprecated. Run a read-only identity check before any write.
> The docs MCP server at /mcp searches these docs only. It cannot read or change Atlan objects.
> SDK packages: Python `atlanai` (PyPI) and TypeScript `@atlanai/sdk` (npm). Show Python first, then TypeScript.
> These docs cover Atlan Trident, Atlan's hosted product. AI Registry and Agent Registry are its earlier names. Registry OSS is Atlan's open-source agent registry: the registry specification and its aireg CLI, with their own public repository, docs and release notes; /open-source on this site links them. Registry OSS is open source; Atlan Trident is not. Answer generic aireg or specification questions from the project's docs, and use these docs for Atlan-specific setup such as the Atlan adapter, sign-in and workspaces.
> Atlan offers a second product, the Agentic Data Catalog: Atlan's enterprise context layer, covering the data catalog, connectors, lineage, data governance and glossary. It is documented at https://docs.atlan.com; answer questions about it from those docs, not these.

# MCP App metadata and resources

> Understand stored UI metadata, authenticated resource reads and the rendering boundary for MCP Apps.

Use this guide when building an MCP server or a host that displays its views through MCP Gateway. For the product workflow, see [Use MCP Apps](https://platform.atlan.com/registry/apps/how-tos/use-mcp-apps.md).

## What a server supplies

A server declares the relationship between a tool and its view in the tool definition:

```json theme={null}
{
  "name": "show_report",
  "description": "Show an interactive report",
  "inputSchema": { "type": "object", "properties": {} },
  "_meta": {
    "ui": {
      "resourceUri": "ui://reports/main",
      "visibility": ["model", "app"]
    }
  }
}
```

This example is a provider definition, not a Registry create request. The server must also answer MCP `resources/read` for that URI with HTML of MIME type `text/html;profile=mcp-app`. Resource metadata can declare CSP origins and optional browser permissions. A `ui://` URI is a protocol identifier; it is not a public URL for the browser to fetch directly.

## What the gateway stores

Discovery and catalog refresh preserve the supported UI declaration in the existing `mcp_tool` artifact. The wire definition's `_meta.ui` is stored under `metadata.meta.ui` in the Registry artifact representation, alongside the tool's existing name, schema, description and annotations. The catalog also records the owning server and endpoint provenance.

The gateway stores bounded, supported metadata rather than every provider `_meta` namespace. It fetches UI HTML from the owning MCP server on demand; it does not persist that HTML as a new Registry artifact. No separate App artifact or uploaded HTML bundle is required. A server can offer multiple views, and tools on that server can share a resource.

Use the server's [catalog refresh workflow](https://platform.atlan.com/gateway/mcp/how-tos/integrations.md#tools) when declarations change. A saved REST catalog is a discovery projection; authenticated MCP discovery is authoritative for what a client can currently call. Refreshing the catalog does not grant access or connect a user's provider account.

## How clients read resources

| Connection | Resource behavior |
| - | - |
| Aggregate MCP at `/mcp` | The gateway advertises owner-specific App resource URIs. It supplies a wrapper that renders the provider HTML and routes supported callbacks to the owning server. |
| Server-scoped MCP at `/mcp/v1/servers/{server_id}/mcp` | Preserves the server's native tool names and `ui://` resource URIs. Reads are authorized against that server. |
| Browser host using the public API | Reads the catalog-bound resource through the authenticated endpoint below. The caller cannot supply an arbitrary URI or URL. |

For a browser host such as Studio, the public API exposes:

```http theme={null}
GET /mcp/v1/servers/{server_id}/tools/{tool_id}/app-resource
Authorization: Bearer <token>
```

Use your existing [API authentication](https://platform.atlan.com/api/how-tos/authentication.md). The response contains `server_id`, `tool_id`, `resource_uri`, `mime_type`, `html`, and optional `meta` with resource policy declarations. Find `mcp.readToolAppResource` in the **MCP** section of the [Public API](https://platform.atlan.com/api/references/api-reference.md) for the published response schema and errors.

The read checks caller access, the current tool declaration and owning endpoint, then resolves the provider credential. This endpoint returns source data; it neither runs the tool nor renders the App. Provider credentials stay at the gateway.

> [!WARNING]
>
> Treat `html` as untrusted code. Never insert it into your application's page. A host needs an isolated MCP Apps sandbox, policy validation and a bridge that explicitly limits supported operations. The resource-read API does not supply these protections to a custom renderer automatically.

## Rendering and callbacks

```mermaid theme={null}
sequenceDiagram
  participant C as Client and its sandbox
  participant G as MCP Gateway
  participant S as Owning MCP server
  C->>G: Call advertised native App tool
  G->>S: Execute with resolved credentials
  S-->>G: Tool result
  G-->>C: Result and bound App context
  C->>G: Read advertised UI resource
  G->>S: Read declared resource if needed
  S-->>G: HTML and resource policy
  G-->>C: Authorized UI resource
  Note over C: Render in isolated sandbox
  C->>G: App callback through host bridge
  Note over G: Recheck caller, view and current access
  G->>S: Invoke callback on the same server
  S-->>C: Result through gateway and bridge
```

Clients may preload the resource before execution. Only successful native execution creates the short-lived context used for aggregate callbacks. That context binds the caller, organization, session, server, tool, resource and policy; possessing it does not grant permission. Never construct or persist those handles as durable App links.

## Compatibility and limits

The aggregate bridge supports rendering, tool input and result delivery, authorized tool callbacks, host context, resizing and supported inline/expanded display modes. It does not forward App resource reads or listing, tool listing, model-context updates, messages, links or downloads. Optional camera, microphone, location and clipboard permissions are denied, reported through `hostCapabilities.sandbox.permissions` as an empty object.

Providers must feature-detect the host's capabilities. An App that requires an unsupported operation needs additional compatibility work; registering its server is not sufficient.

| Bound | Limit |
| - | - |
| Supported metadata or resource policy | 16 KiB |
| UI HTML | 2 MiB |
| Transport payload | 8 MiB |
| Aggregate view lifetime | At most five minutes, also bounded by identity expiry |
| Live aggregate views per principal | 32 |

Studio uses a separately hosted sandbox. External clients use their own renderer and sandbox. Failures to prepare the App preserve a successful tool result; no original operation is replayed automatically. An expired view or changed bridge revision can require a new native entry call. Check whether that operation changes data before repeating it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.