MCP clients

The client is the side of an MCP connection that's doing the using. Your AI app. Claude Code, Claude.ai, Cursor, your custom agent, they're all clients. This page covers what clients actually do, which ones exist in 2026, and what separates a good one from a mediocre one. The quiet truth: the client you pick shapes your AI experience more than the model does.

What a client's actually responsible for.

When I said earlier "the client is the middleman," that undersells it. A good MCP client has a surprisingly long list of jobs.

That last two bullets, permissions and results, are where clients earn their keep. You can build a "technically MCP-compliant" client in a weekend. Building one that's safe and pleasant to use takes years of polish.

The clients that exist today.

The ecosystem in 2026 is still Anthropic-led, but broadening fast. Here's the landscape at a glance.

Claude Code

Anthropic's CLI agent. If you're building agents, this is where you spend most of your time. MCP is first-class, servers go in ~/.claude/config.json or a project file, and they just show up as tools. Supports every transport. See Claude Code overview.

Claude.ai (web + desktop)

For non-developer users. MCP servers are presented as "connectors" (Gmail, Calendar, Notion, Slack, GitHub, Linear, and growing). You install a connector, authenticate once, and every conversation has access. No JSON files to edit. The best on-ramp for someone who doesn't want to touch config.

IDEs and editors

Cursor has the most mature IDE-side MCP support in 2026. Zed is catching up. VS Code supports a subset through the Claude extension. JetBrains has community plugins. Each lets you pipe your code context into the agent along with the MCP tools you configure, which is powerful for working inside a codebase.

Custom agent frameworks

If you're rolling your own agent, the MCP SDKs ship client-side libraries too. You connect your agent to any MCP server and pipe tools directly into your LLM calls. LangGraph, CrewAI, Autogen, and others have MCP adapters in 2026. This is the path if you need behavior no existing client gives you.

What a client config actually looks like.

Most clients use a JSON config. Here's the Claude Code style (other clients are similar):

{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@notionhq/notion-mcp"],
      "env": { "NOTION_API_KEY": "secret_..." }
    },
    "github-remote": {
      "url": "https://api.github.com/mcp",
      "headers": { "Authorization": "Bearer ghp_..." }
    }
  }
}

Two servers here, one local (stdio, spawned from an npm package) and one remote (HTTP endpoint). The client reads this on startup and manages both connections transparently. Adding a new server is just adding another entry. No code changes, no restart of the AI model.

The permission chokepoint.

This is the single most important thing a client does, and the thing that separates good clients from dangerous ones.

Every MCP tool call goes through the client before it reaches the server. That means the client is the only place in the stack where you can say "allow this" or "block this" or "ask the user first." A client without a permission system is a loaded gun: the model can call any tool whenever it wants, including things that cost money or delete data.

Claude Code does this with allow/deny lists using glob patterns:

• mcp__notion__*, allow any tool from the Notion server
• mcp__github__delete_*, always ask before any delete operation on GitHub
• Bash(rm -rf *), flatly deny (never even ask)

Before running any tool call, the client matches it against this list. See Permissions for the deep dive on designing a good one.

Things clients quietly differ on.

On paper, all MCP clients implement the same protocol. In practice, they diverge on a few details you'll run into:

• Resources support. Not every client exposes resources to the user. Some only do tools. If your workflow depends on the user pinning a resource, test on the exact client your user has.
• Prompts UI. Clients decide how to show server-provided prompts. Some as slash-commands, some as menus, some not at all.
• Progress notifications. Long-running tools can stream progress updates in MCP. Some clients show them, some ignore them.
• Remote auth flows. Remote HTTP servers typically need OAuth. Each client handles this slightly differently; what's seamless in one might require manual config in another.

Rule of thumb: servers don't know which client is calling. If you're building a server that depends on specific client features, test on every major client before shipping.