Client compatibility
Clients differ. Your team shouldn't
rediscover that by issue thread.
MCP clients vary in auth flows, transport assumptions, and capability support. mcpctl hosts the compatibility layer at the edge — each client sees the interface it expects. Your server just handles tools.
The reality
The compatibility matrix is real.
An MCP server that authenticates correctly in Claude may fail silently in Cursor. Transport assumptions differ. Capability support varies. mcpctl's hosted compatibility layer absorbs these differences at the edge — your server doesn't have to handle them.
Ship once. mcpctl handles the rest.
Deploy once from your GitHub repo. mcpctl's hosted compatibility layer handles the per-client differences at the edge — no separate per-client deploy cycles or custom integration work.
Hosted at the edge, always-on
Auth flows, transport negotiation, and client-specific wiring live in mcpctl's compatibility layer. Each client sees the interface it expects. You don't configure it per client or maintain it.
Honest about coverage
Most teams only validate the client they built against first. mcpctl validates the managed layer across supported clients, and /inspect gives live evidence for what is running.
Supported clients
Validated where teams usually guess.
A self-built MCP server is usually only proven in the first client the developer used. mcpctl validates the hosted layer across the supported clients below so compatibility does not turn into a per-client yak shave for your team.
Typical self-built server
Usually validated in one client first.
Most teams build against the client they use day to day, often Claude Code. That client gets real validation first; the others stay unverified until auth, transport, or capability mismatches show up later.
mcpctl managed layer
Validated across supported clients.
mcpctl validates the hosted compatibility layer across Claude, Cursor, Windsurf, and Cline so your team is not treating every client as a separate integration project.
Status key: Validated — confirmed by mcpctl across the supported client surface above. Outside the supported set, client support still varies by feature, auth scheme, and transport. Check /inspect for live validation evidence on your deployed service.
Push once. mcpctl handles the rest.
Connect your repo and mcpctl auto-deploys on push. Auth, transport, and client compatibility live in mcpctl's hosted layer at the edge — your server stays focused on tools.
Connect your repo