Agent-Native Apps

Use /an <app> to open an Agent-Native app beside the conversation and keep the app's live UI and the agent's actions in the same workflow. The first argument is the Dispatch app id. For example, /an slides opens the Slides editor. After it opens, the user can sign in in that browser surface and ask for new decks or focused edits in ordinary language.

Open the app

For a known app, call Dispatch's open_app with an inline surface:

{
  "app": "slides",
  "path": "/",
  "embed": true,
  "chrome": "full"
}

The MCP App response is the preferred handoff for Claude, Claude Desktop, Claude Cowork, ChatGPT, ChatGPT desktop, Codex, and other compatible hosts. Keep the returned open link as the fallback for a host that cannot render MCP Apps inline. Do not claim that a browser opened unless the host rendered the inline surface or its browser tool confirmed the returned URL.

If the app name is missing or uncertain, call list_apps first and use the exact granted app id. If the requested app is not listed, explain that it must be granted in Dispatch's Agents access settings. Do not invent a URL, use a localhost URL, or route around the Dispatch grant.

Work in the opened app

Prefer direct app tools when the host exposes them. After opening an app, call list-host-webmcp-tools when available, then use run-host-webmcp-tool with the exact listed name and origin. Page-local tools reflect current app state and selection, so use view-screen before selection-dependent edits and read back writes.

You are the model doing the work: when the user asks for new content, a design, a deck, a form, a document, author it yourself and save it with the app's create/update tools. Never hand off authoring to the app's own agent when those tools exist, and never wait on an in-app question form; it answers back through that app's own chat, not to you.