Atlassian Rovo MCP Server connection timeout after successful OAuth (mcp-remote + authv2 endpoint)

Karen West_p0b3ij

Environment:

• macOS (darwin)
• Node.js v22.x
• mcp-remote@0.1.37
• MCP endpoint: https://mcp.atlassian.com/v1/mcp/authv2
• MCP client: Kiro IDE (also tested with standalone npx command)

Issue:

As of last Friday August 14th, the Atlassian MCP server consistently times out during the connection phase, even after successfully completing OAuth authentication. The connection attempt hangs for 60 seconds and then fails with:

 MCP error -32001: Request timed out.

What I've tried:

• Updated endpoint URL — Changed from the deprecated /v1/mcp to /v1/mcp/authv2 as recommended in the documentation.
• Cleared auth cache — Deleted ~/.mcp-auth/mcp-remote-* to force fresh OAuth flow.
• Completed OAuth successfully — Ran npx mcp-remote@0.1.37 https://mcp.atlassian.com/v1/mcp/authv2 manually in terminal. Browser opened, I authenticated, and received "Authorization successful! You may close this window."
• Fixed SSL certificate error — My corporate network intercepts HTTPS traffic, causing UNABLE_TO_GET_ISSUER_CERT_LOCALLY errors. Worked around this with NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable. OAuth then completed successfully.
• Pinned callback port — Added --callback-port 39570 to match the port used during OAuth (since tokens are cached per redirect URI).
• Pinned mcp-remote version — Used mcp-remote@0.1.37 to match the version the tokens were cached under.
• Killed stale processes — Terminated lingering mcp-remote processes that might be holding locks.

Current behavior:

After all the above, running the command manually shows it just spins indefinitely:

$ NODE_TLS_REJECT_UNAUTHORIZED=0 npx mcp-remote@0.1.37 https://mcp.atlassian.com/v1/mcp/authv2 --callback-port 39570
(node:33691) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0'...
⠹⠸⠼⠴⠦⠧⠇⠏⠋⠙⠹⠸⠼...

It never progresses past the spinner. No "Connected" message, no tool discovery, just hangs until timeout.

MCP config (mcp.json):

{
"mcpServers": {
"atlassian": {
"command": "/usr/local/bin/npx",
"args": [
"-y",
"mcp-remote@0.1.37",
"https://mcp.atlassian.com/v1/mcp/authv2",
"--callback-port",
"39570"
],
"env": {
"PATH": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin",
"NODE_TLS_REJECT_UNAUTHORIZED": "0"
}
}
}
}

Cached tokens:

Tokens are present in ~/.mcp-auth/mcp-remote-0.1.37/ and appear valid (JWT with correct scopes, not expired).

Questions:

• Is there a known issue with the MCP backend causing intermittent hangs during the post-OAuth connection phase?
• Are there any additional diagnostics I can capture to help troubleshoot?
• Is there a way to increase logging verbosity for mcp-remote to see where it's getting stuck?
• I've seen other community posts mentioning similar timeout issues but haven't found a resolution.

Any guidance would be appreciated.

James Gamble

Hola Karen,

The endpoint you’re using is correct, and Atlassian currently documents mcp-remote with https://mcp.atlassian.com/v1/mcp/authv2 for IDE-based clients.

The part I’d focus on first is the corporate TLS interception. NODE_TLS_REJECT_UNAUTHORIZED=0 turns off certificate verification, but it doesn’t actually establish trust for your organization’s inspection certificate.

mcp-remote’s own documentation recommends using NODE_EXTRA_CA_CERTS when you’re behind a VPN or similar TLS-intercepting environment. You can find that guidance here, then scroll to the README > Troubleshooting > VPN Certs section. The example there shows how to set NODE_EXTRA_CA_CERTS to the path of your organization’s CA certificate file.

If your corporate network also requires an explicit outbound proxy, the same README documents the --enable-proxy option. On the repository page, search the README for “enable-proxy.” When enabled, mcp-remote will use standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables.

I’d replace NODE_TLS_REJECT_UNAUTHORIZED=0 with NODE_EXTRA_CA_CERTS pointing to the corporate CA certificate, and add --enable-proxy only if your network actually requires an HTTP/HTTPS proxy. The fact that OAuth completes in the browser doesn’t necessarily mean the subsequent MCP connection from the Node process goes through the same TLS and proxy path.

For diagnostics, mcp-remote also documents a --debug option in that same README. Search for “debug” near the command-line options. It writes detailed authentication, connection, and token-refresh information to a *_debug.log file under ~/.mcp-auth/.

I’d make those TLS trust changes first and rerun the standalone mcp-remote command with --debug. If it still reaches successful OAuth and then hangs before tool discovery, the debug log should give you a much better indication of whether the connection is stopping in the corporate network path or after it reaches Atlassian.

Thanks,

James