@assistant-ui/mcp-docs-server 0.1.31 → 0.1.32

package/.docs/raw/docs/guides/chain-of-thought.mdx

@@ -1,6 +1,6 @@
 ---
-title: Chain of Thought
-description: Group reasoning and tool calls into a collapsible accordion UI.
+title: Chain of Thought UI
+description: Show AI reasoning steps and tool calls in a collapsible thinking accordion. Build chain-of-thought visualizations in React chat with assistant-ui.
 platforms: ["react"]
 ---
 
@@ -8,7 +8,7 @@ LLMs often produce reasoning steps and tool calls in succession. Chain of Though
 
 ## Overview
 
-When a model like OpenAI's `o4-mini` responds, it may emit a sequence of reasoning tokens and tool calls before producing its final text answer. Use `MessagePrimitive.GroupedParts` to group those adjacent reasoning and tool-call parts into a single collapsible "thinking" section.
+When a reasoning model responds, it may emit a sequence of reasoning tokens and tool calls before producing its final text answer. Use `MessagePrimitive.GroupedParts` to group those adjacent reasoning and tool-call parts into a single collapsible "thinking" section.
 
 <Callout type="info">
 The older `components.ChainOfThought` prop on `MessagePrimitive.Parts` and `components` prop on `ChainOfThoughtPrimitive.Parts` are legacy APIs. They still work for existing code, but new code should use `MessagePrimitive.GroupedParts`.
@@ -101,7 +101,7 @@ const AssistantMessage: FC = () => {
 
 ### Use a Reasoning Model
 
-Chain of Thought is most useful with models that produce reasoning tokens (e.g. OpenAI `o4-mini`). Here's an example backend route using the AI SDK:
+Chain of Thought is most useful with models that produce reasoning tokens. Here's an example backend route using the AI SDK:
 
 ```tsx title="app/api/chat/route.ts"
 import { openai } from "@ai-sdk/openai";
@@ -111,7 +111,7 @@ export async function POST(req: Request) {
   const { messages } = await req.json();
 
   const result = streamText({
-    model: openai("o4-mini"),
+    model: openai("gpt-5.4-mini"),
     messages: await convertToModelMessages(messages),
   });
 

package/.docs/raw/docs/guides/context-api.mdx

@@ -1,6 +1,6 @@
 ---
-title: Context API
-description: Read and update assistant state to build custom components.
+title: Assistant Context API
+description: Read and update assistant state to build custom React components in your chat UI — composable context API for thread, message, and runtime data via assistant-ui.
 platforms: ["react"]
 ---
 
@@ -258,8 +258,8 @@ useAuiEvent("composer.send", (event) => {
 });
 
 // Listen to thread events
-useAuiEvent("thread.runStart", (event) => {
-  console.log("Run started in thread:", event.threadId);
+useAuiEvent("thread.modelContextUpdate", (event) => {
+  console.log("Model context updated in thread:", event.threadId);
 });
 
 // Listen to all events of a type across all scopes

package/.docs/raw/docs/guides/dictation.mdx

@@ -1,6 +1,6 @@
 ---
-title: Speech-to-Text (Dictation)
-description: Let users speak into the composer using Web Speech API or a custom dictation adapter.
+title: Speech-to-Text Dictation
+description: Add voice dictation to your AI chat composer with the Web Speech API or a custom adapter. Speech-to-text in React, integrated through assistant-ui.
 platforms: ["react"]
 ---
 

package/.docs/raw/docs/guides/editing.mdx

@@ -1,6 +1,6 @@
 ---
 title: Message Editing
-description: Allow users to edit their messages with custom editor interfaces.
+description: Let users edit their messages and regenerate AI responses with custom editor interfaces. Edit-and-resubmit patterns for React chat via assistant-ui.
 platforms: ["react"]
 ---
 

package/.docs/raw/docs/guides/generative-ui.mdx

@@ -0,0 +1,142 @@
+---
+title: Generative UI
+description: Render agent-described React UI from a JSON spec with a consumer-provided component allowlist.
+---
+
+`MessagePrimitive.GenerativeUI` is a first-class primitive for rendering UI
+described by the agent at runtime as a JSON spec. Instead of hard-coding a
+component per tool, the agent emits a `generative-ui` message part containing
+a tree of components by name. assistant-ui resolves each name against a
+**consumer-provided allowlist** and renders the result.
+
+> The allowlist controls **which** components the agent may render: any name
+> not in it throws a typed `GenerativeUIRenderError` (no implicit fallback). It
+> does not constrain the props passed to those components; see [Security](#security).
+
+## Quick start
+
+### 1. Define your component allowlist
+
+```tsx title="components/gui.tsx"
+const Card = ({ title, children }) => (
+  <div className="rounded-xl border bg-card p-4 shadow-sm">
+    <div className="text-base font-semibold">{title}</div>
+    <div className="mt-2">{children}</div>
+  </div>
+);
+
+const Button = ({ label }) => (
+  <button className="rounded-md bg-primary px-3 py-1.5 text-primary-foreground">
+    {label}
+  </button>
+);
+
+export const componentsAllowlist = { Card, Button };
+```
+
+### 2. Wire the primitive into your message renderer
+
+```tsx title="components/assistant-message.tsx"
+import { MessagePrimitive } from "@assistant-ui/react";
+import { componentsAllowlist } from "./gui";
+
+export function AssistantMessage() {
+  return (
+    <MessagePrimitive.Parts
+      components={{
+        generativeUI: { components: componentsAllowlist },
+      }}
+    />
+  );
+}
+```
+
+You can also use the standalone primitive form:
+
+```tsx
+<MessagePrimitive.GenerativeUI components={componentsAllowlist} />
+```
+
+### 3. Have the agent emit a `generative-ui` part
+
+A `GenerativeUIMessagePart` carries a JSON spec:
+
+```ts
+{
+  type: "generative-ui",
+  spec: {
+    root: {
+      component: "Card",
+      props: { title: "Welcome" },
+      children: [
+        { component: "Button", props: { label: "Get started" } },
+      ],
+    },
+  },
+}
+```
+
+Bare strings act as inline text leaves.
+
+## Spec shape
+
+```ts
+type GenerativeUINode =
+  | string
+  | {
+      component: string;             // resolved against the allowlist
+      props?: Record<string, unknown>;
+      children?: GenerativeUINode[];
+      key?: string;                   // optional stable React key
+    };
+
+type GenerativeUISpec = {
+  root: GenerativeUINode | GenerativeUINode[];
+};
+```
+
+The spec is plain JSON — easy for any agent to emit, and easy to validate
+on the server before delivery.
+
+## Streaming
+
+The primitive is stream-friendly: any partial spec renders progressively. As
+new nodes arrive (filling in `children`, refining `props`), the rendered tree
+updates without reflows or lost local state for already-mounted children.
+
+## Security
+
+The allowlist is the boundary on **which** components render: a spec can only instantiate components you put in the registry, with no `eval` and no dynamic import (names are looked up in the registry and nothing else). An unknown name throws `GenerativeUIRenderError` or invokes your `Fallback`.
+
+It does **not** constrain the `props` the agent supplies. Spec props are spread directly onto your allowlisted components, so treat every allowlisted component as receiving untrusted input: never forward agent-supplied props into `dangerouslySetInnerHTML`, validate or reject `href` / `src` values (for example block `javascript:` URLs), and avoid passing spec props anywhere they become executable. The safest allowlisted components accept only primitive, display-oriented props.
+
+## Error handling
+
+Unknown component names throw `GenerativeUIRenderError` with a typed
+`componentName` field. Catch it with a React error boundary, or pass a
+`Fallback` component to opt into a soft-fail UX:
+
+```tsx
+<MessagePrimitive.GenerativeUI
+  components={componentsAllowlist}
+  Fallback={({ component }) => (
+    <span className="rounded bg-muted px-1.5 py-0.5 font-mono text-xs">
+      unknown component: {component}
+    </span>
+  )}
+/>
+```
+
+## Composing with other primitives
+
+`generative-ui` is a regular `MessagePart` type, so it composes cleanly with
+`MessagePrimitive.Parts`, `MessagePrimitive.PartByIndex`, and
+`MessagePrimitive.GroupedParts`. Render it alongside text, tool calls, and
+reasoning in the same message.
+
+## Why a primitive (not just a tool)
+
+Tool-call UI is great when the agent already invoked a known tool. Generative
+UI flips it: the agent _composes_ UI from a vocabulary you ship. Useful for
+forms, dashboards, status panels, multi-step flows, and anywhere the
+component library you want is broader than a single tool's render surface.

package/.docs/raw/docs/guides/image-generation.mdx

@@ -0,0 +1,74 @@
+---
+title: Image Generation
+description: Generate images in your backend and render them inline in an assistant-ui thread.
+---
+
+Image generation needs no dedicated primitive. Generate the image wherever you already run model calls (a route handler or a tool), store the result as an `ImageMessagePart`, and render it with the `@assistant-ui/ui` `Image` component.
+
+<Callout type="info">
+  This covers non-streaming generation, rendering, and actions. Streaming partial images and multi-image galleries are out of scope.
+</Callout>
+
+## Generate in your backend
+
+Call your provider from a server route. With the AI SDK that is `generateImage`; return the image as a data URI (or an object-store URL) plus any provider metadata you want to keep.
+
+```ts
+// app/api/image/route.ts
+import { generateImage } from "ai";
+import { openai } from "@ai-sdk/openai";
+
+export async function POST(req: Request) {
+  const { prompt } = await req.json();
+  const result = await generateImage({
+    model: openai.image("gpt-image-1"),
+    prompt,
+  });
+  const revisedPrompt = (
+    result.providerMetadata as
+      | Record<string, Record<string, unknown>>
+      | undefined
+  )?.openai?.revisedPrompt;
+  return Response.json({
+    image: `data:${result.image.mediaType};base64,${result.image.base64}`,
+    mimeType: result.image.mediaType,
+    ...(typeof revisedPrompt === "string" && { revisedPrompt }),
+  });
+}
+```
+
+The model provider is irrelevant to rendering; swap `openai.image(...)` for any AI SDK image model.
+
+## Store it as an `ImageMessagePart`
+
+An `ImageMessagePart` only needs `image` (a `data:` URI, an `https://` URL, or a `blob:` URL) plus an optional `filename`. Keep any provenance you want to display, the prompt, a revised prompt, a model id, in your own component state or in message metadata; the part itself stays minimal.
+
+```ts
+const part: ImageMessagePart = {
+  type: "image",
+  image: result.image, // data:, https://, or blob: URL
+};
+```
+
+## Render with the `Image` component
+
+The `Image` component in `@assistant-ui/ui` handles the render states for you:
+
+1. **Running** (`status.type === "running"`) renders a spinner.
+2. **Content filter** (`status.type === "incomplete"` with `reason: "content-filter"`) renders an error card with no `<img src>`.
+3. **Complete** renders a zoomable `<img>` with optional `Image.Actions`.
+
+`Image.Actions` provides download and copy buttons, plus a regenerate button when you pass an `onRegenerate` callback. Wire it to the same generation flow you used above; debounce, rate limiting, and confirmation are your call.
+
+```tsx
+import { Image } from "@assistant-ui/ui";
+
+<>
+  <Image {...imagePart} />
+  <Image.Actions part={imagePart} onRegenerate={() => regenerate(prompt)} />
+</>;
+```
+
+## Example
+
+A complete Next.js example (with a mock fallback when `OPENAI_API_KEY` is unset) lives in [`examples/with-image-generation`](https://github.com/assistant-ui/assistant-ui/tree/main/examples/with-image-generation).

package/.docs/raw/docs/guides/index.mdx

@@ -1,6 +1,6 @@
 ---
-title: Overview
-description: Practical patterns for building features with assistant-ui.
+title: Guides
+description: Practical recipes for building AI chat features in React with assistant-ui — attachments, branching, multi-agent, voice, slash commands, generative UI, and more.
 platforms: ["react"]
 ---
 

package/.docs/raw/docs/guides/interactables.mdx

@@ -1,6 +1,6 @@
 ---
-title: Interactables
-description: Persistent UI whose state can be read and updated by the AI assistant.
+title: Interactable Components
+description: Build persistent UI elements whose state the AI can read and update — copilot interactables in React with assistant-ui for forms, dashboards, and tools.
 platforms: ["react"]
 ---
 

package/.docs/raw/docs/guides/latex.mdx

@@ -1,6 +1,6 @@
 ---
-title: LaTeX
-description: Render mathematical expressions in chat messages using KaTeX.
+title: LaTeX in Chat Messages
+description: Render LaTeX math expressions in AI chat messages with KaTeX — drop-in equation support for React chat UIs built on assistant-ui.
 platforms: ["react"]
 ---
 

package/.docs/raw/docs/guides/mcp-apps.mdx

@@ -0,0 +1,231 @@
+---
+title: MCP Apps
+description: Render MCP App UI resources inline in chat. Native renderer for the Model Context Protocol Apps spec — sandboxed iframes, JSON-RPC bridge, AI SDK integration.
+platforms: ["react"]
+---
+
+[MCP Apps](https://apps.extensions.modelcontextprotocol.io/) lets a Model Context Protocol server ship a UI resource alongside a tool — a self-contained HTML widget that the chat host renders inline when the tool is called. assistant-ui ships a native renderer that mounts the widget in a sandboxed iframe via [`SafeContentFrame`](/safe-content-frame) and runs a JSON-RPC postMessage bridge so the widget can call tools, send messages, request a display mode, and read host context.
+
+## Overview
+
+When an MCP server attaches a `_meta.ui.resourceUri` (the [`text/html;profile=mcp-app`](https://apps.extensions.modelcontextprotocol.io/api/index.html) MIME) to a tool, AI SDK forwards that metadata through the message stream. assistant-ui's renderer picks it up off the `mcp` field on `ToolCallMessagePart`, fetches the resource through your backend route, and mounts it.
+
+The renderer only acts on URIs that start with `ui://` (per the MCP Apps spec). Tools whose `resourceUri` uses any other scheme are treated as non-MCP-Apps tools and fall through to your regular tool UI.
+
+The widget communicates back through a JSON-RPC bridge:
+
+- **widget → host requests**: `ui/initialize`, `tools/call`, `resources/read`, `resources/list`, `openLink`, `sendMessage`, `requestDisplayMode`, `updateModelContext`
+- **host → widget notifications**: tool input streaming, tool result, host context changes
+- **widget → host notifications**: initialized, size changed, log, error, request teardown
+
+Capability presence is determined at mount time by which handlers you provide. Unknown methods return JSON-RPC `-32601`; bad params return `-32602`.
+
+## Quick start
+
+The renderer talks to a backend route you expose — the MCP client lives server-side so credentials and transport stay out of the browser. The route receives `{ method, params }` POSTs and dispatches to your MCP client.
+
+### Client
+
+Compose `McpAppRenderer({...})` into your `Tools` resource. Provide `host.url` pointing at your route. Any tool-call part carrying `mcp.app` metadata renders the MCP App widget automatically.
+
+```tsx
+import {
+  useAui,
+  Tools,
+  McpAppRenderer,
+  McpAppsRemoteHost,
+} from "@assistant-ui/react";
+
+function MyAssistant() {
+  useAui({
+    tools: Tools({
+      toolkit: myToolkit,
+      mcpApp: McpAppRenderer({
+        host: McpAppsRemoteHost({ url: "/api/mcp-apps" }),
+        hostInfo: { name: "my-app", version: "1.0.0" },
+        hostContext: { theme: "light" },
+      }),
+    }),
+  });
+  // ...
+}
+```
+
+`McpAppsRemoteHost` is the default host strategy — it POSTs `{ method, params }` to your route. A different strategy (e.g. a client-side MCP client) can be plugged in by writing a custom resource that returns the same `McpAppsHost` shape (`{ loadResource, callTool, readResource, listResources }`).
+
+`openLink` is auto-wired to `window.open(url, "_blank", "noopener,noreferrer")`. `sendMessage` is auto-wired to append a user message to the current thread (accepts `string`, `{ prompt }`, `{ text }`, or `{ message }`).
+
+### Route handler
+
+The route accepts `POST` requests with `{ method, params }` JSON bodies. Dispatch by method name and return the result as JSON. Example for Next.js App Router:
+
+```ts
+// app/api/mcp-apps/route.ts
+import { experimental_createMCPClient } from "ai";
+
+let clientPromise: ReturnType<typeof experimental_createMCPClient> | undefined;
+const getClient = () => {
+  clientPromise ??= experimental_createMCPClient({
+    transport: { type: "sse", url: process.env.MCP_SERVER_URL! },
+  });
+  return clientPromise;
+};
+
+export async function POST(req: Request) {
+  const { method, params } = await req.json();
+  const client = await getClient();
+
+  switch (method) {
+    case "mcp-apps/read-resource": {
+      const { contents } = await client.readResource({ uri: params.uri });
+      const c = contents.find((x: { uri: string }) => x.uri === params.uri);
+      return Response.json({
+        uri: params.uri,
+        mimeType: "text/html;profile=mcp-app",
+        html: c?.text ?? "",
+      });
+    }
+    case "tools/call": {
+      const tools = await client.tools();
+      const tool = tools[params.name];
+      if (!tool?.execute) {
+        return Response.json({ error: "Tool not callable" }, { status: 400 });
+      }
+      return Response.json(
+        await tool.execute(params.arguments ?? {}, {
+          toolCallId: `mcp-apps-bridge-${crypto.randomUUID()}`,
+          messages: [],
+        }),
+      );
+    }
+    case "resources/read":
+      return Response.json(await client.readResource({ uri: params.uri }));
+    case "resources/list":
+      return Response.json(await client.listResources(params));
+    default:
+      return Response.json({ error: "Unsupported method" }, { status: 400 });
+  }
+}
+```
+
+The renderer POSTs four method names: `mcp-apps/read-resource`, `tools/call`, `resources/read`, `resources/list`. Reject anything else server-side and apply your own auth / rate limiting in the route.
+
+Per-name `setToolUI` registrations always win over the MCP fallback — you can still customize specific tools.
+
+## AI SDK integration
+
+`@assistant-ui/react-ai-sdk` forwards `callProviderMetadata.mcp.app` from AI SDK tool UI parts into `ToolCallMessagePart.mcp.app`. With AI SDK 5.x and an MCP-Apps-capable MCP server, no extra wiring is required on the part shape.
+
+The rich UI comes from the MCP server's metadata, not from the model, so the path is identical whichever provider drives the conversation. Running Claude is just a different `model:` in `streamText` (`anthropic("claude-sonnet-4-6")` via `@ai-sdk/anthropic`); the MCP server, `splitMcpAppTools`, and the renderer are unchanged. MCP Apps is an open standard in the MCP ecosystem (Claude is one of its hosts), so a standard MCP-Apps server renders out of the box. The bridge below is only needed for servers that use OpenAI's `openai/outputTemplate` convention, again independent of which model you run.
+
+On the chat route, use `splitMcpAppTools()` (from `@ai-sdk/mcp`) to keep app-only tools out of the model's view:
+
+```ts
+import { splitMcpAppTools } from "@ai-sdk/mcp";
+
+const tools = await client.listTools();
+const { modelVisible } = splitMcpAppTools(tools);
+
+const result = streamText({
+  model: openai("gpt-5.4-nano"),
+  tools: modelVisible.tools,
+  // ...
+});
+```
+
+### OpenAI Apps SDK servers
+
+[OpenAI Apps SDK](https://developers.openai.com/apps-sdk) servers carry the same `ui://` template under a different convention: the pointer is `_meta["openai/outputTemplate"]` on the tool definition (not `_meta.ui.resourceUri`), and the resource is served as `text/html+skybridge` rather than `text/html;profile=mcp-app`. `@ai-sdk/mcp` does not recognize `openai/outputTemplate`, so it never populates `callProviderMetadata.mcp.app` and the renderer stays idle.
+
+The renderer needs no change; you only have to surface the pointer. assistant-ui already reads `result._meta["ui/resourceUri"]` off tool results, so the smallest bridge is to copy the template onto the result by tool name. Build the map once from the tool listing, then stamp it inside each tool's `execute`:
+
+```ts
+import type { Tool } from "ai";
+
+// reuse the listTools() result from the AI SDK integration step above; no second round-trip
+const templateByTool = new Map(
+  tools.tools
+    .filter((t) => typeof t._meta?.["openai/outputTemplate"] === "string")
+    .map((t) => [t.name, t._meta["openai/outputTemplate"] as string]),
+);
+
+const withTemplateUri = (tool: Tool, name: string): Tool => {
+  const uri = templateByTool.get(name);
+  const exec = tool.execute;
+  if (!uri || !exec) return tool;
+  return {
+    ...tool,
+    execute: async (args, options) => {
+      const result = (await exec(args, options)) as { _meta?: Record<string, unknown> };
+      return { ...result, _meta: { ...result._meta, "ui/resourceUri": uri } };
+    },
+  } satisfies Tool;
+};
+```
+
+Wrap the AI SDK tool objects before handing them to `streamText`:
+
+```ts
+const aiTools = await client.tools();
+const wrappedTools = Object.fromEntries(
+  Object.entries(aiTools).map(([name, t]) => [name, withTemplateUri(t, name)]),
+);
+// pass wrappedTools to streamText
+```
+
+Your `mcp-apps/read-resource` handler reads the `ui://` resource as in the route example above. Set the response `mimeType` to the `text/html;profile=mcp-app` literal that `McpAppResource` expects and keep the server's HTML in `html`; don't forward the raw `text/html+skybridge` value, which the type rejects.
+
+The cleaner long-term fix is upstream: if `@ai-sdk/mcp`'s `getMCPAppToolMeta` also read `openai/outputTemplate`, then `callProviderMetadata.mcp.app` would populate automatically and this bridge would be unnecessary.
+
+## Bridge protocol
+
+The bridge implements the MCP UI JSON-RPC protocol over `window.postMessage`, filtered by both `event.source === frame.iframe.contentWindow` AND `event.origin === frame.origin` — the cross-origin domain `SafeContentFrame` issues per render. Messages from any other origin or window are dropped silently.
+
+### Widget → host requests
+
+| Method | Notes |
+|---|---|
+| `ui/initialize` | Returns `{ protocolVersion, host, hostContext, capabilities }`. Always supported. |
+| `tools/call` | Routed to `host.url` with method `tools/call`. Optional `handlers.allowedTools` allowlist. Invalid `arguments` shape → `-32602`. |
+| `resources/read` | Routed to `host.url` with method `resources/read`. |
+| `resources/list` | Routed to `host.url` with method `resources/list`. |
+| `openLink` | Requires `handlers.openLink`. Rejects non-`http(s)` URLs with `-32602`. |
+| `sendMessage` | Requires `handlers.sendMessage`. |
+| `requestDisplayMode` | Requires `handlers.requestDisplayMode`. Modes: `inline`, `fullscreen`, `pip`. |
+| `updateModelContext` | Requires `handlers.updateModelContext`. |
+
+When a handler isn't provided, the bridge returns JSON-RPC `-32601` (method not found) — which is also how `capabilities` is reported in the `ui/initialize` response.
+
+### Host → widget notifications
+
+- `notifications/tools/call/input` — sent whenever `part.args` (the streaming tool input) changes
+- `notifications/tools/call/result` — sent when the tool result lands (including error envelopes)
+- `notifications/host_context/changed` — sent when `hostContext` changes (e.g. user toggles theme)
+
+### Widget → host notifications
+
+`notifications/initialized`, `notifications/size_changed`, `notifications/log`, `notifications/error`, `notifications/request_teardown` — wire them via `handlers.onInitialized`, `onSizeChange`, `onLog`, `onError`, `onRequestTeardown` respectively.
+
+If the widget never sends `notifications/initialized` (broken or non-spec-compliant), the host flushes its queued notifications after a 5-second safety timeout so the iframe doesn't appear hung.
+
+## Sandboxing
+
+The iframe is built with [`SafeContentFrame`](/safe-content-frame), which serves each widget from a content-hashed cross-origin so the host page is not reachable by `same-origin` references. Default sandbox flags are `allow-same-origin allow-scripts`. Tune via the `sandbox` field on `McpAppRendererOptions`:
+
+```tsx
+McpAppRenderer({
+  // ...
+  sandbox: {
+    sandbox: ["allow-forms", "allow-popups"],
+    enableBrowserCaching: true,
+    className: "my-mcp-app",
+  },
+});
+```
+
+## Security notes
+
+- Widgets run cross-origin in a sandboxed iframe. The bridge filters incoming messages by both source window and origin.
+- The host route is your auth boundary — apply session checks, rate limiting, and per-tool allowlists there. The renderer trusts whatever the route returns.
+- `openLink` rejects non-`http(s)` URLs at the bridge layer, but your `openLink` handler should still treat the URL as untrusted (e.g. always use `noopener,noreferrer`).
+- Keep `host` and `handlers` references stable across renders (e.g. module-scope constants or `useMemo`); an unstable identity will tear down and refetch the widget on every parent re-render.

package/.docs/raw/docs/guides/mentions.mdx

@@ -1,6 +1,6 @@
 ---
-title: Mentions
-description: Let users @-mention tools or custom items in the composer to guide the LLM.
+title: Mentions in Chat
+description: Let users @-mention tools or custom items in the AI chat composer to guide the LLM. Mention picker built into assistant-ui's React composer.
 platforms: ["react"]
 ---
 

package/.docs/raw/docs/guides/message-timing.mdx

@@ -1,6 +1,6 @@
 ---
-title: Message Timing
-description: Display stream timing metadata like duration, tokens per second, and time to first token.
+title: Message Timing & Token Stats
+description: Display stream metadata in AI chat — generation duration, tokens per second, and time to first token, rendered via assistant-ui's React components.
 platforms: ["react"]
 ---
 
@@ -76,9 +76,9 @@ const AssistantMessage: FC = () => {
 | AI SDK (`useChatRuntime`) | Yes | Automatic via client-side tracking |
 | Local (`useLocalRuntime`) | Yes | Pass timing in `ChatModelRunResult.metadata` |
 | ExternalStore | Yes | Pass timing in `ThreadMessageLike.metadata` |
-| LangGraph | No | Not yet implemented |
-| AG-UI | No | Not yet implemented |
-| OpenCode | No | Not yet implemented |
+| LangGraph | Yes | Automatic via client-side tracking |
+| AG-UI | Yes | Automatic via client-side tracking |
+| OpenCode | Yes | Automatic via client-side tracking |
 
 ### Data Stream
 
@@ -163,6 +163,39 @@ const message: ThreadMessageLike = {
 };
 ```
 
+### LangGraph (`useLangGraphRuntime`)
+
+Timing is tracked automatically on the client side by observing streaming state transitions and `LangChainMessage` content changes. No setup required.
+
+```tsx
+import { useLangGraphRuntime } from "@assistant-ui/react-langgraph";
+
+const runtime = useLangGraphRuntime({ stream: myStream });
+// useMessageTiming() works out of the box
+```
+
+### AG-UI (`useAgUiThreadRuntime`)
+
+Timing is tracked automatically on the client side by the AG-UI run aggregator. Each emitted message includes timing metadata computed from stream chunk observations.
+
+```tsx
+import { useAgUiThreadRuntime } from "@assistant-ui/react-ag-ui";
+
+const runtime = useAgUiThreadRuntime({ runtimeUrl: "..." });
+// useMessageTiming() works out of the box
+```
+
+### OpenCode (`useOpenCodeRuntime`)
+
+Timing is tracked automatically on the client side by observing `OpenCodeThreadState` transitions and assistant message content deltas. No setup required.
+
+```tsx
+import { useOpenCodeRuntime } from "@assistant-ui/react-opencode";
+
+const runtime = useOpenCodeRuntime();
+// useMessageTiming() works out of the box
+```
+
 ## API Reference
 
 ### `useMessageTiming()`

package/.docs/raw/docs/guides/multi-agent.mdx

@@ -1,6 +1,6 @@
 ---
-title: Multi-Agent
-description: Render sub-agent conversations inside tool call UIs.
+title: Multi-Agent Chat UI
+description: Render sub-agent conversations and handoffs inside tool calls. Build supervisor and multi-agent patterns in a React chat UI with assistant-ui.
 platforms: ["react"]
 ---
 

package/.docs/raw/docs/guides/quoting.mdx

@@ -1,6 +1,6 @@
 ---
 title: Quote Selected Text
-description: Let users select and quote text from messages. Full guide including backend handling and programmatic API.
+description: Let users select text from AI messages and quote it back into the composer. Full quoting flow with backend handling and programmatic API in assistant-ui.
 platforms: ["react"]
 ---