Skip to content

The MCP ecosystem includes two types of services that AI agents connect to: MCP servers and MCP apps. While both use the Model Context Protocol: A standard protocol for AI agent and server interactions that defines how AI assistants communicate with external tools and data sources.Learn more(opens in new tab), they expose different capabilities and behave differently when connected through the Aembit MCP Identity Gateway.

This page explains the distinction and what Aembit supports for each. For the official specification, see the MCP Apps overview in the MCP documentation.

A traditional MCP Server: A server that implements the Model Context Protocol to provide tools, resources, or data to AI agents and MCP clients.Learn more(opens in new tab) exposes tools that AI agents can invoke. Tools are actions like querying a database, sending an email, or creating a Jira ticket. The AI agent (LLM) decides when to call a tool and provides the required parameters.

Most MCP servers in use today expose only tools. The Aembit MCP Identity Gateway fully supports tool discovery (tools/list) and invocation (tools/call) across all assigned MCP servers.

An MCP App: A UI application that renders inside an MCP host such as Claude Desktop. MCP Apps combine a tool (which declares a UI resource via _meta.ui.resourceUri) with an HTML resource that the host renders in a sandboxed iframe. Defined as an extension to the core MCP specification.Learn more is an interactive UI application that renders inside an MCP host such as Claude Desktop or ChatGPT. MCP Apps are an extension to the core MCP specification, not part of the base protocol.

An MCP App works by combining two MCP primitives: a tool that declares a UI resource in its description (via a _meta.ui.resourceUri field pointing to a ui:// resource), and a resource that contains an HTML page the host renders in a sandboxed iframe. This lets MCP servers return interactive interfaces — data visualizations, forms, dashboards — directly in the chat conversation.

In short:

  • MCP servers expose tools (actions the LLM invokes)
  • MCP apps extend MCP servers with interactive HTML interfaces that render inside the host

How the Identity Gateway handles apps vs servers

Section titled “How the Identity Gateway handles apps vs servers”

This section describes how Aembit’s MCP Identity Gateway supports MCP servers and MCP apps, including any limitations or expected behaviors when connecting each type through the Identity Gateway.

The Identity Gateway proxies tool discovery and invocation for both MCP servers and MCP apps. When an MCP client requests tools/list, the Identity Gateway fans out the request across all assigned MCP servers. It aggregates the results and returns them with server-specific prefixes to prevent name collisions.

The Identity Gateway also preserves Tool annotations: Metadata in MCP tool discovery responses that categorize tools by behavior, such as read-only or destructive operations. MCP clients use annotations to drive safety decisions — specifically whether to auto-approve a tool call or prompt the user for confirmation.Learn more(opens in new tab) in tools/list responses. Annotations categorize tools by behavior (such as read-only or destructive operations), and MCP clients use them to organize tools in their UI.

Resource support (supported with limitations)

Section titled “Resource support (supported with limitations)”

The Identity Gateway supports MCP Resource: Data that an MCP server exposes for context, such as files, database schemas, or documentation. Unlike tools, which are model-controlled, resources are application-controlled — the client or user decides when to retrieve them, not the model.Learn more(opens in new tab) discovery and retrieval:

MethodDescription
resources/listDiscovers available resources across all assigned MCP servers. Returns resource URIs as-is without server-specific prefixes.
resources/readRetrieves a specific resource by URI from the appropriate MCP server.

Resources go through the same Access Policy evaluation, authentication, and credential injection as tool requests. Aembit doesn’t require any special configuration to support resources from MCP apps.

The Identity Gateway can proxy tool and resource requests from MCP apps. One limitation exists: the Identity Gateway adds server-specific prefixes to tool names, which can conflict with the _meta.ui.resourceUri references that MCP apps use to link tools to their UI resources.

In practice, this means:

  • Tools from MCP apps work as expected through the Identity Gateway
  • Resources from MCP apps are accessible
  • Interactive UI experiences may not render correctly if the host can’t match the prefixed tool name to its declared UI resource

What to expect with unsupported capabilities

Section titled “What to expect with unsupported capabilities”

If an MCP server doesn’t support resources, the Identity Gateway handles this cleanly. The resources/list request returns an empty list for that server without generating errors.

If you connect an MCP app and its UI features don’t work as expected, this is likely due to the tool-naming limitation described in the previous section. The tools and resources themselves remain accessible individually.

Current AI models (such as Claude and Gemini) tend to access resources indirectly through tools rather than through explicit resources/read calls. For example, when asked to fetch a resource, the model typically invokes a tool like get_resource exposed by the MCP server rather than calling resources/read directly.

This behavior is evolving as both the MCP specification and AI model capabilities mature. The Identity Gateway supports both access patterns.