You picked an MCP client the way almost everyone does: it was the AI app already open on your screen. Then a server that works fine for a colleague returns nothing for you, or the interactive board they described arrives on your screen as a wall of plain text.
Nothing is broken. Search this term and you will be told, accurately, what an MCP client is - the access layer, one per server, created by the host - and then the page stops. Which leaves the only question you actually arrived with unanswered: I picked this client, so what did I just lose?
What is an MCP client?
An MCP client is the connection inside an AI application that speaks the Model Context Protocol to exactly one server. You do not install it separately. The host, meaning the AI app you run, creates one client per configured server, so a host holding six servers is running six clients side by side.
If the protocol itself is new, what MCP is and what a server does covers the vocabulary in a page. Everything below assumes it.
The part the definition pages get right
Three roles, and it is worth pinning them down once because the rest of this post depends on the third one.
The host is the application a person runs and looks at. It holds the model, the conversation, and the settings screen where servers get added. The client is a single protocol connection the host opens to one server: it performs the handshake, learns what that server offers, forwards calls, and carries results back. The server is the thing on the other end, exposing tools, resources and prompts over a transport.
So the host makes the decisions on your behalf: which transports it speaks, whether it can run an OAuth flow, whether it renders anything richer than text. The client is where those decisions become visible, because it is the only part of the chain that touches the server.
That is why "MCP is an open standard, so any client works with any server" is true about the wire format and misleading about the outcome. A standard fixes the shape of the messages. It does not oblige every client to implement every optional part of the spec, and the optional parts are where the interesting capabilities live.
Clients are not interchangeable
Four differences decide how much of a server you can reach. None of them are visible on the server's install page.
Transport. Local servers conventionally run as a subprocess over stdio; remote servers are HTTPS endpoints reached over Streamable HTTP. A client that only launches subprocesses cannot reach a hosted endpoint at all, and a client that only takes URLs cannot run the local package. The tradeoffs between the two shapes are their own subject, covered in running a local MCP server. A thin proxy can bridge the two by wrapping a stdio server so a remote client reaches it, which is the narrowest of the four routing shapes you can put in front of an MCP server.
Authentication. A remote server that identifies who is calling needs the client to complete an OAuth flow, hold a refresh token, and send it on every call. Clients that support pasted API keys but not OAuth reduce a per-person grant to one shared credential, which changes what the server can enforce and what its audit trail is worth afterwards. What you approve when you click Authorize unpacks that side.
Interactive views. The protocol allows a server to return a ui:// view the host renders inside the conversation, rather than only text. ChatGPT, Claude, Goose and VS Code have shipped support for these; many other clients have not. Same server, same call, and in one client you get a live surface while in another you get the text underneath it.
Sampling and elicitation. Two optional capabilities that run in the other direction: sampling lets a server ask the host's model to generate something mid-call, and elicitation lets a server pause and ask the user a question. Servers that lean on either degrade or refuse in clients that do not implement them.
How to tell what your own client supports
The clients you are most likely to be running are Claude's desktop and web apps, ChatGPT, Claude Code, Cursor, VS Code, Goose, and anything built directly on an MCP SDK. We are deliberately not publishing a yes-or-no grid across those names, because every cell in it is a product decision somebody revisits constantly, and a support matrix that is six weeks stale is worse than none at all: it reads authoritative and sends you debugging the wrong layer.
What is stable is the four axes, and each one can be settled in about a minute against the client in front of you.
| What varies | What you lose when your client lacks it | How to settle it yourself |
|---|---|---|
| Transport: remote HTTP | Hosted endpoints are unreachable; only local packages work | Look for a field that accepts a URL when adding a server, not just a command and args |
| Transport: local stdio | You cannot run a package like an npx server at all | Look for a config file taking command and args |
| OAuth to a remote server | Per-person identity collapses to one shared key, and the audit trail with it | Add a remote server and watch for a browser consent screen rather than a paste-your-key box |
Interactive ui:// views | The rendered surface silently degrades to its text answer | Call a tool you know ships an app. Text where a colleague sees a panel is your answer |
| Sampling and elicitation | Servers that need a mid-call model call, or a question back, refuse or degrade | Check the client's own docs. These are the least evenly implemented parts of the spec |
The rule underneath the table: the server offers, the client disposes. Check the client, not the server docs, when a capability is missing.
Check a real server against your own client
The fastest way to see the effect is to point your client at a server whose full surface you already know, then count what shows up. You can do that with ours without an account.
Run this exactly as written:
npx -y @aioproductoscom/mcp@latestWith no PRODUCTOS_TOKEN set, that starts our local stdio server in demo mode against a fully seeded showcase workspace called Brightline, exposing a read-only subset of the tools. Nothing to paste, nothing to cancel, no signup.
Now ask your client something ordinary in your own words: which features have the most customer requests behind them. A model with the connection working should come back with typed records carrying ids, not a paragraph of prose. That difference is precisely what makes the result something the model can chain another call onto.
Then compare that against the same product spine reached the other way. Our hosted endpoint is Streamable HTTP with OAuth 2.1 and PKCE, and serves 3 interactive ui:// MCP Apps alongside the full tool surface. Same product, same records, and how much of it your client can reach depends entirely on which of the four differences above it implements. If your client only does stdio you get the demo subset. If it does remote plus OAuth you get the identified, writable surface. If it renders ui:// views you get a board you can change a status on.
When the client choice does not matter
Now the case against everything above, because it is stronger than we would like.
If the server exposes plain text-returning tools over stdio, and you are one person on one laptop, your client choice is close to irrelevant. Every mainstream client can launch a subprocess and list its tools. The result you get back will differ because the model differs, not because the client does, and swapping clients to fix a bad answer is diagnosing the wrong layer.
A well-built server also makes the difference disappear on purpose. Our own ui:// apps are progressive enhancement: the text answer always comes first, so a client without app support loses nothing except the interactive surface on top. That is a deliberate design rule, and any server author who cares about reach should follow it. Which means the honest version of this post's thesis is narrower than the headline: the client decides what you get only when the server made its capability conditional on the client. Where the server degrades gracefully, you are not losing information, you are losing convenience.
There is also a cost to caring too much. Chasing one client's feature by adding servers has a real price in tool definitions loaded before your first message - the failure mode in too many MCP servers. Two servers you query weekly in a client you already use beats six in the client with the best feature matrix.
So the choice matters in exactly three situations: the server is remote and needs to know who is calling, the server's value is in an interactive view, or the server depends on sampling or elicitation to do its job. Outside those, pick the client with the model you like and move on.
How to pick, in one pass
Start from the server, not the client. Take the one server you most need working and settle three things about it: local or remote, per-person auth or one shared key, and whether any of its value arrives as something other than text. Those answers are your requirements. Check the client against them, and only then consider switching. Buying for a team adds a fourth: the client must be able to complete an OAuth flow, because that is what lets a server tell your people apart and keep a trail worth reading afterwards.
Once you know what your client can reach, the next question is what is worth connecting it to. See what each tool's own MCP server does, and where a single-tool MCP stops.