Hey, thanks for the detailed report. We don’t often get ones this thorough.
Let’s break down what’s happening. The OAuth flow in Cursor only starts when the MCP server responds to an unauthenticated request with 401 + WWW-Authenticate (that’s how the MCP auth spec works). The Docusign endpoint (both prod mcp.docusign.com/mcp and demo mcp-d.docusign.com/mcp) returns HTTP 403 "RBAC: access denied" instead, and it does not include the WWW-Authenticate header. A plain 403 in the spec means “a token exists, but permissions are insufficient.” That’s a different state than “auth is required,” so Cursor treats it like a transport or gateway failure, the server goes into error, and it never reaches needsAuth. That’s exactly what you’re seeing.
Important detail: the CLIENT_ID and CLIENT_SECRET you enter in Configure are only used after the OAuth flow starts. Since the 403 happens earlier, it never gets to that step, so trying different configs won’t change anything. This also explains why the HubSpot plugin worked for you but Docusign didn’t. It’s not your setup, it’s the response from that specific endpoint.
What you can do on your side is contact Docusign support and ask them to make their MCP gateway return 401 + WWW-Authenticate: Bearer resource_metadata="..." for unauthenticated requests instead of 403. Without that, no MCP client that follows the spec can start OAuth. For a concrete example of how this gets fixed server-side, here’s a writeup of a similar case with Microsoft Entra ID: Working Solution: MCP Server OAuth with Microsoft Entra ID on Azure Container Apps. In that case the endpoint also didn’t return WWW-Authenticate, and the author explains what needs to be changed.
I’ve passed this to the team. If there’s an update, I’ll reply here.