Standardize notification naming and fix formatting in MCP Apps spec
Updates the MCP Apps specification to consistently use the `ui/notifications/` prefix for all notification methods (e.g., `ui/notifications/sandbox-ready`, `ui/notifications/tool-result`). Also removes trailing whitespace, fixes tab/space inconsistencies, improves code formatting with proper backticks, and clarifies terminology throughout the document. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Jonathan Hefner
parent
535dae6a73
commit
86d72db632
1 changed files with 22 additions and 22 deletions
|
|
@ -1,8 +1,8 @@
|
|||
# SEP-1865: MCP Apps: Interactive User Interfaces for MCP
|
||||
|
||||
**Track:** Extensions
|
||||
**Authors:** Ido Salomon, Liad Yosef, Olivier Chafik, Jerome Swannack, Jonathan Hefner, Anton Pidkuiko, Nick Cooper, Bryan Ashley, Alexei Christakis
|
||||
**Status:** Draft
|
||||
**Track:** Extensions
|
||||
**Authors:** Ido Salomon, Liad Yosef, Olivier Chafik, Jerome Swannack, Jonathan Hefner, Anton Pidkuiko, Nick Cooper, Bryan Ashley, Alexei Christakis
|
||||
**Status:** Draft
|
||||
**Created:** 2025-11-21
|
||||
|
||||
## Abstract
|
||||
|
|
@ -86,7 +86,7 @@ The resource content is returned via `resources/read`:
|
|||
connect_domains?: string[]; // Origins for fetch/XHR/WebSocket
|
||||
resource_domains?: string[]; // Origins for images, scripts, etc
|
||||
};
|
||||
"domain"?: string;
|
||||
"domain"?: string;
|
||||
"prefersBorder"?: boolean;
|
||||
};
|
||||
};
|
||||
|
|
@ -293,14 +293,14 @@ If the Host is a web page, it MUST wrap the Guest UI and communicate with it thr
|
|||
|
||||
1. The Host and the Sandbox MUST have different origins.
|
||||
2. The Sandbox MUST have the following permissions: `allow-scripts`, `allow-same-origin`.
|
||||
3. The Sandbox MUST send a `ui/sandbox-ready` notification to the host when it’s ready to process an `ui/sandbox-resource-ready` notification.
|
||||
4. Once the Sandbox is ready, the Host MUST send the raw HTML resource to load in a `ui/sandbox-resource-ready` notification.
|
||||
3. The Sandbox MUST send a `ui/notifications/sandbox-ready` notification to the host when it’s ready to process an `ui/sandbox-resource-ready` notification.
|
||||
4. Once the Sandbox is ready, the Host MUST send the raw HTML resource to load in a `ui/notifications/sandbox-resource-ready` notification.
|
||||
5. The Sandbox MUST load the raw HTML of the Guest UI with CSP settings that:
|
||||
- Enforce the domains declared in `ui.csp` metadata
|
||||
- Prevent nested iframes (`frame-src 'none'`)
|
||||
- Block dangerous features (`object-src 'none'`, `base-uri 'self'`)
|
||||
- Apply restrictive defaults if no CSP metadata is provided
|
||||
6. The Sandbox MUST forward messages sent by the Host to the Guest UI, and vice versa, with any method that doesn’t start with `ui/sandbox-`. This includes lifecycle messages, e.g. `initialize` request & `initialized` notification both sent by the Guest UI. The Host MUST NOT send any request or notification to the Guest UI before it receives an `initialized` notification.
|
||||
6. The Sandbox MUST forward messages sent by the Host to the Guest UI, and vice versa, for any method that doesn’t start with `ui/notifications/sandbox-`. This includes lifecycle messages, e.g., `ui/initialize` request & `ui/notifications/initialized` notification both sent by the Guest UI. The Host MUST NOT send any request or notification to the Guest UI before it receives an `initialized` notification.
|
||||
7. The Sandbox SHOULD NOT create/send any requests to the Host or to the Guest UI (this would require synthesizing new request ids).
|
||||
8. The Host MAY forward any message from the Guest UI (coming via the Sandbox) to the MCP Apps server, for any method that doesn’t start with `ui/`. While the Host SHOULD ensure the Guest UI’s MCP connection is spec-compliant, it MAY decide to block some messages or subject them to further user approval.
|
||||
|
||||
|
|
@ -325,7 +325,7 @@ UI iframes can use the following subset of standard MCP protocol messages:
|
|||
- `ui/initialize` → `ui/notifications/initialized` - MCP-like handshake (replaces custom iframe-ready pattern in MCP-UI)
|
||||
- `ping` - Connection health check
|
||||
|
||||
### Host Context in McpUiInitializeResult
|
||||
### Host Context in `McpUiInitializeResult`
|
||||
|
||||
When the Guest UI sends an `ui/initialize` request to the Host, the Host SHOULD include UI-specific context in the `McpUiInitializeResult`’s `hostContext` field:
|
||||
|
||||
|
|
@ -486,7 +486,7 @@ Host SHOULD add the message to the conversation thread, preserving the specified
|
|||
}
|
||||
```
|
||||
|
||||
Host sends this notification after the Guest UI's initialize request completes, when tool arguments become available. This notification is sent at most once and is required before sending `ui/tool-result`.
|
||||
Host sends this notification after the Guest UI's initialize request completes, when tool arguments become available. This notification is sent at most once and is required before sending `ui/notifications/tool-result`.
|
||||
|
||||
`ui/notifications/tool-input-partial` - Host MAY send this notification zero or more times while the agent is streaming tool arguments, before `ui/notifications/tool-input` is sent.
|
||||
|
||||
|
|
@ -513,12 +513,12 @@ Guest UI behavior (optional):
|
|||
- MUST NOT rely on partial arguments for critical operations
|
||||
- SHOULD gracefully handle missing or changing fields between notifications
|
||||
|
||||
`ui/tool-result` - Tool execution result
|
||||
`ui/notifications/tool-result` - Tool execution result
|
||||
|
||||
```json
|
||||
{
|
||||
"jsonrpc": "2.0",
|
||||
"method": "ui/tool-result",
|
||||
"method": "ui/notifications/tool-result",
|
||||
"params": "CallToolResult" // Standard MCP type
|
||||
}
|
||||
```
|
||||
|
|
@ -603,22 +603,22 @@ Host MAY send this notification when any context field changes (e.g., theme togg
|
|||
|
||||
These messages are reserved for web-based hosts that implement the recommended double-iframe sandbox architecture:
|
||||
|
||||
`ui/sandbox-ready` - Sandbox proxy is ready
|
||||
`ui/notifications/sandbox-ready` (Sandbox Proxy → Host) - Sandbox proxy is ready
|
||||
|
||||
```json
|
||||
{
|
||||
"jsonrpc": "2.0",
|
||||
"method": "ui/sandbox-ready",
|
||||
"method": "ui/notifications/sandbox-ready",
|
||||
"params": {}
|
||||
}
|
||||
```
|
||||
|
||||
`ui/sandbox-resource-ready` - HTML resource ready to load
|
||||
`ui/notifications/sandbox-resource-ready` (Host → Sandbox Proxy) - HTML resource ready to load
|
||||
|
||||
```json
|
||||
{
|
||||
"jsonrpc": "2.0",
|
||||
"method": "ui/sandbox-resource-ready",
|
||||
"method": "ui/notifications/sandbox-resource-ready",
|
||||
"params": {
|
||||
"html": "string", // HTML content to load
|
||||
"sandbox": "string" // Optional override for inner iframe `sandbox` attribute
|
||||
|
|
@ -666,9 +666,9 @@ sequenceDiagram
|
|||
P -> P: Render inner iframe with HTML
|
||||
|
||||
end
|
||||
UI ->> H: initialize
|
||||
H -->> UI: InitializeResult (e.g., host-context, capabilities, etc.)
|
||||
UI ->> H: notifications/initialized
|
||||
UI ->> H: ui/initialize
|
||||
H -->> UI: McpUiInitializeResult (e.g., host-context, capabilities, etc.)
|
||||
UI ->> H: ui/notifications/initialized
|
||||
opt Stream Tool input to UI
|
||||
H -->> UI: ui/notifications/tool-input-partial (0..n)
|
||||
end
|
||||
|
|
@ -681,7 +681,7 @@ sequenceDiagram
|
|||
end
|
||||
```
|
||||
|
||||
Note: when the Guest UI is rendered inside a sandbox, the sandbox transparently passes events between the Guest UI and the Host (except for events that start with `sandbox-`)
|
||||
Note: when the Guest UI is rendered inside a sandbox, the sandbox transparently passes messages between the Guest UI and the Host, except for messages named `ui/notifications/sandbox-*`.
|
||||
|
||||
#### 5. Interactive Phase
|
||||
|
||||
|
|
@ -746,7 +746,7 @@ Note: Cleanup may be triggered at any point in the lifecycle following UI initia
|
|||
|
||||
Tool execution results are passed to the UI through two mechanisms:
|
||||
|
||||
#### 1. Tool Input (via ui/notifications/tool-input notification)
|
||||
#### 1. Tool Input (via `ui/notifications/tool-input` notification)
|
||||
|
||||
The original tool call arguments:
|
||||
|
||||
|
|
@ -761,7 +761,7 @@ params: {
|
|||
}
|
||||
```
|
||||
|
||||
#### 2. Tool Result (via ui/tool-result notification)
|
||||
#### 2. Tool Result (via `ui/notifications/tool-result` notification)
|
||||
|
||||
The tool's execution result:
|
||||
|
||||
|
|
@ -783,7 +783,7 @@ The tool's execution result:
|
|||
}
|
||||
|
||||
// UI receives:
|
||||
Notification: ui/tool-result
|
||||
Notification: ui/notifications/tool-result
|
||||
params: {
|
||||
content: [...], // Same as above
|
||||
structuredContent: { temperature: 72, ... },
|
||||
|
|
|
|||
Loading…
Reference in a new issue