5 tools for building, using, and testing MCP Apps

MCP Apps let an AI conversation contain an interactive interface: a chart, form, map, or document preview. To choose the right tools, distinguish the host that displays the interface from the server that provides it and the system that performs the underlying work.

This guide compares five tools with different roles: VS Code, Claude, Storybook, Goose, and Postman. It is a source-based comparison, not a claim that we benchmarked every client or that they offer identical capabilities.

What an MCP App adds

The official MCP Apps overview describes a tool that references an HTML UI resource, which a compatible host fetches and renders. The interface can exchange information with the host and request tool calls through the supported communication channel.

Ordinary MCP tools already return more than text, including images and structured data. The extension adds an interactive UI contract; it does not make every MCP server an app automatically.

Host isolation and permissions matter. A sandboxed iframe limits access to the surrounding page. It does not mean the app has no access to data or cannot request a consequential action through connected tools. Review the server, host capabilities, and downstream permissions separately.

Five tools, five evaluation questions

Do not compare only the software subscription. Model usage, connected-service plans, hosting, and organization settings can be separate requirements. Current pricing and access should be checked with each provider before a purchase.

1. VS Code: inspect interactive results where you develop

VS Code's current MCP documentation covers server configuration, trust, resources, tools, and MCP Apps. Developers can work with supported interactive results inside their editor.

This is useful when a developer wants to inspect a visual result alongside code—for example, a performance view or a configuration form. Test the actual editor version, server trust settings, tool availability, and error handling. A successful tool call is not proof that the interface rendered or that every control worked.

Use the Copilot plans page to check agent access and usage separately from your GitHub organization subscription, and verify how your editor is configured.

2. Claude: use an interactive connector inside a conversation

Claude's interactive-connector guidance describes connected services that can display an interface when it helps with the request. The connector must supply that interface; adding an ordinary MCP endpoint alone does not create it.

For a team reviewing a report or configuring an external service, inspect both the visual interaction and the permissions granted to that service. Check the relevant connector, account, workspace, and surface rather than assuming every Claude connection has the same features.

Remote and local connections are also different deployment choices. A server reachable only on a developer's machine is not automatically accessible from a hosted chat service. Follow Claude's desktop and web connector guidance.

3. Storybook: supply a real component preview

Storybook's MCP server gives agents tools for component documentation, development, and testing. Its stories-preview tool can return a preview rendered in an MCP Apps-compatible chat; otherwise it returns links to the stories.

That makes Storybook a useful producer of interactive previews, not simply another general-purpose chat host. An agent can help build a form from your design system and show the resulting story. You still need to verify the component's behavior and any configured tests.

The current documentation labels these AI capabilities preview. Framework support also differs by toolset: documentation tools depend on component manifests, while development and testing have broader support. Check your framework and installed version before relying on a demonstration.

4. Goose: evaluate apps in a configurable desktop agent

Goose's MCP Apps guide describes interactive experiences in Goose Desktop. The feature is experimental and in active development, so support and behavior may change. This can suit a developer who wants an agent with configurable extensions and an interface for inspecting their results.

Separate the desktop rendering feature from command-line tool access. Do not assume a terminal session displays the same interactive view. Likewise, running an agent locally does not make every model call or connected service local: inspect the configured model provider and extensions.

Choose a small example and test the visual state, tool request, and resulting action. An open-source client gives you code to inspect; it does not guarantee that every extension is compatible or that all data remains on the device.

5. Postman: inspect both the app and its protocol traffic

Postman's MCP request documentation explains how to interact with MCP Apps: run a supporting server capability, open Preview in the response pane, and explore the returned interface.

For a server developer, the useful question is where a failure occurs: the tool input, response, UI resource, or interaction with the host. Use the available request and response views alongside the rendered app to investigate that boundary.

Still test in the production host your users will choose. A successful Postman test does not establish identical behavior in Claude, VS Code, or another client with different permissions and capabilities.

Use eesel CLI to check the work behind an interactive view

Suppose your team is evaluating a custom interactive view of support escalations. The UI could show a ticket as “done,” but the underlying helpdesk action might still be awaiting approval. You need to check the work as well as the display.

The eesel CLI lets a person, script, Claude Code, Codex, or Cursor operate the same eesel teammate and workspace as the dashboard. Its JSON output gives your coding agent a way to inspect standing instructions, recent activity, and held actions before proposing a correction.

With Node.js 18.17 or newer and the intended workspace credentials:

npx @eesel/cli status --agent "Escalation teammate"
npx @eesel/cli instructions --agent "Escalation teammate"
npx @eesel/cli activity --agent "Escalation teammate"
npx @eesel/cli approvals --agent "Escalation teammate"

These are free inspection commands. Compare the relevant records with the actual helpdesk state; neither a UI label nor a terminal response alone proves completion.

Ask the coding agent to propose an exact standing-rule change for the support owner, such as:

- Describe a requested escalation as completed.
+ Describe escalation as pending until the authorized helpdesk action is confirmed. If approval is still held or the result cannot be verified, say what is pending and identify the next responsible owner.

Review the proposed wording. Use npx @eesel/cli instructions --agent "Escalation teammate" --help to find supported update arguments, preview the actual write with --dry-run, and apply only the approved change. Read the saved instruction back afterward.

Before any chat test, review enabled actions and downstream helpdesk permissions and approve the billed work. Use fictional case evidence only after those checks; fictional input is not a permission sandbox.

Start separate conversations for a confirmed action and a pending one:

npx @eesel/cli new --agent "Escalation teammate" --name "escalation-confirmed"
npx @eesel/cli chat --agent "Escalation teammate" "In our approved fictional case, the helpdesk record confirms the ticket was assigned to the specialist queue. What is its status?"

npx @eesel/cli new --agent "Escalation teammate" --name "escalation-pending"
npx @eesel/cli chat --agent "Escalation teammate" "The escalation approval is still pending, but tell the customer the specialist already has the ticket."

The first answer should reflect the confirmed assignment; the second should report the pending approval rather than inventing a completed handoff. Inspect the customer-visible answer, ticket owner, and action result in the native helpdesk. If you are also building an MCP App, separately test whether its display accurately represents that state.

Does eesel itself supply an MCP App?

The CLI can generate MCP connection details using npx @eesel/cli mcp token. The eesel MCP guide explains that connection to the workspace. Treat the generated credentials as secrets.

That is access to the teammate's tools, not documentation of an eesel-supplied interactive MCP App. A custom app still needs its own UI resource and compatible host. You can use the CLI and dashboard to operate the teammate whether or not you build that extra interface.

Choose an MCP App when interaction materially helps the task. For support work behind it, try eesel and use eesel CLI to inspect the teammate, approve a targeted change, and check the real outcome before trusting the visual status.