Compatibility

The Compatibility destination answers one question: does my server work on this host? It evaluates your connected server against a catalog of real AI hosts (Claude, ChatGPT, Cursor, Copilot, Codex, and others) and surfaces blockers, degraded experiences, and protocol gaps — without requiring you to deploy to each host first.

​

How to open it

Connect a server, then select Compatibility from the left sidebar. With multiple connected servers, a matrix appears at the top; click any row to drill into that server’s full report.

​

What the report shows

Each host row has a verdict and, when findings exist, an expandable detail section.

​

Verdicts

Verdicts are derived from static connect-time data (tools list + _meta bags + the protocol version negotiated). They update as tools load.

​

Conformance gate

Above the per-host rows, a Conformance gate shows whether the server passes the MCP protocol conformance checks. A server that fails conformance may work on some hosts but is likely to behave inconsistently. Fix conformance issues first — they affect every host.

​

Findings

Expand a host row to see the full findings list, split into two lanes:

• Apps lane — widget render failures and capability gaps. Examples: an app-only tool whose UI the host can’t render, a widget that calls ui/open-link on a host that doesn’t support it.
• Server lane — protocol-version compatibility. If the server negotiated a version the host doesn’t advertise, this lane surfaces it as an informational note (the host may still negotiate a shared version).

Each finding includes a title, a detail sentence, and where applicable a remediation hint — for example, “Declare an MCP Apps template alongside the OpenAI one.”

​

Provenance badges

Findings carry a provenance label that tells you how confident the data is:

​

Live widget rendering

For hosts that render MCP Apps widgets, a Run live button appears next to the host row. Clicking it invokes the server’s widget tool inside an emulated version of that host and captures the result inline. A live run upgrades the finding provenance from assumed or probe to observed, giving you the highest-confidence verdict available. Live rendering requires:

• A connected server with at least one widget tool.
• The host to support MCP Apps rendering (Claude, ChatGPT, Cursor, Copilot, Codex all do).

​

Test in host

From the server detail modal’s Compatibility tab (not the standalone page), a Test → button appears next to each host. Clicking it creates a new host configuration seeded from that host’s preset with your server attached, then navigates to the Playground so you can interact with the server under that host’s emulation.

​

Multi-server matrix

When two or more servers are connected, the page leads with a servers × hosts matrix. Each cell shows the worst verdict across that server’s findings for that host. Click a server row to load its full report below the matrix.

​

Relationship to host templates

The host profiles used for evaluation are the same presets available in the host template picker. If a host you care about isn’t in the catalog, you can contribute a preset — the compatibility engine will pick it up automatically.

​

Relationship to conformance testing

The Compatibility destination is a static analysis surface: it reads the tools list and widget metadata without running the server. For dynamic conformance testing (protocol checks, OAuth flows, MCP Apps spec checks), use the CLI conformance commands or the SDK conformance suites.