MCP Client: What It Does and How to Pick One

Your AI can use only the tools your MCP client lets it reach. Pick one carelessly and you've picked your limits.

An MCP client is the part of an app that connects an AI model to MCP servers, the services that hold your tools and data. It keeps the line open, asks each server what it offers, and carries the model's requests across. Claude Desktop is one. Cursor is another. So is a Python script you wrote on a Sunday.

Strictly, the MCP specification calls the app the host and the client a connector inside it. Everyone says "client" for both, and so does this post.

If the protocol itself is new to you, Model Context Protocol, explained plainly covers it from the start.

The loose naming hides three decisions. Does the client reach servers on the internet, or only ones on your laptop? Does it ask before a tool runs? Does your connection survive when you change models?

Those three matter more than the logo on the app.

Choose an MCP client by where its servers run, who approves each call, and whether your connections outlast your choice of model.

An MCP client is the switchboard, and the model makes the calls

Picture an old telephone switchboard. The operator doesn't decide who gets called. The operator holds the cables, knows which jack leads where, and patches the caller through.

The model is the caller. Each MCP server is a person on the far end of a line, good at a particular set of jobs.

The client is the operator.

Anthropic introduced MCP in November 2024, and the official tutorial for building a client shows what the operator does. A message that needs a tool goes through seven steps:

1. The client asks each connected server which tools it offers.
2. Your message goes to the model together with those tool descriptions.
3. The model decides whether a tool would help, and which one.
4. The client carries the model's request to the server and runs the call.
5. The server's result comes back to the client, which hands it to the model.
6. The model writes a plain answer from the result.
7. You read it.

Look at who owns what. Step 3 belongs to the model. Steps 1, 4 and 5 belong to the client.

Step 2 is where a cost hides.

Step 3 is also where MCP parts ways with a plain API call. With an API, your code chooses the call. With MCP, the model does, which is the argument behind MCP vs API.

A server can offer more than tools. The spec lists three things: resources, which are data the user or the model can read, prompts, which are templated messages and workflows, and tools, which are functions the model can run. It also lets a client offer something back. That something is elicitation, where a server asks you for more information in the middle of a task.

Support for those pieces is the client's call. Cursor's docs list tools, prompts, resources, roots, elicitation and apps as supported. VS Code's docs describe tools, resources, prompts and MCP Apps.

Nothing in the protocol forces a client to carry the whole set. A server that leans on prompts or elicitation can behave differently from one client to the next.

Five kinds of MCP client cover almost everything you will meet

The kind of client tells you more than the brand does. Find the row that sounds like where you work.

Each kind has a regret waiting for it, and knowing the regret in advance is most of the choice.

With an editor, the regret arrives the first time a teammate who doesn't code asks to use the connection you built. With a single vendor app, it arrives when you want another company's model to look at the same data. With an open source app, it arrives when an update changes how servers are configured and you're the one who has to fix it.

With a command line client or an SDK, it arrives when the thing you built for a test becomes something people rely on. With a workspace, the regret is the one in the table: a server that only exists on your laptop needs an address before the workspace can reach it.

None of these is a reason to avoid a kind. Each is a cost to price in before you start.

Two questions sort the five faster than any feature list. Where does the server run? Who else needs the connection?

The first question separates clients that start servers on your machine from clients that call servers on the internet. The second is the one people skip.

A connection only you can use is a personal tool. A connection that a teammate, an agent or a scheduled task can use is infrastructure, and it deserves a client built for that.

Local or remote decides how hard setup is and how much you have to trust

A local MCP server is a program on your own computer. The client starts it with a command and talks to it through standard input and output, a transport called stdio.

A remote server lives at an address. You paste the URL, sign in if it asks, and you're connected.

Cursor's docs lay the difference out in one table. These are the columns that matter for a choice:

The trade is trust. VS Code's documentation says it plainly: local MCP servers can run arbitrary code on your machine, so add only servers from sources you trust.

It can sandbox local stdio servers to limit file and network access, but only on macOS and Linux. On Windows, it can't.

Take a notes folder you want a model to search. VS Code's sandbox settings let you name the folders a server may write to, deny it your SSH directory, and list the only network domains it may call. That's the right way to run a local server: narrow, named, and nothing else.

A remote server runs on someone else's machine, so a bad one can't read your disk. It can still misuse whatever you let it sign in to, which is why the sign-in screen deserves a read.

Vendors such as Stripe, Sentry and Cloudflare run servers you can connect to by address. Use those remote. Use a local server when the data lives on your machine, like that notes folder or a database on localhost, and read its code first.

Watch how a client handles sign-in. Cursor's docs cover providers that don't support dynamic client registration: you paste a client ID, and optionally a secret and scopes, into a JSON file.

That's fine for a developer. A sign-in button is the better design for anyone who doesn't write JSON for a living.

Here is where the remote-only design stops being right. If your server reads files on your laptop, a client that calls only remote servers can't reach it until you put it at an address. Magai works that way, and an editor or a desktop app is the better pick for that job.

Remote when you can. Local when you must.

Every tool you connect rides along with every request

Go back to step 2. Your message travels to the model with a description of every tool the client has switched on.

Say you connect six servers that offer forty tools each. That is 240 descriptions in front of the model before it reads your question. The client in the official tutorial lists the tools and sends all of them with each query, and a basic client does the same.

Three things go wrong at that size. The request grows, so replies cost more and arrive slower. Two servers with similar tools, such as two that both offer a search, leave the model a coin flip. And the model can reach for a tool you never meant it to use for this job.

So ask whether the client lets you trim the list. VS Code has a Configure Tools button in the chat input that shows every tool from a server and toggles individual tools on or off.

Cursor lets you switch a whole server on or off from its Customize page, and its docs say a disabled server won't load or appear in chat. A client with neither leaves you choosing between everything and nothing.

Start with fewer servers than feels sensible. You can add the seventh in a minute, and you can't unsee a week of muddled answers.

Trim yours in five minutes:

1. List every server you have connected.
2. Beside each one, write the single job it does for you.
3. Switch off or remove any server with no job.
4. On the servers that stay, turn off tools you would never want a model to call.
5. Ask your three most common questions again and compare the answers.

In Magai, the connections list shows every server in the workspace with the tools each one offers, and removing one takes a click.

Approval is the setting that decides what a mistake costs

The spec is blunt about this. Hosts must obtain explicit user consent before invoking any tool, tools represent arbitrary code execution, and descriptions of what a tool does should be treated as untrusted unless they come from a server you trust.

The spec also admits that MCP can't enforce any of it at the protocol level. The client does.

What that looks like varies. Cursor asks for approval before using an MCP tool by default and shows you the arguments. Its run modes change that: in Auto-review mode, allowlisted MCP tools run at once and everything else goes through a classifier.

VS Code may ask you to confirm each tool invocation, and it treats calls from a sandboxed server as pre-approved because the sandbox limits what they can do.

You'll hear the objection from yourself within a week. Approval prompts get tiresome, and by the thirtieth click you've stopped reading them.

A prompt nobody reads protects nobody.

Fair. So split the decision by consequence. Take an issue tracker server. Tools that list issues or read one are reads. Tools that create, assign or close an issue are writes.

Let the reads run without asking. Make the writes stop and ask. You get automation on the questions you ask all day and a human check on every move that changes the record.

Before the first real task on any new client, run a short drill. Connect a server, ask for something that only reads, then ask for a harmless change and watch whether the client stops to ask. If it doesn't, find the setting before you do anything that matters.

Approval is the last line of defense, so vet the server before it ever gets that far. How to check an MCP server before you connect it walks through that.

A workspace client keeps your connections when the model changes

Every client above keeps the connection in one place. A code editor keeps it in the project or your profile. A single vendor app keeps it with that vendor's models. An open source app keeps it in the app you installed.

Now change the model. You want a second opinion, or a cheaper model for the boring part, or a stronger one for the hard part. In a single vendor app that means leaving and reconnecting every server.

Anyone who has moved a half finished job from one model's app to another's knows what that costs, and Grok vs ChatGPT puts a name on it: the switching cost between models.

A workspace client changes where the connection lives. In Magai the connection belongs to the workspace, not to a model. Ask a question with Claude, type /GPT on the next message, and the same server answers both, with the conversation intact.

Nothing said earlier in the thread is lost when the caller changes.

A thread can run like this. Ask Claude which Linear issues are blocking the launch. Type /GPT and have it assign the export bug and draft a two line update for Slack. Type /Gemini and have it pull this week's error counts from a Sentry server.

Three models, two servers, one thread, and each server was connected once.

Agents use the same connections. Give an agent a connection and it can call that server's tools on its own, in a chat or on a schedule. Any agent in Magai can connect to external MCP servers.

Workspaces separate teams or projects, and a connection belongs to one workspace. An agency can keep one client's servers in that client's workspace and nowhere else.

Setup is a paste. On the MCP connector page the steps are to add the server's URL and a name, sign in if it asks, read the tools it lists, and use it in any chat on any model. The connector comes with every plan, and Standard is $20 a month.

A server that hands your tracker or your database to a model raises a fair question about where that data goes. In Magai, prompts, files, inputs and outputs are never used to train any model, from any provider on the platform.

Newer MCP features are where clients start to differ

The 2026-07-28 revision of the spec describes requests as stateless and self-contained, with capabilities negotiated per request. On top of that core it defines optional extensions.

Tasks covers long running operations, with polling and durable handles. Skills over MCP delivers structured instructions for agent workflows, discovered through MCP itself. MCP Apps puts interactive pieces such as charts, forms and video players inside the conversation.

Every extension is opt in and needs support from both the client and the server. That last clause is the one that affects you.

A server can offer an app that renders a chart, and a client that doesn't support MCP Apps shows you plain output. Cursor's docs say MCP Apps follow progressive enhancement: if a host can't render the UI, the tool still works through normal MCP responses.

Good design, and still a downgrade if the chart was the point. Both Cursor and VS Code list MCP Apps support.

Tasks matter when a job takes minutes, like a large export. Without them, a long call holds up the whole conversation.

Skills over MCP is worth watching if you build agents. If a server can hand a client the instructions for using it well, an agent needs less hand written setup. Support is up to each client.

Three questions to put to any client you're weighing:

1. Does it render MCP Apps, or does it fall back to text?
2. Does it support Tasks, so a long job doesn't hold up the conversation?
3. Does it show an image a tool returns? Cursor's docs say it attaches returned images to the chat.

You don't need any of this on day one. Check it when a server you depend on starts leaning on it.

Find your situation and the client follows

Find the row that sounds like your week.

Picture three people and follow the table for each.

A solo consultant keeps client notes in a folder on a laptop and wants a model to search them. The fourth row applies. The server is local, so the consultant needs a client on the same machine, and an editor or a desktop app fits. The workspace row doesn't apply until the notes sit behind an address.

A five person marketing team lives in an issue tracker, a calendar and a docs tool, and each publishes a remote server. The first row applies. They connect each server once, and every model and every scheduled report works from the same list, because the connection belongs to the workspace they share.

A developer building a support bot needs to see exactly what a server returns before shipping. The last row applies. An SDK client shows the raw messages, and the editor stays for everything else.

If you're the second person, pick a client built for sharing. If you're the first or the third, the table already sent you somewhere better, and that's the honest answer.

If you write code all day, keep your editor as your MCP client. A workspace doesn't replace it, and both can connect to the same remote server.

Run a 20 minute test before you commit to an MCP client

Twenty minutes with one server you already use will tell you more than a feature list. Run these steps in order on any client you're weighing.

1. Pick one remote server you already use, like your issue tracker or a docs tool, and connect it. Note whether sign-in was a button or a file, and how long it took.
2. Read the tool list. Count the tools, check that each has a description you understand, and see whether you can switch off the ones you don't need.
3. Ask a question only the server can answer, such as which tasks are due Friday. Then confirm the answer came from a tool call and not the model's guess. A good client shows the call and its arguments.
4. Ask for a small change you can undo, like adding a test note. See whether the client stops to ask, and whether the prompt tells you what is about to happen.
5. Ask for something that can't work, like a record that doesn't exist. The protocol lets a tool report an error instead of crashing, and the official client tutorial passes that flag to the model so it can try something else. See whether your client does that or goes quiet.
6. Change the model and ask the first question again. The connection should work with no extra setup.
7. Hand the connection to someone else, or to a schedule. See whether it runs without you at the keyboard.
8. Remove the server, then revoke its access on the server's own side so the sign-in doesn't linger.

Score each step pass or fail. A client that passes steps 1 to 5 is safe to use alone. Steps 6 and 7 decide whether it's safe to use with other people, so give them as much weight as the first five.

A slow first reply isn't a verdict. The official tutorial warns that a client's first response can take up to 30 seconds while a server starts. Judge the second reply.

To run the test in Magai, step 1 takes a minute. Paste the server's address at app.magai.co, sign in if it asks, and read the tool list before you ask anything.

Then ask the same question with /Claude and again with /GPT, and see whether the second model needed anything from you.

The operator stays. The callers change. Pick an operator that can handle that.