Custom Azure-hosted MCP connector started intermittently failing on Aug 12 — "Couldn't reach the MCP server" — traced to OAuth discovery preflight against a non-OAuth server

### MCP server URL

https://[REDACTED-appservice].azurewebsites.net/sse

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

My server does not have auth

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026-08-14, ~2:47 PM CDT

### Browser and OS

_No response_

### Describe the issue

Our custom remote MCP connector (no OAuth — IP allowlist + API key auth) stopped connecting reliably on 8/12/2026 around 4PM Central Time from Claude Desktop and claude.ai, failing with "Couldn't reach the MCP server," despite the server being confirmed healthy throughout. This server has been in continuous production use since approximately February 27, 2026 (~5.5 months) with no comparable connectivity failures before August 12, 2026 — this is not a fragile or newly-deployed setup. Edge-level diagnostic logging shows the client running an OAuth discovery preflight (.well-known/oauth-protected-resource, .well-known/oauth-authorization-server) against our server immediately before failed connection attempts, all returning 404 since we don't implement OAuth. We also tested publishing a minimal Protected Resource Metadata document with an empty authorization_servers array — this made things worse, producing a different, harder failure ("Couldn't register with sign-in service") via an attempted Dynamic Client Registration against a server we hadn't listed.

### Issue details

```shell
The connector had been working normally, then began failing to connect starting [date/approximate time — fill in when it first broke, if you can pin it down]. This wasn't a gradual degradation — it stopped working and has not reliably recovered since, despite the server itself remaining healthy and responsive the entire time (confirmed via /health and direct API tests against the underlying database).

Sequence observed via Azure AppServiceHTTPLogs immediately preceding a failed connection attempt (all requests from a legitimate Anthropic IP within the documented 160.79.104.0/21 range, completing within ~340ms of each other — not a timeout):

GET /.well-known/oauth-protected-resource/sse -> 404
GET /.well-known/oauth-protected-resource -> 404
GET /.well-known/oauth-authorization-server -> 404

We then tested returning:

json
{ "resource": "...", "authorization_servers": [] }

at the two protected-resource paths. Result: instead of "Couldn't reach the MCP server," the connector produced a new error — "Couldn't register with [connector]'s sign-in service. You can try again, or add an OAuth Client ID in the connector settings" (ofid_1eb1ec879dc028d2). We reverted immediately; the original "Couldn't reach" symptom returned (ofid_a8a8d0d8521c31e6), confirming the revert was clean.

We separately found and fixed an unrelated validator bug on our own server (rejecting a connectivity-check query with no table reference) and confirmed via code inspection it cannot be the cause of this symptom — it only fires on tools/call, never initialize, and even a rejection returns a complete HTTP response rather than a dropped connection.

Reference IDs collected:

ofid_38ec7cc64c35fdc0 — Aug 12, 2026, ~4:36 PM CT (first reported, via internal helpdesk ticket from an end user)
ofid_92ad1e4f577e2f27
ofid_b4bc07d7f460c673
ofid_da5c0ccb5527a61d
ofid_1eb1ec879dc028d2 (during the metadata experiment)
ofid_a8a8d0d8521c31e6 (after reverting)
```

### Expected behavior

For a server that reports "no auth" (as selected above), the client's OAuth discovery preflight should either be skipped entirely, or a 404/absence of .well-known/oauth-protected-resource should be treated as "this server doesn't use OAuth, proceed directly to the MCP handshake" — not result in a failed connection. If a specific response shape is required to signal "no authorization needed" (as opposed to omitting the endpoint or publishing empty metadata, both of which currently fail), that should be documented so non-OAuth server maintainers can implement it correctly.

### Logs from your server

```shell

```

### Additional context

Our server exposes both a Streamable HTTP endpoint (POST /sse) and a legacy SSE handshake (GET /sse → POST /mcp/message). Traffic logs show the client opens the GET /sse connection but all actual MCP messages (initialize, tools/call, etc.) go to POST /sse — /mcp/message is never invoked. So while an SSE connection is present, it appears vestigial; Streamable HTTP is what's actually carrying every request.

This connector is configured at the organization level in Claude.ai (Settings → Organization → Connectors), shared across multiple users, rather than added individually by a single user. The initial report of this issue came from a an end user (see ofid_38ec7cc64c35fdc0 above) — indicating this affects the org-wide connector for all users, not a single account's configuration. All other ofid_ were generated by me.