claude.ai hung up on a slow MCP server after 4.7 seconds, well before a cold replica could answer
claude.ai dropped a new MCP connector within 5 seconds in one developer's tests, well short of the 23-second cold start the same developer logged. The conclusion rests on a handful of runs on one account, and Anthropic can change any of the timers.
The Engineer · Build desk
Key figures: a replica took 23 seconds from being scheduled to its container running. Claude waits up to 10 seconds for OAuth endpoints, per Anthropic's docs. Pressing Connect on an existing connector gave up on a 40-second delay after 9.97 seconds.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Replica scheduled to container running | 23 seconds | 21 | |
| Claude's wait on OAuth endpoints, up to | 10 seconds | per Anthropic's authentication docs | 4 |
| Connect gave up on a 40-second delay after | 9.97 seconds | Connect on an existing connector | 3 |
What happened
- Pressing Connect on an existing connector tolerated an 8-second delay, but a 40-second delay was abandoned after 9.97 seconds.
- Anthropic documents 240 seconds for a tool call, a far longer window than the handshake got in these runs.
- A later deployment took about 22 seconds in all, and only 0.3 seconds of that fell between the container coming up and the app accepting connections.
- Microsoft's Container Apps troubleshooting page describes a 10 to 30 second first-request delay after inactivity and suggests --min-replicas 1.
Why it matters
- constraint The cold-start budget belongs to the client's timers: well under 10 seconds to survive a connect, and under 5 while a user is adding the server.
- decision On that host about 21.7 of the 22 seconds passed before the app started, so trimming application startup recovers almost none of it.
- exposure A server with its own OAuth, like the author's, can be woken by any of several requests, each on a different clock, so a cold start can fail at any of them.
The delay barely changed the outcome in the add-connector flow. claude.ai left after 4.5 seconds against a 75-second delay and after 4.7 seconds against an 8-second one [1]. The 4.7-second run ended with "Couldn't check the server." [2] The test server was a small MCP server with no auth, behind a temporary tunnel, logging to the millisecond when a request arrived and when the client hung up [19].
Anthropic's authentication docs say Claude waits up to 10 seconds for OAuth discovery, registration and token endpoints, and 30 for a refresh [4]. They do not include a number for the MCP handshake [5]. The tool-call window is longer, but a cold server has to get through the handshake first. The post's author wrote, "It's the handshake that's short." [20]
The diagnosis of the author's own server is an inference from timing. The logs show the replica scheduled at 12:50:37 and the container running at 12:51:00 [7], a gap of 23 seconds [21], with image pull taking only 2.84 of them [7]. The request that woke it could have been an OAuth endpoint or the handshake itself [8]. Unless it was a refresh, the request had about 10 seconds and the replica needed at least 23 [9]. The Connect runs tested 3, 8 and 40 seconds [3].
A slow answer does not cancel the work. With tools/list held to 75 seconds, a second round of initialize and tools/list arrived 10.5 seconds after the first tools/list [10]. Claude never hung up on the first, which stayed open until the server answered at 75 seconds [11]. A cold replica therefore keeps starting after the client has given up, and connecting again once it is up works [12].
For the numbers to transfer, your first request after idle has to land on a flow with a short window, and your platform's cold path has to run longer than that window. The rest of the sample is narrower still: one day, web only, a tunnel adding its own latency, and a test server without OAuth [13]. The 23 seconds was itself measured once, on one deployment in eastus [16].
The author's fix, one always-on replica, has a price [14]. A 0.25 vCPU replica running all month is about 650,000 vCPU-seconds, against a free grant of 180,000 when the author checked [15]. That leaves 470,000 vCPU-seconds above the grant [22]. An idle replica is billed at a lower rate, so the bill depends on how much of the month the replica sits idle. The author points readers to current pricing for their region [15].
What to watch
- Whether Anthropic publishes a timeout for the MCP handshake.
- Whether the desktop and mobile clients behave like the web client, since every run here was on the web.
- A Connect run at about 23 seconds, between the 8 and 40 tested, to show whether the author's own cold start fails there.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption
- Insufficient
- Hype gap+5
- Incentives
- Insufficient
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Adding the test server as a new connector, claude.ai gave up after 4.5 seconds when the server's delay was 75 seconds and after 4.7 seconds when the delay was only 8.
- [2]
The 4.7-second add-connector run ended with the message "Couldn't check the server."
- [3]
Pressing Connect on an existing connector: a 3-second delay was fine; an 8-second delay connected, although the UI briefly said there were no tools; a 40-second delay was abandoned after 9.97 seconds with "Couldn't reach Test Probe".
- [4]
Anthropic's authentication docs say Claude waits up to 10 seconds for the OAuth discovery, registration and token endpoints, and 30 seconds for a refresh.
- [5]
The docs do not give a number for the MCP handshake.
- [6]
Anthropic documents 240 seconds for tool calls.
- [7]
In the author's logs the replica was scheduled at 12:50:37 and the container was running at 12:51:00; pulling the image was only 2.84 seconds of that.
- [8]
The author's logs do not say which request woke the replica; it could have been an OAuth discovery, registration or token request, or the MCP handshake itself.
- [9]
Unless the request that woke the replica was a refresh, which gets 30 seconds, it had about 10 seconds, and the replica needed at least 23.
- [10]
Every Connect the author logged sends initialize and tools/list twice, about a second apart; with tools/list delayed 75 seconds, the second round came 10.5 seconds after the first tools/list.
- [11]
Claude never hung up on the first slow tools/list request; it stayed open until the server answered it 75 seconds in, so a slow request keeps running on the server after Claude has moved on.
- [12]
Connecting again once the replica is up works.
- [13]
The measurements are a handful of runs from one account on one day, on the web only, through a tunnel that adds a little latency, with a test server that had no OAuth; Anthropic can change any of it.
- [14]
Microsoft's troubleshooting page for MCP servers on Container Apps describes 10 to 30 seconds for a first request after inactivity and suggests --min-replicas 1; the author set that.
- [15]
A 0.25 vCPU replica running all month is about 650,000 vCPU-seconds and the free grant was 180,000 when the author checked; an idle replica is billed at a lower rate, so current pricing for the region should be checked.
- [16]
The author measured the 23 seconds once, on one deployment in eastus.
- [17]
When the author later deployed a new version, the app was listening 0.3 seconds after its container started, out of about 22 seconds in total.
- [18]
To keep scale to zero without a failed first connect, startup has to finish well under 10 seconds, and under 5 if it happens while someone is adding the connector.
- [19]
The author wrote a tiny MCP server with no auth that delays its answer by a set amount and logs to the millisecond when a request arrives and when the client hangs up, and put it behind a temporary tunnel.
- [20]
"It's the handshake that's short."
- [21]
The gap between scheduling and the container running was 23 seconds.
- [22]
A 0.25 vCPU replica running all month uses about 470,000 vCPU-seconds above the free grant before the lower idle rate is applied.
- [23]
About 21.7 of the roughly 22 seconds passed before the app started listening.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toHow long does claude.ai wait for your MCP server? I measured it
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Azure Container AppsFollow
- Model Context ProtocolFollow
- Serverless cold startsFollow