Which AI hosts support which MCP features (October 2026)

When I lined up what each host documents, the list of things every host supports turned out to be very short: tools, on a remote server. Everything else a Model Context Protocol (MCP) server can offer, from prompts to MCP Apps, is documented for some hosts and not, or not yet, for others. So before you build on a feature, it helps to know which hosts will use it.

This is part 31 of my series on what an MCP server does under the 2026-07-28 specification, after part 30. My host rulebook lists the rules each host applies to your server; this part lists the features each one supports. The facts are as I read them in October 2026, most on 8 October; client support changes monthly, so check a host’s current docs before you depend on a feature.

In brief #

1. Tools on remote Hypertext Transfer Protocol (HTTP) servers are the only surface all seven hosts I compared support, so that’s where your essentials belong.
2. Prompts, resources, OAuth and MCP Apps are broad across chat and integrated development environment (IDE) hosts, but not universal. ChatGPT, for one, isn’t documented to consume prompts from remote servers.
3. Elicitation, server instructions and the stateless 2026-07-28 protocol are still growing: Claude Code is the only one of the seven hosts confirmed to use 2026-07-28.
4. Skills, Tasks and the two authorization extensions are emerging: the official matrix confirms Skills and the authorization extensions in a handful of clients at most, and doesn’t track Tasks.
5. My advice: keep your own matrix, built from telemetry, because requests tell you what each host negotiated.

The core features, host by host #

If a row is new to you, the series explains it: resources, prompts, server instructions, elicitation, the two transports (standard input and output, or stdio, for local servers and HTTP for remote ones), OAuth and the stateless protocol. Each cell comes from the host’s own documentation, the official extension support matrix or, where a cell says per a third-party source, a gateway vendor’s or an integrator’s documentation. Yes: documented as supported. Part: partial or limited. No: documented as not supported, or not applicable. ?: not confirmed in the sources I read, which isn’t the same as unsupported. Form and URL (Uniform Resource Locator) are elicitation’s two modes; DCR is Dynamic Client Registration and CIMD is Client ID Metadata Documents.

Notes on the table:

• Claude. Claude Desktop runs local servers, through Desktop Extensions or local configuration. Claude on the web and mobile connects to remote servers only, throughcustom connectors brokered from Anthropic’s cloud.
• Claude Code.Claude Code loads server instructions at session start alongside tool names when tool search is on, and truncates them at 2,048 characters by default. Its v2 MCP runtime, built on the MCP TypeScript software development kit (SDK) 2.0, asks servers whether they support 2026-07-28 and uses it where they do.
• ChatGPT and resources. OpenAI documents two cases in which ChatGPT reads resources:ui:// templatesto render an app’s interface , and Skills files, which areimported as a snapshot when a plugin is submitted. General-purpose MCP resources aren’t documented as a ChatGPT feature.
• ChatGPT and local servers. ChatGPT can’t reach a server on your localhost directly; it uses remote servers, through Developer Mode and apps. A local or private server, stdio included, can be connected through OpenAI’sSecure MCP Tunnel , or through an HTTPS (secure HTTP) forwarding service for testing. Public plugin submission still needs a public HTTPS endpoint.
• ChatGPT and prompts. OpenAI’s docs centre on tools and don’t describe prompt support, and agateway vendor’s ChatGPT page says ChatGPT doesn’t currently consume arbitrary prompts, roots, sampling or elicitation from a remote server. OpenAI’s own docs describe elicitation support, so that row follows OpenAI.
• Cursor. Its prompt, elicitation and OAuth cells come from the same vendor’sCursor guide and from integrator documentation.

Count the Yes cells in each row and you can see how quickly documented support thins after tools and remote servers:

The official extensions #

The official matrix is community-maintained. As of 8 October 2026 it confirmed this support for MCP Apps, the two authorization extensions and Skills; it doesn’t track Tasks.

| Client | MCP Apps | OAuth Client Credentials | Enterprise-Managed Auth | Skills |

|---|---|---|---|---|
| Claude (web) | Yes | ? | ? | ? | 

| Claude Desktop | Yes | ? | ? | ? | | Claude Code | No | ? | ? | ? | | ChatGPT | Yes | ? | ? | Part | | VS Code GitHub Copilot | Yes | ? | ? | ? | | Cursor | Yes | ? | ? | ? | | Microsoft 365 Copilot | Yes | ? | ? | ? | | Gemini CLI | ? | ? | ? | ? | | Goose | Yes | ? | ? | ? | | Postman | Yes | ? | ? | ? | | MCPJam | Yes | ? | ? | ? | | Archestra.AI | Yes | ? | Yes | ? | | PostHog Code | Yes | ? | ? | ? | | fast-agent | ? | ? | ? | Part | | MCP Inspector | ? | ? | ? | Part | | Apify mcpc CLI | ? | Yes | Yes | Yes |

Claude Code is marked No for MCP Apps because it’s a terminal application: it filters ui:// resources out of its resource suggestions rather than rendering them. Reading a user interface (UI) resource by its Uniform Resource Identifier (URI) still works.

The matrix and my testing landscape differ on the MCP Inspector. The matrix marks it Part for Skills and confirms nothing else; my review of 1 October 2026 records that Inspector version 2 covers Tasks, Skills and MCP Apps and debugs enterprise-managed authorization. The table reproduces the official matrix as it stands; for what the Inspector can exercise, the testing landscape has more detail.

What this means for your server #

The matrix sorts into four depths of support, from universal to emerging:

My rules of thumb follow from it; they’re advice, not requirements of the specification:

1. Put essential functionality in tools with good text output. Tools are the only universal surface (part 8 covers them).
2. Use prompts and resources as accelerators, not dependencies. Their rows in the core-features table have No, Part and ? cells, so a server that depends on them may not work everywhere.
3. Give every MCP App a text fallback. Terminal hosts and some IDEs won’t render it (part 25 shows how).
4. Give every elicitation a non-interactive path. Many hosts, and every unattended agent, can’t show a form.
5. Serve both protocol eras until your telemetry shows legacy traffic is gone (part 22 ).
6. Use Skills and Tasks where they’re negotiated, and fall back to prompts, instructions and synchronous tools elsewhere.

One more piece of advice: keep your own matrix for the hosts your users have, and build it from telemetry rather than documentation. Clients SHOULD send their clientInfo on every request (part 3), and each request declares its capabilities. So your observability data (part 20) tells you which extensions each host negotiated, more accurately than any published matrix, this one included.

Method and caveats #

• Built from my guide’s chapter on platform support, written against the 2026-07-28 specification, with host support as of 8 October 2026.
• The chart counts each row’s Yes cells in the core-features table, out of seven hosts, Cursor’s three third-party ones included and Part cells left out; no correction changed a Yes cell.
• Where OpenAI’s documentation and the gateway vendor’s page are more precise than my notes (ChatGPT’s local servers, resources and prompts, and the vendor’s list of what ChatGPT doesn’t consume), this article follows them and names the source.