Summary

Attempting to log into the Atlassian MCP server (https://mcp.atlassian.com/v1/sse) from Warp opens the system browser, but the Natoma authorization page never renders. The browser hangs or shows an invalid_request error from Natoma. The root cause is that the rmcp crate Warp pins (warpdotdev/rmcp @ c0f65dc441af7d714b9c453ac5e7ef641451abe3) does not include the OAuth 2.0 resource parameter (RFC 8707, Resource Indicators for OAuth 2.0) on either the /authorize URL or the /token exchange request. Natoma enforces resource, so it rejects the authorize call with invalid_request before the user-facing login page is rendered.

Steps to reproduce

1. In Warp, install/enable the Atlassian MCP server (e.g. via the MCP UI or by adding a templatable MCP installation pointing at https://mcp.atlassian.com/v1/sse).
2. Trigger OAuth: Warp opens the configured URL in the system browser.
3. Observe that the Natoma authorization page does not render — the browser either hangs on a redirect or shows invalid_request.

Expected behavior

The Natoma consent page renders, the user logs in / consents, and Warp completes the OAuth callback. The Atlassian MCP server then becomes usable from Warp.

Actual behavior

The authorize URL is constructed without the resource query parameter. Natoma rejects the request with invalid_request (or equivalent). The login page never renders and the MCP server stays in Authenticating / unauthenticated state.

Diagnosis

In the pinned rmcp revision, AuthorizationManager::get_authorization_url and AuthorizationManager::exchange_code_for_token build their requests without add_extra_param("resource", ...). Upstream modelcontextprotocol/rust-sdk already added this in PR modelcontextprotocol/rust-sdk#651 ("11-25-2025 compliant Auth"), but warpdotdev/rmcp had not yet picked up the change at the rev Warp pins.

The minimal fix is to thread self.base_url.to_string() as the resource parameter through both endpoints (per RFC 8707):

let mut auth_request = oauth_client
    .authorize_url(CsrfToken::new_random)
    .set_pkce_challenge(pkce_challenge)
    .add_extra_param("resource", self.base_url.to_string());

and likewise on .exchange_code(...).set_pkce_verifier(...).add_extra_param("resource", self.base_url.to_string()).

Proposed fix

A PR backporting just the RFC 8707 part of the upstream fix is open against warpdotdev/rmcp:

• rmcp PR: feat(auth): add RFC 8707 resource parameter to authorize and token requests rmcp#10

Diff is +50/-3 in crates/rmcp/src/transport/auth.rs (the +50 includes a unit test asserting the resource query parameter is present in the generated authorize URL). All 23 auth tests pass:

cargo test -p rmcp --features=auth --lib transport::auth
test result: ok. 23 passed; 0 failed

Once that lands, Warp can bump the pinned rmcp rev in Cargo.toml and remove the temporary workaround in app/src/ai/mcp/templatable_manager/oauth.rs.

Environment

• OS: macOS
• Warp: open-source build from warpdotdev/warp:master
• Affected MCP server: https://mcp.atlassian.com/v1/sse (Natoma-backed)

Filing per CONTRIBUTING.md: this is a bug report, so it should be implicitly ready-to-implement once triaged.