Mixed Auth & Scope Escalation Dissonance with MCP Spec

It seems like there’s a bit of a discrepancy between what the MCP spec says you should do to handle principles of least private and mixed auth MCP servers that require / expect scope escalation and what the Apps SDK documentation is saying that MCP server developers should do.

The MCP spec says here (SEP-835: Update authorization spec with default scopes definition by localden · Pull Request #835 · modelcontextprotocol/modelcontextprotocol · GitHub) that the MCP server should return a 403 with insufficient_scope and the WWW-Authenticate header set with the required scope included within it and that the MCP client should attempt to upgrade their authorized scopes by asking the user.

The AppsSDK documentation here: Authentication says that the server should return an error at the response level itself like this:

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Authentication required: no access token provided."
      }
    ],
    "_meta": {
      "mcp/www_authenticate": [
        "'Bearer resource_metadata=\"https://your-mcp.example.com/.well-known/oauth-protected-resource\", error=\"insufficient_scope\", error_description=\"You need to login to continue\"'"
      ]
    },
    "isError": true
  }
}

Those two approaches seem to be at odds with each other. Does anyone here have any practical guidance on what to do here?

2 Likes