Choosing your AI host: the five questions that matter

The five questions, and why the order matters

A host is the app that runs the model and pays for the tokens. Claude, Claude Code, Cursor, ChatGPT, Codex and Hermes are hosts. Most write-ups compare them on feel: which one is nicer to type into, which one gets the code right. If you plan to install tools into the host over MCP, feel is the last thing to test. Four of the five gates below are answered by the vendor's own docs plus one command. Every host claim on this page comes from the vendor page listed in the sources at the end, read on 19 September 2026. Where a page did not say, this article says we do not know.

Ask them in this order. Each answer makes the next one cheaper to test. A host that cannot hold a remote MCP server with OAuth is out at gate one, and its seat price stops being your problem. A host that clears gate one but opens the call from the vendor's cloud changes what your network team has to sign off, which changes who is able to install it, which changes the number of seats you are really buying.

The five are not equal. The first two cut hosts from the list. The third and fourth decide if the setup lives past the first week with other people in it. The fifth decides the bill. Work down the list in that order and you cut the field before you pay for a trial.

• 1. Can it add a remote MCP server over HTTP, with OAuth, and no proxy you have to write and run?
• 2. Who sees your data: which machine opens the call to your server, and what does the vendor say about training on what you type?
• 3. Does it keep state between sessions, and which state: the server list, the token, or the chat?
• 4. Can a person who never opens a terminal finish the setup, or does it end in a JSON file?
• 5. What does a seat cost at your real head count, on top of the model tokens the host already bills?

Question 1: can the host add a remote MCP server with OAuth?

Support for MCP is three features wearing one badge. A host can start a local process over stdio, which is a command on your own machine. It can open a streamable HTTP call to a URL. It can also hand the job to the vendor's backend, which opens the call for you. The three are not swaps for each other. A server you buy or build will work with one of them and fail on the others.

The server half of this is a spec, so you can hold a vendor to it. The MCP auth spec says a guarded server acts as an OAuth 2.1 resource server. It says the server MUST publish Protected Resource Metadata (RFC 9728), so a client can find the auth server on its own. It says the client MUST use Resource Indicators (RFC 8707), so the token it gets is bound to your server and cannot be replayed at some other one. It says both sides SHOULD do Dynamic Client Registration (RFC 7591), so that no human has to paste a client ID.

What you are testing is the client half. Anthropic's Claude Code MCP page gives a one line add for an HTTP server, and a sign-in through a slash command in the session or a login command in the shell. OpenAI's MCP page for Codex lists streamable HTTP servers with bearer tokens or OAuth, and names both Client ID Metadata Documents and Dynamic Client Registration. Cursor's MCP page lists stdio, SSE and streamable HTTP, and its OAuth path wants a static client ID, with an optional secret, against fixed redirect URLs. Those are three different stories about the same word. The third one means a server that only does dynamic sign-up needs a client made by hand first.

Ten minutes: open the host's MCP docs and search for the word http. If every example is a command with flags, the host starts local processes, and your remote server will need a bridge on each machine. Then search for oauth. If the only path is a token you paste into a header, the host can reach your server, but the key is now a long lived secret in a file, and rotating it is your job from then on.

• Local process over stdio: the host starts a command. Fine for a tool that reads your disk, no use for a server a team shares.
• Streamable HTTP from your own machine: the host opens the call. Your firewall sees your laptop.
• Brokered by the vendor: the vendor's servers open the call. Your firewall sees the vendor. That is question 2.
• A token in a header: it works today, and it is the thing you will forget to rotate next year.

Question 2: who sees your data, and which machine opens the call?

There are two data questions here and only the loud one gets asked. The loud one is training: does the vendor learn from what you type. The quiet one is routing: which IP shows up at your MCP server, and so which network line the setup has to cross.

Anthropic answers the routing one in plain words. Its support page for custom connectors says that when you add one, Claude reaches your remote MCP server from Anthropic's cloud rather than from your own device, and that this holds for the web app, the desktop app, Cowork and the phone apps. A server behind your VPN will not connect, even though you can open it yourself, and the fix it names is to allow the vendor's IP ranges through your firewall. The same page says local MCP servers set up in the desktop config file are a separate path that does use your own network, and that this path is not there in Cowork or on the web.

That one fact reorders a buying process. If your server is internal, a brokered host turns the setup into a firewall ticket, and that ticket is not yours to close. If your server is public and sits behind OAuth, the brokered path is usually the better one, because it gives you the same tools on a phone that you get on a laptop, and a local setup cannot do that.

On training, read the page the vendor wrote for the plan you are on, not a summary of it. Anthropic's privacy page for the consumer plans frames model improvement as a thing you switch on, with a setting to change your mind, and says in its first lines that it covers the consumer plans and not the commercial ones. Cursor's security page says that with Privacy Mode on, it will not train on your data, and that new team members inherit the team setting. Both of those are about the host. Neither one says a word about the MCP server you install into it, which has its own terms and its own logs.

Ten minutes: point the host at a server you own, even a stub that logs the call and returns a 401, and read the log. One line tells you the source IP, the user agent, and whether the host tries again after a failure. No doc page beats that.

• Read the page for your plan. The same vendor has one set of terms for consumers and another for work accounts.
• Log the first call. Source IP plus user agent answers the routing question in one line of text.
• Ask what the tool vendor keeps. The host's terms do not bind the server on the other end of the call.
• If your server is internal, get the vendor's IP ranges before you promise a date to anyone.

Question 3: does the host keep state between sessions?

State is three things and hosts treat them one way each. There is the server list, which is config. There is the token you get at the end of the OAuth flow. There is the chat itself, meaning what the model still knows about your work when you come back on Monday.

Config is the easy one to check, because it is a file you can open. Claude Code names three scopes: a local one, a user one that follows you across projects, and a project one in a file at the root of the repo that you commit and share. Codex keeps its MCP config in one file per user, with a per project file for trusted folders, and its docs say the CLI, the IDE add-on and the desktop app all read the same file, so you can move between them without setting it up again. Cursor has the same split: one file in the project, one in your home folder.

A shared file in git is what makes a team setup repeatable, and it is also how secrets get out. A shared file is a good thing when the server uses OAuth, because there is nothing secret in it. The same file with a token in a header puts a key in your repo history, where it stays after you delete the line.

Chat state is the one people mean when they ask, and it is the one this page will not rank. Two products can put the word memory on two different things, and the same product can put it on two plans. Read the vendor page for the plan you hold, then test it rather than trust it.

Ten minutes: add the server, run one tool, quit the host all the way, and open it again. Check three things in order. Is the server still listed. Does the first call go through with no new consent screen, which tells you the refresh token was kept. Does the model still know a fact you gave it yesterday, which tells you whether chat state is real or whether you are the memory.

• Server still listed after a restart: the config is on disk or in your account. Expect this from every host here.
• No second consent screen: the host kept a refresh token. Ask where it went, and whether it is in the OS keychain.
• The model recalls yesterday: chat state is real. Test with a fact only you could have given it, not one it could guess.
• Two machines, one account: set it up on a second device and see what carries over. Brokered hosts win this one.

Question 4: can a non-developer install it?

Ask this one out loud. It decides whether your setup reaches five people or fifty, and it is easy to skip when the person choosing lives in a terminal.

Two of the six are terminal tools. Claude Code and the Codex CLI want a shell, and their MCP setup is a command or a file you edit. Cursor is a code editor, and its MCP setup is a JSON file in a folder, with a panel for switching servers on and off. Those are good surfaces for engineers and a wall for the rest of the company.

The click paths are written down too, and they carry a gate of their own. Anthropic's support page on custom connectors says they are there on Claude, Cowork and Claude Desktop for the Free, Pro, Max, Team and Enterprise plans, that a Free user gets one custom connector, and that on Team and Enterprise only an Owner can add one to the org, after which each member connects to it on their own account. OpenAI's MCP page describes an Add server dialog in the ChatGPT desktop app and in the IDE add-on: a name, a choice of stdio or streamable HTTP, and an Authenticate button for the servers that need it.

ChatGPT on the web is the one that catches people out. The same OpenAI page says ChatGPT on the web can use remote MCP tools that come from installed plugins, that it does not read the local Codex config file, and that admins decide which plugins and tools are there at all. If your plan was to send a colleague a URL to paste into the web app, read that page before you promise it.

Ten minutes: send the setup steps to one person who does not write code, say nothing else, and watch. Count how many times they come back with a question. More than once and you are the setup process, and you will be the setup process for every new hire after them.

Question 5: what does a seat cost at your team size?

This page does not print per seat prices. They move, they differ by plan and by contract, and a price copied into an article is wrong within a quarter. The shape of the bill does not move, and the shape is the part people get wrong.

You are buying two things that arrive as one number. There is the seat, which is what the host charges per person per month. There is the model use, which is either folded into the seat up to some limit, billed on its own against an API key, or both at once on two surfaces of the same product. Move work out of chat and into an agent loop and the seat count can stay flat while the model bill climbs, because a loop sends the context again on every turn.

Write the sum down before you talk to anyone. Seats times price, plus the model spend you have now, plus the model spend the new work adds, minus the tool you stop paying for, if you stop paying for one. The third term is the one to measure, because it is the only one you cannot read off an invoice you already have.

Ten minutes: open the vendor's pricing page for the tier you would really buy, find the two things that are metered, and write the seat price and the metered unit on one line. Then count the people who must act inside the host, and the people who only read what comes out. The second group does not need a seat.

• Count actors, not head count. A person who reads the output does not need a seat in the host.
• Ask what happens at the included limit: a hard stop, a slower model, or an overage. Each one is a different risk.
• Check whether the admin controls sit on a higher tier than the seats do. Org-wide approval of connectors often does.
• Price the exit. Config in files you own makes a move a copy. Config in an account makes it a migration.

The ten-minute probe: what a compliant MCP server answers

You do not need a host to test the server half of this, and you do not need an account. A compliant remote MCP server answers an unauthenticated call with a 401 and a WWW-Authenticate header pointing at its own metadata. Run this before you spend a seat. The example below uses Notion's public endpoint, which appears in Claude Code's own MCP docs.

Step 1. Ask for the tool list with no token. The command is curl -s -i -X POST https://mcp.notion.com/mcp -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'.

What you see: HTTP/2 401, and the header www-authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.notion.com/.well-known/oauth-protected-resource/mcp", error="invalid_token". The shape of that header varies. We ran the same call against Stripe's endpoint and got the same pointer back with no realm and no quotes around it. The part that matters is resource_metadata, because that is the link the spec requires and the link the host will follow.

Step 2. Fetch the URL from that header. You get a small JSON document with the resource, an authorization_servers list, and scopes_supported. If the resource value does not match the URL you just called, character for character, a host that checks the audience of its token will refuse to use it, and you have found the bug before it became a support thread.

Step 3. Fetch /.well-known/oauth-authorization-server on the auth server named in step 2. Look for three fields. S256 in code_challenge_methods_supported, which is PKCE. A registration_endpoint, if you want dynamic sign-up to work. And resource_indicators_supported. A server with no S256 leaves an intercepted code usable on its own.

Step 4. Now add the server in the host and watch the browser window it opens. The domain in the address bar during consent should be the auth server you read in step 2. If it is some other domain, stop and find out why before anyone signs in.

Four minutes per server once the commands are in your shell history. It tells you more than any comparison table, this one included. It also works against a server you are building, which is the cheapest way to learn that your metadata document has the wrong resource URL in it.

What each host documents today, and what we could not check

The table at the end of this page holds only claims the vendor writes down, and the page each claim came from is in the sources. It does not score anything. Two hosts with the same cell can feel nothing alike in daily use, and that gap is not a thing an article can measure for you.

One honest hole: Hermes. We could not find vendor docs on its MCP behaviour that we were willing to cite, so this page does not state what it supports. If Hermes is on your list, ask for the transport list and the OAuth behaviour in writing, then run the probe above from inside it.

A second hole: every cell is what the page said on the day we read it. Host support for MCP has moved in both directions: Claude Code's own page now marks the SSE transport deprecated. Re-read the vendor page rather than trust a cell in a table, ours included.

Failure modes when you install a server into a host

These are the failures that look like a broken server and are really a host mismatch. Each has a symptom you can name before you file the bug against the wrong party.

• The server never connects and the host shows no error. Cause: the host opens the call from the vendor's cloud and your server is on a private network. Proof: zero entries in your server's access log.
• Consent works, then every call returns a 401. Cause: the token is bound to a resource that is not the URL the host calls, usually a trailing path that differs by one character.
• It works for you and fails for a colleague. Cause: plan gating. On Team and Enterprise plans an Owner has to add the connector to the org before members can connect to it.
• Tools show up, then vanish after a restart. Cause: the server was added in a project scope and the other person opened a different folder.
• The model ignores a tool that is right there in the list. Cause: a name and a description that read like three other tools. That is a server problem, and no host setting fixes it.
• It works in the terminal client and fails in the web client of the same vendor. Cause: the two surfaces read different config, which the vendor documents and nobody reads.

The tradeoff: one host for everyone, or one host per job

Standardising on one host is cheaper to run and easier to support, and it costs you the thing each host is good at. A terminal host is better on code because it sits in the repo. A brokered host is better at reaching a person on a phone. Picking one is picking which group gets the worse tool, so pick it out loud rather than by accident.

Two hosts costs the other way. You keep two configs, two OAuth grants per person, and you answer the same security questionnaire twice. What saves it is that a remote MCP server is one server either way, so the tools do not double when the hosts do. If you go that way, treat the server as the system of record and the host as a thing you can throw away. That is also the cheapest way to survive a host you stop liking.

The limit of all five questions: they test the plumbing, not the work. A host can pass every gate and still be wrong for you, because the model behind it is weak at your task, because the team will not use it, or because the one feature you need sits on a plan you cannot buy. Use the questions to cut the list, then run real work in the last two for a week.

A second limit: none of this predicts how a host behaves when things break. The probe says a server answers correctly right now. It says nothing about what the host does when a tool hangs mid-task, and that behaviour differs enough between hosts to matter. Point the host at a server that sleeps for two minutes and read what it tells the user.

Where Agentik fits, in one paragraph

Agentik {OS} sells operating systems that install into the host you already pay for, over one public MCP endpoint at https://mcp.agentik-os.com/api/mcp, with OAuth 2.1 and PKCE. The hosts are Claude, Claude Code, Cursor, ChatGPT, Codex and Hermes. The host runs the model and pays the tokens. Agentik never buys tokens, which is exactly why the five questions above are yours to answer and not ours to answer for you. For the per host steps rather than the choice, /docs/mcp has them.

The honest cost of that design: a host that fails question one cannot run our OS either. We sit on your side of the table on this one, which is why this page cites vendor docs instead of ranking vendors.