Your MCP server returns a login page or 403 instead of 401

If you deploy on Vercel and have Deployment Protection enabled

1. 1 Vercel's own documentation states that automated systems receive a login page or a 403 rather than your deployment content. This applies to Vercel Authentication and Password Protection alike.
2. 2 For a preview or internal deployment, send the bypass secret as a header on every request. Generate it in Project Settings under Deployment Protection.
3. 3 For a production MCP server, turn Deployment Protection off for that project and authenticate in your own handler instead — the gate is not a substitute for application auth.

# Bypass header for a protected deployment
curl -X POST https://your-app.vercel.app/mcp \
  -H "x-vercel-protection-bypass: $VERCEL_AUTOMATION_BYPASS_SECRET" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

If you use Azure App Service or Functions built-in authentication (Easy Auth)

1. 1 By default Easy Auth redirects unauthenticated requests to the identity provider's login page.
2. 2 Set the unauthenticated action to return 401 instead of redirecting, so API clients get a status they can act on.
3. 3 If your MCP server validates tokens itself, set the action to allow anonymous requests and let your handler enforce auth.

az webapp auth update \
  --name <app-name> \
  --resource-group <group> \
  --unauthenticated-client-action Return401

If your MCP server sits behind an AWS Application Load Balancer with an OIDC action

1. 1 The authenticate-oidc action performs a browser redirect flow, which an MCP client cannot complete.
2. 2 Add a listener rule that matches your MCP path and forwards straight to the target group, ahead of the authenticate rule.
3. 3 Validate the bearer token in the MCP server, or in front of it with something that speaks the MCP auth flow.

If you run oauth2-proxy in front of the server on Kubernetes

1. 1 oauth2-proxy is a browser cookie-session proxy. It is the reflexive answer for protecting an internal service and it is structurally wrong for MCP, because the client presents a bearer token and has no cookie jar.
2. 2 Route the MCP path around oauth2-proxy, and validate the token in the server or at an MCP-aware gateway.
3. 3 If you only need to accept JWTs from your existing identity provider, a JWT filter on your ingress or gateway is the simpler and correct tool.

If you deploy on Netlify with site-level password protection

1. 1 Password protection serves an HTML form rather than a 401, and a missing fallback rule can produce a bare 404 instead.
2. 2 Remove site-level protection from the MCP function's path and authenticate inside the function.
3. 3 Note that Netlify streaming functions carry a 10-second execution limit, which is a separate constraint worth checking while you are here.

Something else

Any gate built for browser sessions fails the same way, so the fix has the same two shapes wherever it lives. Either exempt the MCP route from the gate and authenticate inside your server, or configure the gate to answer an unauthenticated API request with 401 rather than a redirect. Find the component that answered the curl above — a proxy, an ingress annotation, an identity-aware proxy, a platform setting — and change it at that layer, not in your MCP handler.