You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a tool renders an MCP App (i.e. it carries _meta.ui.resourceUri), the host's app-view frame/header is labeled with the tool's name (e.g. get_report_app) instead of its human-facing title (e.g. "Open Dashboard"). Regular (non-app) tool calls render title correctly in the same host, so app views are the only surface where the raw programmatic identifier leaks to end users — and there is no _meta.ui field a server can set to label the view.
Evidence / how it reproduces
The server sets a top-level Tool.title and it is emitted on the wire. mcp.types.Tool has a title field, and the host renders it for ordinary tool-call chips — e.g. tools titled "Look Up Data", "Business Glossary", "Run Analysis" all display those titles.
The same server's app-rendering tool (declares _meta.ui.resourceUri, plus a top-level title) shows its frame header labeled with the tool name (get_report_app, underscores and all — no humanization), not its title.
Inspecting the Apps metadata schema (2026-01-26), the _meta.ui object for a tool has only: domain, prefersBorder, resourceUri, visibility. There is notitle / label / displayName for the view frame. So even if a host wanted to show a friendly frame label, the server has no field to supply one independently of the tool name.
Net: for app-rendering tools, the tool name is effectively user-facing chrome, but the only user-facing-name mechanism (Tool.title) is ignored for the frame, and there's no app-specific alternative.
Impact
End users (often non-technical business users) see programmatic identifiers like get_report_app in the app frame. There is no server-side way to present a clean name for an app view — renaming the tool name itself just swaps one snake_case identifier for another (the frame doesn't humanize it) and couples the user-facing label to the programmatic call name.
Proposal (either would resolve it)
Host behavior: when labeling an app-view frame, hosts SHOULD prefer the tool's title (falling back to name when title is absent) — mirroring how non-app tool chips already resolve the display name.
Spec: add an optional title (or label) to the tool _meta.ui object, letting a server name the view independently of the tool name — analogous to the proposed ui.homepage field (Add ui.homepage field for redirecting to the app's homepage #703). Hosts render _meta.ui.title ?? tool.title ?? tool.name.
Option 1 needs no schema change and immediately fixes the mismatch; Option 2 gives finer control (e.g. a view title distinct from the tool title).
Environment
MCP Apps spec 2026-01-26.
Host: claude.ai (web).
Server: FastMCP; the tool declares a top-level title (verified emitted on the wire) and it renders correctly for non-app tool calls in the same session.
Summary
When a tool renders an MCP App (i.e. it carries
_meta.ui.resourceUri), the host's app-view frame/header is labeled with the tool'sname(e.g.get_report_app) instead of its human-facingtitle(e.g. "Open Dashboard"). Regular (non-app) tool calls rendertitlecorrectly in the same host, so app views are the only surface where the raw programmatic identifier leaks to end users — and there is no_meta.uifield a server can set to label the view.Evidence / how it reproduces
Tool.titleand it is emitted on the wire.mcp.types.Toolhas atitlefield, and the host renders it for ordinary tool-call chips — e.g. tools titled "Look Up Data", "Business Glossary", "Run Analysis" all display those titles._meta.ui.resourceUri, plus a top-leveltitle) shows its frame header labeled with the toolname(get_report_app, underscores and all — no humanization), not itstitle.2026-01-26), the_meta.uiobject for a tool has only:domain,prefersBorder,resourceUri,visibility. There is notitle/label/displayNamefor the view frame. So even if a host wanted to show a friendly frame label, the server has no field to supply one independently of the tool name.Net: for app-rendering tools, the tool
nameis effectively user-facing chrome, but the only user-facing-name mechanism (Tool.title) is ignored for the frame, and there's no app-specific alternative.Impact
End users (often non-technical business users) see programmatic identifiers like
get_report_appin the app frame. There is no server-side way to present a clean name for an app view — renaming the toolnameitself just swaps one snake_case identifier for another (the frame doesn't humanize it) and couples the user-facing label to the programmatic call name.Proposal (either would resolve it)
title(falling back tonamewhentitleis absent) — mirroring how non-app tool chips already resolve the display name.title(orlabel) to the tool_meta.uiobject, letting a server name the view independently of the toolname— analogous to the proposedui.homepagefield (Add ui.homepage field for redirecting to the app's homepage #703). Hosts render_meta.ui.title ?? tool.title ?? tool.name.Option 1 needs no schema change and immediately fixes the mismatch; Option 2 gives finer control (e.g. a view title distinct from the tool title).
Environment
2026-01-26.title(verified emitted on the wire) and it renders correctly for non-app tool calls in the same session.Related
ui.homepagefield) — precedent for adding aui.*field to app metadata.