Connect MCP clients

After a server is created and reachable, use the server Connect tab as the source of truth for client configuration. It shows the public MCP URL, OAuth metadata, and client-specific snippets when available.

If a hosted server has an active custom domain, the Connect tab uses that custom /mcp URL. The canonical MCP Stack URL remains available as a fallback while DNS or managed TLS is still pending. See Set up a custom MCP domain for the full custom-domain workflow and status stages.

What the Connect tab gives you#

The Connect tab is the source of truth for MCP URLs, OAuth metadata, and client snippets.

The Connect tab can show:

• Hosted MCP URL (including custom domain when active).
• Gateway public MCP URL.
• OAuth issuer and protected resource metadata.
• Authorization endpoint.
• Token endpoint.
• Dynamic registration endpoint when available.
• Resource/audience.
• Scopes.
• Client snippets for supported local clients.

Copy values from the Connect tab instead of guessing endpoint paths.

Local client example#

For local developer clients that accept JSON configuration, the shape is usually:

{
  "mcpServers": {
    "support-api": {
      "url": "https://your-public-mcp.example.com/mcp"
    }
  }
}

If the server is Gateway-backed, the client should follow the advertised OAuth metadata rather than requiring a manually pasted downstream access token.

Claude Code style snippet#

Use the snippet from the Connect tab when possible. A typical command-based local client configuration looks like:

{
  "mcpServers": {
    "support-api": {
      "type": "http",
      "url": "https://your-public-mcp.example.com/mcp"
    }
  }
}

Cloud clients#

Cloud clients need a public MCP URL and working OAuth metadata. Before sharing a server with a cloud client:

1. Publish or expose the MCP endpoint.
2. Confirm the URL ends with /mcp.
3. Confirm Gateway metadata loads.
4. Confirm the provider callback URL is registered.
5. Run tools/list from MCP Stack or the CLI.
6. Test the client connection with a low-risk read tool first.

OAuth metadata checks#

Use curl to verify discovery before troubleshooting the MCP client:

curl -i https://your-public-mcp.example.com/.well-known/oauth-protected-resource
curl -i https://your-public-mcp.example.com/.well-known/oauth-authorization-server

Expected result:

• HTTP 200.
• JSON response.
• Correct issuer.
• Correct resource.
• Authorization and token endpoints from the downstream provider.

Troubleshooting connection failures#

Related#

• Configure a Gateway profile
• Set up a custom MCP domain
• Troubleshoot common issues

Quick answer#

Collect the MCP URL, whether the server is Gateway-backed, which client you are using, and the first failing request. Then verify URL, metadata, callback, scopes, and a tools/list smoke test in that order.