MCP connector: intermittent tools/call loss + misleading "Reconnect" error text generates false-positive bug reports against MCP server vendors

Cross-references: #469 (customer-side view, still open), #744 (same misleading-error pattern, different trigger), #575 (same "request never arrives at server" signature, closed as not-planned).

## Summary

Claude Desktop's MCP connector transport is intermittently dropping `tools/call` requests before they reach the target MCP server. The two client-facing error strings and the connector-panel prompt all point users at the connector / the MCP server (implying vendor fault), never at the transport. Result: MCP server vendors are receiving false-positive bug reports, spending support cycles on phantom defects, and are one review-cycle away from unearned 1-star reviews.

We are the publisher of Royal MCP, an on-plugin MCP server for WordPress with 1k+ active installs. This report is filed with vendor-side evidence a single customer would not typically produce — full server-log correlation, second-site confirmation, and mathematical rule-out of rate limiting.

## The two symptom strings, one underlying condition

Same tool, called twice in succession with nothing changed between calls, has been observed to return one of each:

```
This connector requires additional permissions. The user needs to reconnect it
with the appropriate access.
```

```
Connection closed
```

Simultaneously, the connector panel shows:

```
Can't reach [connector] right now — it may need to be reconnected. [ Reconnect ]
```

The em dash is U+2014 (rendered as `—` here). Codebase searches should use the em-dash form.

The connector recovers on its own within seconds. Clicking Reconnect is not required for recovery and burns OAuth state for no reason.

*Screenshot above: both surfaces at once during a diagnostic session — in-conversation text and the connector-panel `[Reconnect]` prompt appearing together. Six `wp_get_option` calls issued in a burst: 3 succeeded, 3 returned the error. The "RoyalMPC" label is the connector name the operator configured in Claude Desktop; the endpoint is Royal MCP.*

## Server-side proof the requests never arrive

A Royal MCP user, Art of We Build Websites (cited with permission), ran a controlled 52-call diagnostic on 2026-08-01 against a production WordPress site and reconciled his client-side call record against Royal MCP's built-in Activity Log line by line.

**Whole-session totals:**

| Measure | Value |
|---|---|
| Tool calls issued | 52 |
| Returned an error to the client | 21 |
| **Client-side loss rate** | **40.4%** |
| Distinct tools affected | 8 |

**Per-tool correlation:**

| Tool | Calls issued | Succeeded on client | Rows on server |
|---|---|---|---|
| `wp_update_seo_meta` | 7 | 2 | **2** |
| `wp_get_seo_meta` | 5 | 3 | **3** |
| `royal_mcp_connection_health` (single window) | 4 | 2 | **2** |
| `wp_create_post` | 1 | 1 | **1** |
| `wp_get_pages` | 1 | 1 | **1** |
| `wp_get_option` (window A, 21:29–21:31) | 11 | 7 (4 ok, 3 refused) | **7** |
| `wp_get_option` (window B controlled trial, 21:38) | 16 | 11 | **11** |

**In every case, server log count equals client success count. It never equals the issue count.**

## The load-bearing detail: ERROR rows

Royal MCP's Activity Log records genuine rejections (option allowlist refusals) as ERROR rows alongside SUCCESS rows. Three ERROR rows appear in the 46-row export. **This rules out "the log only writes on success."** A missing row can only mean the request never arrived.

*Screenshot above: Activity Log page 2 of 3 — Session A (21:20–21:31). Three ERROR rows on `wp_get_option` (allowlist refusals) interspersed with SUCCESS rows. Requests the client reported as failed appear on no page of this log.*

## The single clearest illustration

Rows 14/15/16 of Session C were issued as one parallel batch of three:

- Row 14: `wp_get_seo_meta` for post 11 → **arrived, succeeded**, full field set returned
- Row 15: `wp_update_seo_meta` title-only → **arrived, succeeded**, write confirmed by read-back
- Row 16: `wp_get_option` for `blogname` → **lost**, no server row, client returned "permissions error"

The one that vanished was the simplest read in the entire session — a whitelisted core option requiring no elevated capability. Two batch-siblings including a WRITE arrived and succeeded. No permission model produces that outcome. A lossy transport does.

## Controlled trial rules out rate limiting, caching, dedup

Session B: 16 calls to `wp_get_option name: "blogname"` (identical arguments) in a single minute:

| Mode | Issued | Arrived | Lost | Outcome order |
|---|---|---|---|---|
| A (parallel batch of 6) | 6 | 4 | 2 | OK, LOST, OK, LOST, OK, OK |
| B (parallel batch of 6) | 6 | 4 | 2 | OK, LOST, LOST, OK, OK, OK |
| C (sequential singles) | 4 | 3 | 1 | OK, LOST, OK, OK |
| **Total** | **16** | **11** | **5** | **31.3% lost** |

- **Losses fall mid-batch, not at the tail.** A rate ceiling hit mid-burst would fail the tail; positions 2/4 and 2/3 fail instead.
- **Identical concurrent calls returned different outcomes inside a single batch** — no response caching or dedup in play. Every call genuinely entered the transport.
- **Rate limit ruled out mathematically.** Royal MCP enforces 60 req/min per IP. Heaviest sampled window: 13 requests over 19 minutes. Independently, missing requests never arrived to be counted.

## Independent confirmation, second site

Same reporter, different site: `webuildwebsites.ca`, Royal MCP 1.4.37, Divi 4. Single tool, identical arguments. Client-side only.

| Mode | Issued | Lost | Loss rate |
|---|---|---|---|
| Concurrent, two bursts of six | 12 | 5 | **41.7%** |
| Isolated singles, 40 seconds apart | 6 | 1 | **16.7%** |

A third site (Divi 4.27.7, Royal MCP 1.4.38) exhibited the identical failure pattern. Neither Divi version nor plugin build is a variable. **Spacing calls out reduces loss by roughly two-thirds but does not eliminate it. Agents issue tool calls in parallel batches by default, so the amplifier is engaged in ordinary use.**

## Why the vendor angle matters

Before running the reconciliation, the reporter had drafted four defect findings against Royal MCP based on client-side symptoms — OAuth grant issues, Divi 5 incompatibility, PHP fault in theme introspection, and a `wp_update_permalink_structure` connection-drop. **All four dissolved once the server log was consulted.** In his words: *"we were being careful."*

Most users won't have a server-side log to check, and the review will be written before anyone thinks to look. Every MCP server vendor with Claude Desktop connector traffic is on the receiving end of this class of bug.

## Environment (reporter's primary site)

| Item | Value |
|---|---|
| MCP endpoint | Streamable HTTP, `/wp-json/royal-mcp/v1/mcp` |
| Royal MCP | 1.4.38 |
| WordPress / PHP | 7.0.2 / 8.3.30 |
| Auth | `oauth-bearer`, `scopes: ["tools"]`, sole admin user |
| Client | Claude Desktop on Windows 11, native connector (NOT `mcp-remote` stdio bridge) |
| Session stability | `session_id` byte-identical across successful probes bracketing failures; `token_ttl` counted down normally |
| OAuth reference (traceable at Anthropic's end) | Failed reauth on 2026-07-31 carried reference `ofid_f0808340d1b8604b`. Reconnect required 5 attempts. |

## Ask

1. **Fix the transport layer** so `tools/call` requests don't drop intermittently. Root cause TBD from Anthropic's side.

2. **If (1) is longer:** rewrite the error strings to reflect the actual failure mode. Neither "requires additional permissions" nor "Connection closed" is what happened — the request was dropped in transit. Something like `Connection interrupted — retrying automatically` would eliminate the false-positive vendor bug-report cycle even if intermittent loss persists. The `[Reconnect]` prompt is actively harmful — it directs users to burn OAuth state on a non-issue.

3. **A public status / known-issue acknowledgment** MCP server vendors can link customers to. Every vendor is currently answering these tickets from scratch. A canonical Anthropic-side URL turns 30-minute responses into 30-second ones.

## Evidence provenance

- Full 46-row Activity Log JSON export + timestamped client-side call record available on request.
- Reporter (Art Boyle, We Build Websites) has offered repeat testing across three production sites on two Divi majors + a live news site being built from scratch that will exercise the article workflow at volume.
- We (Royal Plugins) have shipped a wp.org pinned support post and a docs page walking users through the Activity Log diagnostic so they can distinguish transport-loss from real Royal MCP errors — happy to link back to any Anthropic acknowledgment.

## Contact

- Royal Plugins (publisher of Royal MCP): hello@royalplugins.com
- Original diagnostician (with permission to cite): Art Boyle, We Build Websites — webuildwebsites.ca