App view frame is labeled with the tool `name`, not its `title` — no `_meta.ui` field to name a view

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'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 no title / 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)

1. 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.
2. 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 (#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.

Related

• #703 (ui.homepage field) — precedent for adding a ui.* field to app metadata.
• #672 (UI views not tied to specific tool calls) — adjacent to how a view is identified/labeled.

Start by reviewing the Apps metadata schema for 2026-01-26 and the host handling that distinguishes app-view frames from ordinary tool-call chips. Compare how Tool.title and Tool.name are resolved in both surfaces; done means the app frame has a defined friendly-label behavior or the schema documents the chosen _meta.ui field.