Does Claude.ai support MCP OAuth authorization (2025-06-18)? Getting 'Tool execution failed' instead of OAuth flow

[matsonwade]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Does Claude.ai support the latest version 2025-06-18 MCP authorization protocol? My remote MCP server returns a 401 with WWW-Authenticate: Bearer resource_metadata="PRM URL", yet Claude.ai responds with "Tool execution failed" instead of initiating the OAuth flow.

Context for my MCP Server:

• MCP TypeScript SDK 1.17.3
• Streamable HTTP based on latest 2025-06-18 protocol
• Successfully completes MCP Inspector's OAuth flow
• Endpoint is https://mcp.sitesparq-dev.io/mcp
• Deployed on AWS Fargate (ECS) behind ALB + CloudFront

To reproduce, you can call curl with:

curl -i -sS "https://mcp.sitesparq-dev.io/mcp" -X POST -H 'Content-Type: application/json' --data-binary @- <<'JSON'
{"jsonrpc":"2.0","id":"1","method":"tools/call","params":{"name":"get_website","arguments":{"websiteId":"65b7addb-a549-4953-b4df-b4d165cbe802"},"stream":false}}
JSON

Here's the response:

HTTP/1.1 401 Unauthorized
Content-Length: 0
Connection: keep-alive
Date: Wed, 01 Oct 2025 21:35:17 GMT
Set-Cookie: AWSALBAPP-0=remove; Expires=Wed, 08 Oct 2025 21:35:17 GMT; Path=/
Set-Cookie: AWSALBAPP-1=remove; Expires=Wed, 08 Oct 2025 21:35:17 GMT; Path=/
Set-Cookie: AWSALBAPP-2=remove; Expires=Wed, 08 Oct 2025 21:35:17 GMT; Path=/
Set-Cookie: AWSALBAPP-3=remove; Expires=Wed, 08 Oct 2025 21:35:17 GMT; Path=/
X-Powered-By: Express
Access-Control-Allow-Origin: *
Vary: Origin
Access-Control-Allow-Headers: Content-Type, Authorization, MCP-Session-Id
Access-Control-Expose-Headers: WWW-Authenticate
Access-Control-Allow-Methods: GET, POST, DELETE, OPTIONS
WWW-Authenticate: Bearer resource_metadata="https://mcp.sitesparq-dev.io/.well-known/oauth-protected-resource"
X-Cache: Error from cloudfront
Via: 1.1 027f3e9868eb8f82bc6ad5eae363a2fa.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: SFO53-P6
X-Amz-Cf-Id: QDzQtmTGB4zX9nvlxsCgy_aDt8m3pGSSU2hGIDE8kR2IOgkbzdvRQA==

[Tengen-12]

Yes Claude supports OAuth-based MCP servers, but your failure suggests a compatibility or implementation detail mismatch particularly because you’re implementing the latest 2025-06-18 version, and Claude may not yet fully support every nuance of that version in all cases.

[isheng-eqi]

I can see the problem in your curl output. It is not an OAuth version mismatch — it is a CloudFront configuration issue.

The smoking gun

X-Cache: Error from cloudfront

This header means CloudFront itself returned the 401 error before the request reached your MCP server. Your server is not even seeing the request. CloudFront is intercepting it.

Why this breaks Claude's OAuth flow

The MCP OAuth flow works like this:

1. Claude sends tools/call → Server returns 401 + WWW-Authenticate
2. Claude reads WWW-Authenticate header → discovers OAuth metadata URL
3. Claude initiates OAuth flow → gets access token
4. Claude retries tools/call with Authorization: Bearer <token>

In your setup, CloudFront is returning the 401 at step 1, but it is also stripping or mangling the WWW-Authenticate response header that the ALB or server originally set. Claude receives a 401 without a valid WWW-Authenticate header it can parse, so it falls back to the generic "Tool execution failed" error.

(Note: your curl output shows the header present, but CloudFront behaviors can differ between curl and the Claude client — different TLS negotiation, different header handling, different origin routing.)

The root cause

Your architecture:

Claude → CloudFront → ALB → Fargate (MCP Server)

The issue is likely one of:

1. CloudFront origin configuration: CloudFront is not configured to forward the WWW-Authenticate header from the origin. Check your CloudFront behavior → "Cache key and origin requests" → ensure WWW-Authenticate is in the allowed headers list (or use the "All" viewer request policy).

2. CloudFront error caching: The first 401 response was cached by CloudFront without the WWW-Authenticate header. Subsequent requests get the cached (broken) response. Invalidate the CloudFront cache or set Cache-Control: no-cache on 401 responses from your origin.

3. ALB health checks: Your ALB may be returning 401 to CloudFront's health checks, causing CloudFront to mark the origin as unhealthy and serve error responses.

4. CORS configuration: Claude's OAuth flow may involve a browser redirect. Your server's CORS headers list Access-Control-Allow-Headers: Content-Type, Authorization, MCP-Session-Id but the OAuth flow may need additional CORS headers (like Access-Control-Allow-Origin for the OAuth provider's domain).

How to debug

Test whether the issue is CloudFront or your server by bypassing CloudFront:

# Hit the ALB directly (bypass CloudFront)
curl -i -sS "http://<alb-dns-name>/mcp" \
  -X POST \
  -H 'Content-Type: application/json' \
  --data-binary '{"jsonrpc":"2.0","id":"1","method":"tools/call","params":{"name":"get_website","arguments":{"websiteId":"65b7addb-a549-4953-b4df-b4d165cbe802"},"stream":false}}'

If this returns the proper 401 + WWW-Authenticate header, the problem is CloudFront. If it also fails, the problem is in your ALB or server.

Claude.ai OAuth support status

To answer your direct question: yes, Claude.ai supports MCP OAuth, but with caveats:

• Claude Desktop and Claude.ai use the 2024-11-05 protocol version for OAuth, not 2025-06-18
• The resource_metadata parameter in your WWW-Authenticate header is from the newer spec — Claude may not recognize it
• Try using the older format: WWW-Authenticate: Bearer resource_metadata="https://..." with the 2024-11-05 resource metadata format

But fix the CloudFront issue first. The X-Cache: Error from cloudfront header means your OAuth flow is broken at the CDN layer, not at the protocol layer.