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
{{ message }}
Repository navigation
Commit f94cb38
Browse filesBrowse the repository at this point in the historyBrowse files
View (App) <--PostMessageTransport--> Host (AppBridge) <--MCP Client--> MCP Server
73
+
View (App/Client) <--PostMessageTransport--> Host (AppBridge/Server) <--separate MCP Client--> MCP Server
74
74
```
75
75
76
76
1. Host creates iframe with view HTML
77
77
2. View creates `App` instance and calls `connect()` with `PostMessageTransport`
78
-
3. View sends `ui/initialize`request, receives host capabilities and context
78
+
3. View and Host complete the temporary inner base MCP handshake, then the View sends `ui/initialize`and receives authoritative Apps capabilities and context
79
79
4. Host sends `sendToolInput()` with tool arguments after initialization
80
80
5. View can call server tools via `app.callServerTool()` or send messages via `app.sendMessage()`
81
81
6. Host sends `sendToolResult()` when tool execution completes
Copy file name to clipboardExpand all lines: docs/overview.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -56,7 +56,11 @@ flowchart LR
56
56
-**Host** — The chat client (e.g., Claude Desktop) that connects to servers, embeds Views in iframes, and proxies communication between them.
57
57
-**View** — The UI running inside a sandboxed iframe. It receives tool data from the Host and can call server tools or send messages back to the chat.
58
58
59
-
The View acts as an MCP client, the Host acts as a proxy, and the Server is a standard MCP server.
59
+
The View's `App` subclasses the base MCP SDK `Client`. The Host's `AppBridge`
60
+
subclasses the base MCP SDK `Server` for the inner iframe channel, while a
61
+
separate outer `Client` connects the Host to the actual MCP Server. Keeping
62
+
those two connections separate prevents iframe negotiation and capabilities
63
+
from leaking into the server connection.
60
64
61
65
## Lifecycle
62
66
@@ -93,7 +97,7 @@ sequenceDiagram
93
97
```
94
98
95
99
1.**Discovery** — The Host learns about tools and their UI resources when connecting to the server.
96
-
2.**Initialization** — When a UI tool is called, the Host renders the iframe. The View sends `ui/initialize` and receives host context (theme, capabilities, container dimensions). This handshake ensures the View is ready before receiving data.
100
+
2.**Initialization** — When a UI tool is called, the Host renders the iframe. The SDK first completes its temporary inner base MCP handshake, then the View sends `ui/initialize` and receives host context (theme, capabilities, container dimensions). `ui/initialize` remains authoritative for Apps capabilities and identity, and `ui/notifications/initialized` remains the public View-ready signal.
97
101
3.**Data delivery** — The Host sends tool arguments and, once available, tool results to the View. Results include both `content` (text for the model's context) and optionally `structuredContent` (data optimized for UI rendering). This separation lets servers provide rich data to the UI without bloating the model's context.
98
102
4.**Interactive phase** — The user interacts with the View. The View can call tools, send messages, or update context.
99
103
5.**Teardown** — Before unmounting, the Host notifies the View so it can save state or release resources.
0 commit comments