Custom MCP connector: intermittent "The connector's server isn't responding" on claude.ai, succeeds on retry with identical parameters

### What happened?

Tool calls to the Custom Avoma MCP connector on claude.ai fail intermittently with a generic client-side error, then succeed seconds later on retry with the exact same tool, parameters, and session — no changes made in between. This matches the pattern already reported in #154, #49910, and #394 (brokered/remote MCP call dropped or timed out between claude.ai's broker and a healthy remote server). Filing separately since this reproduces against a custom (self-added) remote MCP connector pointed at Avoma's MCP endpoint, not one of claude.ai's built-in/first-party connectors.

Environment
Surface: claude.ai (web)
Connector: Avoma MCP — custom connector added via Settings → Connectors (remote MCP, mcp.avoma.com), OAuth-based, not a built-in claude.ai connector
Tool called: List Meetings (also seen on Get Meeting Notes in a separate session)
Model: Claude Sonnet 5
Date/time of capture: [FILL IN — e.g. 2026-07-16, ~10:05 AM IST]
What happened
First call to List Meetings → fails:

{"error": "The connector's server isn't responding. You can try again.", "request_id": "req_011Cd57Z5kY5wvgymmhDqDy5"}

Claude retries the same tool call with the same parameters → fails again (result shown as generic "Result" error in UI, no new detail).
Third attempt, same tool, same parameters → succeeds and returns data normally.

No parameters changed between attempts. No reconnection or re-auth was performed by the user between attempts.
Evidence this is not an Avoma-server-side issue
Retrying the identical call within seconds succeeds — rules out bad parameters, auth expiry, or a genuinely down upstream server (which wouldn't self-heal in seconds without intervention).
The failure message is the generic client-side wrapper ("connector's server isn't responding... you can try again"), not a passthrough of any Avoma-side error body — indicating the timeout/drop happens between claude.ai's broker and the Avoma MCP server, not inside Avoma's server logic itself.
This matches the exact shape of prior reports where server-side logs show a successful response while the claude.ai client reports a failure (see #154, #49910: server responded in <10ms, client still reported a timeout).

### What did you expect to happen?

Claude should successfully execute the Avoma tool call (e.g. List Meetings) without any client-side error. Since the identical call — same tool, same parameters, same connector session — succeeds moments later with no reconnection or configuration change in between, the Avoma server itself is clearly healthy and responsive throughout. The expected behavior is either the call succeeding on the first attempt, or, if a transient timeout genuinely occurs, an automatic retry on Claude's side before surfacing an error to the user — rather than requiring the user to manually retry a failed call that had no real server-side problem.

### Steps to reproduce

Open a claude.ai conversation with the Avoma MCP connector enabled.
Ask Claude to list upcoming meetings (or any Avoma tool call).
Observe intermittent failure with {"error": "The connector's server isn't responding...", "request_id": "..."}.
Ask Claude to retry the identical call.
Observe it may fail once or twice more, then succeed with no configuration change.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

custom connector

### Error messages or logs

```shell
{"error": "The connector's server isn't responding. You can try again.", "request_id": "req_011Cd57Z5kY5wvgymmhDqDy5"}
```

### Additional context

Frequency
1 in every 5 request is hampered

Related issues
#154 — Remote MCP tools fail with "Error occurred during tool execution" on claude.ai while server returns 200 (closed as not planned)
#394 — Broader writeup grouping brokered remote-MCP failures (200 server-side / opaque client error)
anthropics/claude-code#49910 — Remote MCP tool calls dropped at 60s client-side despite server responding in <10ms (~25% observed failure rate, retries within seconds usually succeed)

Impact
Disrupts any workflow relying on the Avoma MCP connector for real-time meeting/CRM data retrieval — requires manual retries and erodes trust in connector reliability, especially in agentic/automated flows where a human isn't present to notice and retry.