pls provide a private way to send the HAR, or send me a dm and I’ll provide a link.
Heres a better report, also a workaround.
In ChatGPT Developer Mode, MCP tools may be advertised using link-scoped routes such as:
/<connector>/link_<id>/<tool>
Those advertised routes can later fail with:
Resource not found: /<connector>/link_<id>/<tool>
even though the equivalent native route:
/<connector>/<tool>
continues to work for the same tool call.
Observed behavior suggests the issue is not just “the link ID changed.” Instead, the host appears to maintain a deeper connector dispatch/session state behind visible MCP routes. Link-scoped routes are the unstable layer: they can become non-dispatchable, recover later, or be replaced by a freshly advertised linked route, while the native route remains usable throughout.
Expected behavior
If a route is advertised as callable, it should either:
- dispatch successfully, or
- return a normal backend/tool-level error.
If the link-scoped form is not reliably dispatchable, it should not be exposed as the primary callable route. The host should either:
- expose only the native route, or
- normalize the linked form to the native form before dispatch.
Actual behavior
The advertised linked form may work initially, then later return:
Resource not found: /<connector>/link_<id>/<tool>
with no corresponding backend request IDs for the failing call.
At the same time, the equivalent native route:
/<connector>/<tool>
can still work normally and return backend IDs.
What was observed
Across repeated sessions and many direct tool calls, the following patterns were reproduced:
-
Linked route healthy, then stale
- A link-scoped route is advertised and works for multiple calls.
- Later, the same visible linked route starts returning
Resource not found.
-
Failure occurs before backend dispatch
- Successful calls have normal backend
request_id / event_id.
Resource not found calls do not.
-
The same visible linked route can fail and later work again
- So visible
link_<id> identity alone is not the true unit of validity.
-
Native/linkless routes remain usable during linked-route failure windows
- The direct/native route
/<connector>/<tool> continues to work while the linked route is dead.
- This held for both cheap/readiness calls and auth-required read-only calls.
-
A fresh linked route can be republished while native routes are already healthy
- New linked routes may appear during the degraded window.
- Sometimes a newly advertised linked route is immediately usable.
- Sometimes it is visible before it is actually dispatchable.
-
Repeated linked-route failures may escalate into auth/approval challenges
- The auth challenge is not always the first symptom.
- In observed runs, one or more linked-route failures could occur first.
- Accepting the challenge can correlate with a fresh linked route being issued.
Most likely issue
This looks like a host-side mismatch between:
- the advertised route surface, and
- the currently dispatchable route surface.
The evidence fits a model where:
- native routes are the stable dispatch surface,
- linked routes are ephemeral session bindings layered on top,
- and those linked bindings can become invalid independently of the visible route string.
In other words, the problem appears broader than simple visible link_<id> churn. A linked route may:
- go stale,
- later recover,
- be replaced by a fresh linked route,
- or trigger auth escalation after repeated failure.
Impact
This causes the host to advertise tool routes that are not reliably callable. From the user/tooling side:
- the tool appears available,
- the published linked path may fail pre-dispatch,
- the equivalent native path may still be healthy,
- and repeated use of the linked path may trigger unnecessary auth/reconnect flows.
Practical workaround
Normalize any advertised linked route of the form:
/<connector>/link_<id>/<tool>
to the native route:
/<connector>/<tool>
before dispatch.
In observed cases, using the native route avoided the stale linked-route failure.
Suggested area to investigate
- link-scoped MCP routes are being advertised even when only the native route is actually dispatchable,
- route publication and route dispatch readiness are derived from different internal states,
- repeated failures on stale linked routes are incorrectly feeding into downstream auth/approval logic.
ChatGPT UI - 