MCP Connect Auth: Publish MCP Servers with OAuth Clients Can Actually Use

TL;DR​

• MCP Connect Auth gives every published /skills listing a tenant authorization server — DCR, PKCE, protected-resource metadata, and federation to your existing sign-in.
• Path B (bundle URL): publish, configure federation, point Claude/Cursor/ChatGPT at https://mcp.mcpbundles.com/bundle/{slug}/ — no pip install on your MCP server.
• Path A (vendor origin): add mcpbundles-mcp-connect when clients hit your own MCP URL.
• Full reference: MCP Connect Auth integration doc.

If you've tried to publish a remote MCP server and stalled on OAuth, you're not alone. Certified MCP clients expect dynamic client registration, PKCE, protected-resource metadata, and a coherent authorization server. Rolling that stack while also shipping tools is a common reason listings sit at /skills with zero connections.

The problem​

Publishing to the MCPBundles directory is straightforward: HTTPS URL, tool discovery, metadata, done.

Connecting from a real MCP client is a different bar. Clients probe RFC 9728 protected-resource documents, register via DCR, run PKCE, and expect token endpoints that match the metadata they fetched. Vendors who already operate app login still need a separate MCP-client OAuth surface — or clients fail before the first initialize.

That gap shows up as:

• Listings live on /skills but Claude/Cursor never complete OAuth
• Custom OAuth stacks that work for your web app but not for MCP DCR
• Protected-resource URLs that don't line up with where clients actually connect

The solution: MCPBundles MCP client authentication​

When you publish with MCPBundles handles MCP client authentication, we provision a tenant authorization server per listing slug. Your upstream JSON-RPC stays unchanged. You configure:

1. Federation sign-in URL — where users land to sign in on your app
2. Federation secret — server-side only; used after login to complete OAuth

Two connect URLs share one tenant AS:

Path B is the fastest route to real client traffic: publish, federation, bundle URL. Path A adds origin hosting and optional client telemetry when you need clients on your domain.

Vendor checklist​

1. Publish your MCP server to the public directory with MCP Connect Auth enabled.
2. Open the Connect Auth section in your maintainer dashboard — set federation sign-in URL and copy the secret once.
3. (Path A only) Install mcpbundles-mcp-connect or @mcpbundles/mcp-connect-auth on your MCP server.
4. After user login, call completeFederation from your backend with the OAuth state and your subject id.
5. Ship — point clients at the bundle URL or your origin; run mcpbundles connect doctor --listing {slug} --surface bundle until green.

What you get in the dashboard​

• Connect Readiness — same probe ladder as the CLI (public-config, JWKS, tenant AS, protected-resource)
• Connections — which MCP clients connected via bundle proxy or origin telemetry
• Install snippets — copy-paste FastMCP setup for Path A

Optional add-ons​

Origin client telemetry — when clients hit your origin (Path A), handshake middleware reports client name, protocol negotiation, and capability summaries into Connections. Path B gets full proxy telemetry with zero vendor code.

Claude / ChatGPT publishing assist — connector URLs and registry export from listing metadata when you're ready to submit to external directories.

Positioning​

MCP Connect Auth is not a replacement for WorkOS, Scalekit, or your app login stack. It is the MCP-client OAuth layer for published remote servers — the part vendors routinely underestimate before /skills traffic arrives.

We built it because directory listings without connectable OAuth don't compound. Connect Auth makes "published and connectable" the default.

Get started​

Publish with MCP Connect Auth or read the full integration reference.

mcpbundles connect doctor --listing your-slug --env staging --surface bundle

When readiness is green, connect from your certified MCP host using the bundle URL — federation loop complete, no custom AS required.