Best Prompt Tools with MCP Support (2026)

TL;DR: This is a working list of MCP prompt tools, not a marketing one: "supports MCP" is not one claim, and clients differ in transport, auth, and setup. Prompt Architects' connect page documents six working clients: Claude Desktop, Claude.ai, Cursor, Claude Code, Codex, and Codex CLI. Windsurf isn't one. We built this server, so treat that as disclosed, not hidden.

What Does MCP Support Actually Mean for a Prompt Tool?

The Model Context Protocol standardizes one thing: how an AI client discovers and calls something outside the model, over a defined transport, using a defined message shape. The current specification revision is 2026-07-28, and it defines two transports a server can offer: stdio for local processes and Streamable HTTP for anything reachable over a network.

For a prompt tool specifically, two of the protocol's primitives matter. The tools primitive is a function the model can call on its own, mid-conversation, when it decides the call is useful. The prompts primitive is a reusable template a person invokes directly, often as a slash command. Prompt Architects' MCP server exposes both: its four operations work as autonomous tool calls and as /mcp__pa__improve-style slash commands, so the model can reach for a rewrite unprompted, and a user can also trigger one deliberately.

The prompts primitive is the less finished half of the ecosystem right now. The official MCP tutorial for building a server documents registerTool repeatedly and never once walks through registering a prompt, and client support for the slash-command syntax is inconsistent: Claude Code documents /mcp__servername__promptname explicitly, VS Code tells users to type /<MCP server>.<prompt>, and Cursor lists prompts as a supported feature without publishing any invocation syntax for them at all. If a prompt tool's MCP server only ships the tools primitive, that is not a shortcut. It is closer to where most of the ecosystem already sits. We cover the prompts primitive and its slash-command conventions in more depth in MCP prompt templates and slash commands.

Authentication is more settled. For any server reached over HTTP, the specification's authorization page states plainly: "Authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients" (modelcontextprotocol.io, accessed September 3, 2026). A prompt tool whose MCP server skips OAuth entirely and only accepts a static key is not following the current spec's baseline expectation, even if the connection still works. If MCP itself is new to you, our beginner-friendly walkthrough covers the concept without assuming you already write code.

The MCP Client Landscape You'll Actually Connect a Prompt Tool To

An MCP-capable prompt tool is only useful inside a client that also speaks MCP. Prompt Architects' own connect page (prompt-architects.com/integrations/mcp, verified September 3, 2026) documents exactly six: Claude Desktop, Claude.ai, Cursor, Claude Code, Codex, and Codex CLI. Each has its own setup shape, and the shapes genuinely differ enough that "just add the MCP URL" undersells how different the actual steps are.

Here is how four of them compare, pulled directly from the setup code shipped on that page:

Codex (the desktop app) and Claude.ai follow the same OAuth-only shape as Claude Desktop: paste a URL, sign in through a browser tab, approve once. Codex CLI is the outlier. It speaks stdio, not HTTP, so the config bridges to the remote server through mcp-remote, a small proxy fetched on demand with npx. That single difference is why "does this tool support MCP" is the wrong question to stop at. The honest follow-up is which transport, and does the client's config format match it.

Windsurf, Devin, and the Client That Isn't on the List

Windsurf is a real product and belongs in any honest account of the MCP client landscape. It just is not one Prompt Architects has a documented connection for. Cognition acquired Windsurf, and as of this writing docs.windsurf.com 301-redirects straight through to docs.devin.ai, with the rules-file convention moving alongside it: .devin/rules/ is now the preferred location for agent rules, .windsurf/rules/ is kept as a fallback, and the older single .windsurfrules file is still read.

That acquisition explains why some 2026 content about "MCP-compatible tools" lists Windsurf and Devin as effectively the same surface. It also means the correct scoping for this post is narrow: Prompt Architects' connect page names six clients, and Windsurf genuinely is not one of them.

There's a broader lesson underneath the Windsurf case, and it applies to any "MCP-compatible tools" list, ours included: a roundup like this one has a shelf life, because MCP client support is still actively consolidating. An editor who bought a company last quarter can rename its docs, change its rules-file convention, or fold its whole product into another one's brand, and a static list written before that happened goes stale without anyone editing a single word of it. The fix isn't to avoid naming specific tools. It's to check each one against its own current page before you trust a list, including this one, rather than assuming a name you recognize still means what it meant six months ago. Marketing copy on our own site describes the server as working with "any other MCP-aware client," which is technically true of the protocol in general. This post is specifically about tested connections, though, and Windsurf is not one we can point you to a working guide for. Do not read general MCP-awareness as a promise of a supported setup.

Why MCP Is Our Strongest Signal for a Serious User

This is where the disclosure in the callout above earns its keep: the reason this topic gets a dedicated post is a number from our own customer data, not marketing copy.

Only 4.8% of all customers connect MCP at all, which makes it the least-used of the platform's seven features by raw count. But among the top 5% of customers by engagement, 60.6% have it connected, the single strongest predictor of high-value usage in the dataset, ahead of every other feature. Claude Code alone accounts for roughly 177,000 of the 199,000 recorded MCP events, mostly session handshakes rather than one-off calls, which points to people leaving the connection live and reaching for it repeatedly rather than trying it once.

None of that means MCP is the easiest on-ramp. It clearly is not, given how few customers use it at all, and the six-client setup walkthrough further down this post is exactly the kind of one-time friction that keeps adoption low. It means that once someone does the one-time setup, they tend to stay, and the gap between 0.7% and 60.6% is too large to explain as noise. The likelier story is that connecting an MCP server selects for a specific kind of user in the first place: someone who already lives in a terminal or an IDE rather than a browser tab, and who was already going to be a heavier user of everything else the product offers. MCP probably isn't manufacturing engagement so much as it's a visible marker of engagement that already existed. Either way, the correlation is real and it's the reason this feature earns a dedicated buying guide rather than a single bullet point on a comparison page.

Connecting an MCP Server: The Same Six Steps, Every Time

Strip away the client-specific screenshots and every OAuth-based MCP connection reduces to the same sequence:

1. Get the server URL. For Prompt Architects it is https://mcp.prompt-architects.com/mcp, one URL for every client, with no per-client variant.
2. Open your client's connector or MCP settings. Named differently everywhere: Claude Desktop calls it Settings → Connectors, Cursor calls it Settings → MCP.
3. Add a new server entry. Either paste the URL into a UI field or drop a small JSON block into a config file. Both do the same thing.
4. Trigger the connection. The client either auto-detects OAuth or you click an explicit "Authenticate" action.
5. Sign in and approve, in the browser tab that opens. This is the OAuth 2.1 consent screen the spec's MUST requirement guarantees exists, not a proprietary login page.
6. Confirm it worked. In Claude Code, typing /mcp lists connected servers; in others, the new tools simply appear the next time you open a chat. If a server that should be connected doesn't show up, this troubleshooting guide works through the most common causes before you assume the server itself is down.

The one client-specific wrinkle worth showing in full is Claude Code, because it collapses steps 2 through 4 into a single terminal command:

claude mcp add --transport http pa https://mcp.prompt-architects.com/mcp

Running that opens a browser tab for sign-in and consent, then the server is live. The full setup, scopes, and auth details specific to that client are in Using MCP inside Claude Code. For a headless box where no browser can open, the personal-access-token variant replaces steps 4 through 6 with a static header instead of an interactive login:

claude mcp add --transport http pa \
  https://mcp.prompt-architects.com/mcp \
  --header "Authorization: Bearer pa_live_<your-token>"

The Four Tools You Get Once You're Connected

Prompt Architects' server exposes four operations, each available both as something the model can call on its own and as an explicit slash command:

The tools/prompts split described earlier in this post is exactly what makes both invocation styles possible here: each of the four is registered as an MCP tool, so a model mid-task can call improve_prompt without being asked, and the same four are also exposed with the /mcp__pa__ prompt naming Claude Code documents, so a person can trigger one directly instead of waiting for the model to decide to.

Custom GPTs Are Not MCP Clients, and That Distinction Is the Best Portability Argument Around

If you build against OpenAI's Responses API, you are, in a real sense, using an MCP client. The platform's own developer docs state it directly: "Both connectors and remote MCP servers can be used with the mcp built-in tool type" (developers.openai.com, accessed September 3, 2026).

Custom GPTs are a different surface entirely, built on an uploaded OpenAPI schema for Actions rather than the MCP protocol, and they carry a default configuration that blocks outbound calls to any domain not explicitly allowlisted. Custom GPTs are also more restricted than most guides assume: OpenAI's help centre documents that creating and publishing a new GPT is unavailable on every personal ChatGPT tier, Free through Pro, and works only inside Business, Enterprise, and Edu workspaces.

That gap, a first-party agent API that speaks the same open protocol as Claude Code and Cursor, next to a GPT-builder surface that speaks a proprietary schema instead, is the strongest evidence for MCP as a genuinely portable standard rather than a Claude-specific convention. It comes from OpenAI's own documentation, not from an MCP advocacy piece.

Two more restrictions worth knowing if you were planning around Custom GPTs specifically. OpenAI's own help centre states that creating and publishing a new GPT is not available on any personal ChatGPT account at all, not Free, not Go, not Plus, not Pro; it works only inside Business, Enterprise, and Edu workspaces, subject to that workspace's own permissions. And the older Assistants API, which some existing "AI agent" tutorials still reference, was shut down on August 26, 2026, replaced by the Responses API and a separate Conversations API. If a guide you're reading about connecting a prompt tool to "ChatGPT" doesn't specify which of these three surfaces it means (Custom GPTs, the Responses API, or the retired Assistants API) treat that as a sign the guide itself hasn't been checked against OpenAI's current docs.

A Token in a Config File Is a Real, Long-Lived Credential

Every client above that offers a personal-access-token path is asking you to paste a plaintext secret into a file. Treat it accordingly.

The practical rules: keep any file containing a bearer token out of version control with a .gitignore entry, scope tokens per project or per machine instead of sharing one everywhere, and know before you need it how to revoke and reissue one. OAuth avoids this entire category of risk by design, since there is no long-lived static secret sitting on disk. That is the real reason the connect flows above default to it and only reach for a token as the headless fallback.

Which Auth Method Should You Actually Use?

Default to OAuth 2.1 for anything you personally operate — a laptop, a desktop app, an interactive terminal session. It costs one browser sign-in, tokens refresh themselves, and revocation from a dashboard is immediate and complete. Reach for a personal access token only where a browser genuinely cannot open: a CI pipeline, a scheduled script, a headless server. When you do, scope it as narrowly as the client allows, store it outside your repo, and rotate it the moment you suspect it has been seen by anyone or anything it shouldn't have been.

Getting the client list and the auth shape right matters more than which specific prompt tool you connect first — the setup pattern above transfers to any MCP server that follows the specification correctly, ours included. MCP support is one axis to compare prompt tools on, not the only one; if your team's evaluation criteria are shaped by a specific job function, our roundup for customer support teams works through that trade-off for one concrete use case.