Claude Interactive Connectors: Why a Working MCP Demo May Not Ship

Claude’s November 10 interactive-connector update lets supported tools open beside a conversation or in full screen. Developers can build these experiences with MCP Apps, but a successful local demo does not establish that customers will receive every feature through a directory installation.

The announcement describes a rollout on web and desktop across plans as accounts receive the new Claude experience. Full-app support is a public preview for developers. End users need a connector that supports the capability; the update does not turn every existing integration into an embedded editor.

Choose the workflow before embedding the app

Consider a fictional issue-tracking product. The first useful integration might let a user open a selected issue, inspect its current state and ask Claude to prepare a status change. Embedding the entire product is optional; the essential question is whether the person and Claude can work on the same issue without losing context.

Write down three states before implementing: no issue selected, one issue selected and an issue that changed after selection. Decide what the UI and assistant should do in each state. An attractive embedded page still needs a reliable answer when someone asks to update the wrong or stale object.

Start with a narrow, reversible action and show its result. If changing a status is enough to validate the workflow, do not begin with bulk deletion, permissions administration or an unattended sequence of writes.

Remote servers and verified listings matter

The MCP Apps getting-started documentation distinguishes local examples from the newer capabilities. App tools, entry points and embedded websites require a remote-backed connector. For directory connectors, entry points and embedded websites require a Verified listing; a Community installation does not receive those two features even if a custom-connector test worked.

That creates two separate acceptance tests. First, prove the integration works technically in the supported development setup. Then test the actual distribution route intended for customers. A launch plan that only covers the first test can leave users with a different experience from the demo video.

For the issue tracker, keep a small matrix with custom connector, intended directory listing and organization access as separate rows. Record which features are visible for each. Mark a feature unavailable when the relevant requirement is unmet rather than treating it as an intermittent rendering bug.

Separate UI tools from the saved system of record

MCP Apps can give Claude tools that change the app’s on-screen state, such as a selection, while embedded websites can bring an existing editor into the app. The SDK supports registering tools and resources for multiple hosts, but host capabilities still need checking.

In the issue example, selecting a row and saving a new status are different operations. The first affects what the person sees; the second changes the issue that other teammates depend on. Make that distinction obvious in both tool names and visible feedback.

An implementation should return the specific issue identifier and resulting state after a successful save. If the save fails, preserve the user’s intended change and show the failure rather than rendering the optimistic state indefinitely. This is a recommended design check, not a claim about how a particular partner has implemented its connector.

Test the interruption as carefully as the happy path

Use a small checklist before a customer rollout:

• Open the tool without a selected object and ask for a change.
• Select one issue, switch to another and verify the intended target remains clear.
• Revoke access or use a test account without write permission, then confirm the UI reports the limit.
• Repeat the same action after a delayed response and check for duplicate changes.
• Close and reopen the app to confirm that the saved state matches the underlying product.

These checks are especially valuable when a conversation and an embedded editor both expose the same operation. Two interfaces do not remove the need for one authoritative record of what happened.

Diagnose a missing feature at the right layer

First check whether the account has the new Claude experience, then whether the connector supports the requested mode and the organization allows its tools. For developer tests, verify remote-server and listing requirements before investigating application code.

The getting-started guide also documents a host-specific sandbox domain derived from the server URL. A domain mismatch is a different failure from a missing directory entitlement. Preserve the actual error and reproduce it in the intended installation path; changing unrelated settings makes the problem harder to isolate.

Distribution is part of the integration test. The feature is ready for a customer when their account, installation route and permissions produce the experience you have described, not when a developer’s custom connector can display it once.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product details and practical lessons into clear stories that developers and buyers can use.

Book a 30-minute call.