# MCP host coverage: will the server work in the AI apps your company uses?

October 24, 2026 · Part 4 of 4

![MCP host coverage. A blueprint drawing of a tall sheet with a column of check boxes, joined by fine lines to a ring of small blank nodes around it.](https://pournasserian.com/_astro/lead.r1asJDSz_8OShe.webp)

The question a buyer asks is rarely "is this server compliant?" It's "will it work in Copilot?", or in Claude, or in the editor the developers use. 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 is documented for some hosts and not, or not yet, for others. So the hosts your company runs decide what a server is worth to you.

This is part 4 of a short series for the people who buy, approve and govern MCP servers rather than build them, after [part 3's maturity map](https://pournasserian.com/writing/mcp-buyer-maturity-map). It draws on the same facts as [my series for builders](https://pournasserian.com/writing/mcp-2026-what-a-server-does), under the 2026-07-28 specification. The host facts are as I read them in October 2026, most on 8 October; client support changes monthly, so check a host's current documentation before you depend on a feature.

MCP is an open standard that lets AI applications discover and use external tools, data and prompt templates through one common interface. The AI application is the host, and each host decides which parts of the standard it uses.

## In brief

1. **Tools on a remote server are the only surface all seven hosts I compared support,** so a server's essentials have to live there.
2. **Each host adds rules of its own,** from the length of a tool name to the annotations every tool must carry, and the rules conflict with each other.
3. **Local and remote servers reach different hosts.** Claude on the web and mobile connects to remote servers only; ChatGPT can't reach a server on a laptop directly; VS Code runs local servers and can sandbox them.
4. **What to require as a result:** essentials in tools with text output, a text fallback for every interface, a path for every question that works unattended, both protocol eras served, and tests in three hosts.
5. **My advice: ask the vendor for its own support matrix, built from its telemetry,** because each request tells a server what the host negotiated.

## What every host supports, and what only some do

Here is the core of the matrix. Each cell comes from the host's own documentation, the [official client matrix](https://modelcontextprotocol.io/extensions/client-matrix) or, where it says so, a gateway vendor's or an integrator's documentation. Yes means documented as supported; Part means partial or limited; No means documented as not supported, or not applicable; and ? means not confirmed in the sources I read, which isn't the same as unsupported. Local servers run over standard input and output (stdio); remote ones over HTTP. Form and URL (Uniform Resource Locator) are the two ways a server can ask the user something.

| Feature | Claude (web, Desktop, mobile) | Claude Code | ChatGPT | VS Code (GitHub Copilot) | Cursor | Gemini CLI | Microsoft 365 Copilot |
|---|---|---|---|---|---|---|---|
| Tools | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Resources | Yes | Yes | Part | Yes | ? | Yes | ? |
| Prompts | Yes | Yes | No, per a third-party source | Yes | Yes, per a third-party source | Yes | ? |
| Server instructions | ? | Yes | Yes | ? | ? | ? | ? |
| Elicitation | ? | Yes, form and URL | Yes | ? | Yes, form and URL, per a third-party source | ? | ? |
| Local (stdio) servers | Part | Yes | Part | Yes | Yes | Yes | ? |
| Remote (HTTP) servers | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| OAuth for remote servers | Yes | Yes | Yes | ? | Yes, per a third-party source | Yes | ? |
| 2026-07-28 stateless protocol | ? | Yes | ? | ? | ? | ? | ? |

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

```mermaid
xychart-beta horizontal
  title "Hosts marked Yes for each core feature"
  x-axis ["Tools", "Remote HTTP servers", "Prompts", "OAuth for remote servers", "Resources", "Local stdio servers", "Elicitation", "Server instructions", "2026-07-28 stateless protocol"]
  y-axis "Hosts, of 7, marked Yes in the table" 0 --> 7
  bar [7, 7, 5, 5, 4, 4, 3, 2, 1]
```

Three cells deserve a note. ChatGPT reads resources in two documented cases, the templates of an app's interface and the files of a skill, and general-purpose resources aren't documented as a ChatGPT feature; a [gateway vendor's page](https://zuplo.com/docs/mcp-gateway/connect-clients/chatgpt.md) says it doesn't currently consume prompts from a remote server either. [Claude Code](https://code.claude.com/docs/en/mcp) is the only host of the seven confirmed to use the 2026-07-28 revision; it asks a server whether it supports it and uses it where it does. And server instructions, the paragraph a host may give the model about a server, are a host's choice to load, not a guarantee of the protocol.

The official extensions are thinner still. As of 8 October 2026 the official matrix confirms MCP Apps, the interactive interfaces, in Claude on the web and Desktop, ChatGPT, VS Code, Cursor and Microsoft 365 Copilot, and not in Claude Code, a terminal; Skills only partially, in ChatGPT among the mainstream hosts; and the two authorization extensions in no mainstream host. It doesn't track Tasks. [Part 3](https://pournasserian.com/writing/mcp-buyer-maturity-map) has the full table.

## The rules each host adds

A server that follows the specification can still be turned away by a host, because each host publishes rules of its own. I collected them on 1 October 2026 in [one MCP server, eight rulebooks](https://pournasserian.com/writing/what-ai-hosts-require-of-an-mcp-server); here are the ones a buyer meets first.

| Host | Rule |
|---|---|
| The specification | Tool names of 1 to 128 characters; input errors returned as tool errors, not protocol errors ([tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)) |
| The Claude connector directory | Tool names of 64 characters or fewer; a title and a read-only or destructive hint on every tool; read and write split into separate tools; no prompt-injection patterns ([review criteria](https://claude.com/docs/connectors/building/review-criteria)) |
| ChatGPT apps | All three hints, read-only, destructive and open-world, on every tool, whose absence is a common cause of rejection; non-promotional descriptions ([submission guidelines](https://developers.openai.com/apps-sdk/app-submission-guidelines)) |
| Codex | A startup timeout of 10 seconds and a tool timeout of 60 seconds by default |
| VS Code and Copilot | At most 128 tools enabled per chat request ([docs](https://code.visualstudio.com/docs/copilot/agents/agent-tools)) |
| Windsurf | 100 tools in total |
| Kiro | Names of at most 64 characters including the server prefix, with no hyphens or dots ([docs](https://kiro.dev/docs/mcp/)) |
| Gemini CLI | Names over 63 characters are truncated, and the server never finds out ([docs](https://geminicli.com/docs/tools/mcp-server/)) |

The rules disagree with each other. A name the specification allows is too long for the Claude directory and gets cut short by Gemini CLI; annotations the specification makes optional are mandatory for Claude and ChatGPT; and the hosts cap different things, tools per request here, seconds there, the size of a result elsewhere. A server built for one host can exceed another without changing a line, which is why the vendor's answer to "which hosts do you test in?" matters more than its answer to "are you compliant?".

## Local or remote

Where a server runs decides which hosts can reach it, and brings a governance question of its own.

- **Claude.** Claude Desktop runs local servers, through Desktop Extensions or local configuration. Claude on the web and mobile connects to remote servers only, through [custom connectors](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) brokered from Anthropic's cloud.
- **ChatGPT.** It can't reach a server on a laptop directly; it uses remote servers, through Developer Mode and apps. A local or private server can be connected through OpenAI's [Secure MCP Tunnel](https://developers.openai.com/api/docs/guides/secure-mcp-tunnels), and a public plugin submission still needs a public HTTPS endpoint.
- **VS Code, Cursor, Gemini CLI and Claude Code** run local servers; as of October 2026, [VS Code](https://code.visualstudio.com/docs/agent-customization/mcp-servers) can sandbox them on macOS and Linux, with filesystem and network allowlists.

A local server runs code on the user's machine, so it trades operational simplicity for supply-chain and trust concerns. [Part 2](https://pournasserian.com/writing/mcp-buyer-governance-checklist) has the policy I'd write for it: signed packages, minimal dependencies, secrets from the environment and the host's sandboxing where it exists. A remote server over HTTP is the one every host reaches, and the one that can use the authorization model of part 1.

## What to require because of it

The matrix sorts into four depths of support, from the one surface everyone has to the extensions a few clients negotiate:

```mermaid
flowchart TB
    t1["Universal: tools over remote HTTP"]
    t2["Broad: prompts, resources, OAuth,<br/>MCP Apps in chat and IDE hosts"]
    t3["Growing: elicitation, 2026-07-28 stateless protocol,<br/>server instructions with tool search"]
    t4["Emerging: Skills, Tasks extension,<br/>enterprise and client-credentials auth"]
    t1 --> t2 --> t3 --> t4
```

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

1. **The essentials live in tools with good text output.** Tools are the only universal surface.
2. **Prompts and resources are accelerators, not dependencies.** A server that needs them won't work everywhere.
3. **Every interface has a text fallback.** Terminal hosts and some editors won't render it, and under the MCP Apps extension a tool MUST return meaningful text content even when an interface is available.
4. **Every question to the user has a path that works unattended.** Many hosts, and every unattended agent, can't show a form.
5. **Both protocol eras are served** until the vendor's telemetry shows the older one gone from your hosts.
6. **Skills and Tasks are used where a host negotiates them,** with prompts, instructions and plain tools as the fallback elsewhere.

One more thing to ask for. Clients SHOULD send their name and version on every request, and each request declares the capabilities and extensions the host supports, so a server's observability data is a more accurate support matrix than any published one, this one included. A vendor who keeps that matrix can tell you, for the hosts your people use, exactly what works. A vendor who can't is guessing, and so are you.

## Method and caveats

- Built from my guide to MCP servers, written against the 2026-07-28 specification, and from my review of the hosts' own rules, reframed for the people who choose a server for the hosts they run. Host support is as of 8 October 2026 and the hosts' rules as of 1 October 2026.
- The chart counts each row's Yes cells in the core-features table, out of seven hosts, with the three cells marked per a third-party source included and the Part cells left out.
- Where OpenAI's documentation and the gateway vendor's page are more precise than my notes (ChatGPT's local servers, resources and prompts), this article follows them and names the source.
- Everything here is framed from the specification and the hosts' documentation. It describes no particular vendor, product or deployment.
