Skip to content

Troubleshooting MCP auth

Troubleshooting guide for common errors while adding auth for MCP Servers

This guide helps you diagnose and resolve common issues when integrating Scalekit as an authentication server for your MCP servers. When you add authentication to MCP servers, you may encounter configuration problems, network issues, or client-specific limitations. This reference covers the most common scenarios and provides step-by-step solutions.

Use this guide to troubleshoot setup problems, resolve CORS and network issues, understand client-specific behavior, and implement best practices for your authentication setup.

My MCP server is not connecting to the MCP Inspector

Section titled “My MCP server is not connecting to the MCP Inspector”

When your MCP server fails to connect to the MCP Inspector, this typically indicates a problem with the authentication handshake or metadata configuration. Follow these diagnosis steps to identify the issue.

Verify the MCP server is responding correctly:

  1. Open your browser’s developer tools (Network tab)
  2. Navigate to your MCP server URL (e.g., http://localhost:3002/)
  3. Confirm the response returns a 401 status code
  4. Check the response headers for www-authenticate containing resource_metadata="<metadata-url>"

Validate the metadata:

  1. Copy the metadata URL from the www-authenticate header
  2. Open it in your browser
  3. Confirm the JSON structure matches what you see in your Scalekit dashboard

I’m getting a redirect_uri mismatch error during authorization

Section titled “I’m getting a redirect_uri mismatch error during authorization”

This error typically occurs when your MCP client has cached an old MCP server domain after you’ve changed it. The client continues sending requests to the old URL, which doesn’t match your current Scalekit configuration.

Clear cached authentication by client type:

MCP-Remote:

  1. Delete the cached configuration folder: ~/.mcp-auth/mcp-remote-<version>
  2. Reconnect to your MCP server

VS Code:

  1. Open the Command Palette (Cmd/Ctrl + Shift + P)
  2. Search for Authentication: Remove Dynamic Authentication Provider
  3. Select and remove the cached entry
  4. Reconnect to your MCP server

Claude Desktop:


I see CORS errors in the network logs when using MCP Inspector

Section titled “I see CORS errors in the network logs when using MCP Inspector”

CORS errors occur when your MCP client cannot make cross-origin requests to your Scalekit environment during the authentication handshake. This prevents the authentication flow from completing successfully.

Resolution:

  1. Navigate to Dashboard > Authentication > Redirect URLs > Allowed Callback URLs
  2. Add your MCP Inspector URL to the allowed list: http://localhost:6274/
  3. Retry the connection

Calls from the MCP client are not reaching my MCP server

Section titled “Calls from the MCP client are not reaching my MCP server”

If requests from your MCP client silently fail to reach your server, a proxy or firewall may be blocking them. This often happens in corporate environments or when using CDN services.

Troubleshooting steps:

  1. Check if you’re using a proxy (e.g., Cloudflare, AWS WAF, corporate proxy)
  2. Configure your proxy to allow or exempt requests from your MCP client to your server domain
  3. Review proxy logs to confirm whether requests are being blocked
  4. Test direct connectivity from your client machine to your MCP server (without proxy, if possible)

Claude Desktop ignores custom ports when connecting to MCP servers

Section titled “Claude Desktop ignores custom ports when connecting to MCP servers”

Claude Desktop currently only supports standard HTTPS traffic on port 443. If your MCP server runs on a custom port (e.g., https://mymcp.internal:8443/), Claude Desktop will still attempt to connect to port 443, causing the connection to fail.

Workaround options:

  1. Expose your MCP server on port 443 (requires a proxy or load balancer)
  2. Use a reverse proxy that listens on 443 and forwards requests to your custom port

Multiple authentication tabs open when using both MCP-Remote and Claude Desktop

Section titled “Multiple authentication tabs open when using both MCP-Remote and Claude Desktop”

Recent versions of Claude Desktop have introduced Connectors functionality, eliminating the need to run MCP-Remote separately. Claude Desktop includes a Custom Connector feature that allows you to configure MCP servers directly without additional tools.

Recommendation:

  • Use Claude Desktop’s built-in Custom Connector feature for MCP server management
  • Disable or stop MCP-Remote if you’re only using Claude Desktop
  • If you have a specific use case requiring both, contact Claude’s official support

My browser is not getting invoked during authentication

Section titled “My browser is not getting invoked during authentication”

Some MCP clients require permission to open your default browser during the authentication flow. If your browser doesn’t launch, the authentication handshake may timeout, preventing successful authentication.

Resolution by operating system:

macOS:

  1. Open System Preferences > Security & Privacy > App Management
  2. Ensure the MCP client has permission to open applications
  3. Restart your MCP client

Windows:

  1. Navigate to Settings > Privacy > App permissions
  2. Enable Allow apps to manage your default app settings
  3. Restart your MCP client

Linux:

  1. Ensure xdg-open or your default browser opener is installed: which xdg-open
  2. Verify the command is accessible from your terminal
  3. Restart your MCP client

Follow these best practices to avoid common issues and maintain a robust MCP authentication setup:

  1. Use separate Scalekit environments for development and production to prevent configuration conflicts
  2. Register MCP servers with environment-specific domains:
    • Development: https://mcp-dev.yourdomain.com/
    • Production: https://mcp.yourdomain.com/
  3. Update your MCP client configuration to point to the correct Scalekit environment for each deployment
  4. Test authentication independently in each environment before deploying to production
  5. Monitor authentication logs in Dashboard > Authentication > Logs to identify and resolve issues quickly
  6. Keep callback URLs updated whenever you change domains or ports