MCP Connector "Resource not found" - tools/call never reaches server

For the last ~5 days, connector calls have been failing intermittently.

A given operation works correctly several times in a row.
After some number of successful invocations, the next call suddenly fails with no response, on MCP server side I see no requests happening.
Once this issue occurs, even previously working calls to the same operation start failing in the same way, until end of the agent operation.

Interrogation of the agent reveals that is getting error in response of tool invocation:

{
“error”: “Resource not found: /…/add_node. You can retry your request with an available resource. Your available resources are: \n\n{“finite”: true}”
}

When asked agent to repeat the operation it works for a while until it starting to error in the same way again - no Connector reset/reloads required.

This bug randomly kills access to connector operations mid-session, so longer automated flows can’t be trusted to finish and often have to be completed manually. Each failure also wastes tokens on retries, re-discovery of available operations, and extra explanation/debug messages, making even simple tasks more expensive than they should be.

Im not sure if Codex CLI category matches where it actually happens. Issue Im having is on the ChatGPT Plus plan + enabled Developer mode using MCP connector. This happening even with MCP connector with no auth enabled. Is this related to the Codex CLI too? Anyone got similar issues using MCPs over CLI?

Don’t suppose you figured out what was going on? I’m having the exact same thing, wondering if it’s my end or OpenAI..

Unfortunately, I haven’t found any workaround for this. It appears to be an issue on OpenAI’s side.

Our MCP server is working correctly: every ListToolsRequest succeeds, which confirms the server is reachable and returns valid responses. However, when the agent attempts to invoke a tool, the invocation fails with “Resource not found”.

The worst part is what happens next: when this issue occurs (and it happens frequently), the agent does not stop. It keeps retrying tool invocations and burns tokens, because it assumes it’s still executing the task. In reality, due to the failure, no actions are executed on the MCP server at all.

As a temporary mitigation, I had to explicitly instruct the agent to immediately stop operations as soon as this error appears.

I agree it definitely seems like an OpenAI thing. I did notice something new today though, now when it disconnects it shows a little window within the chat wanting to reconnect, which is handy, and that just launches the same connection process but doesn’t interrupt the responses at least. Ever seen that before? I also implemented a refresh token in my OAuth implementation just incase it was that but it made no difference. I just don’t understand why there isn’t more noise about this because surely it’s affecting everyone, including approved Apps!?

Yeah, I’ve seen those authentication/reconnect popups too. For me they started showing up toward the end of 2025, around the same time as the additional tool confirmations: “Using tools comes with risks. Learn more” prompt. The annoying part is that it can’t be “remembered” for the session, so it keeps appearing again and again.

My guess is that not everyone notices this because it may depend on how frequently tools are invoked in a single session. In my case, the workflow requires multiple tool invocations in series: the agent reads files, checks documentation for specific classes, and then applies changes based on the task. When it works, it actually gives me better results than using Codex alone, but with the current “Resource not found” issues, it’s no longer a reliable workflow. Back then, I described the issue using “report bug” form, but never got any feedback.

Wonder why I’ve never seen it before, yeah for my implementation I need them to continuously interact with my tool, which does lots of round trips and then blows past the random 10-15 requests that it takes to then drop out. Hoping they fix this soon.

Hey everyone, Can someone please confirm if this is still an issue. If yes, can you please reproduce the issue on your end and use dev tools (inspect) and provide the request id from networks tab for the failing request. Once we have the request id, we can take a look and assess the root cause. Thank you!

I also am having the same problem. If I make a test prompt and ask it to call my tool 25 times, it always fails after 10-20 calls.

On the failed tool call, my MCP server does not receive any request.

I’m not sure exactly what information from the dev tools you are looking for, but here is the payload and response for the conversation. I could not include the whole response, so this is just the tool call that failed.

Also note that I have two MCP servers loaded (both of which perform similar functions and have similar names). It looks like when one tool fails, all tools from that MCP server disappear.

Conversation network request payload

{“action”:“next”,“messages”:[{“id”:“586ef8c9-3b95-4865-bb72-1ad4d654c965”,“author”:{“role”:“user”},“create_time”:1774770187.428,“content”:{“content_type”:“text”,“parts”:[“game id 19fe6691-cdb9-4736-9aee-617d04ab8221\r\n\r\nas a test, draw 25 cards one at a time”]},“metadata”:{“developer_mode_connector_ids”:,“selected_sources”:,“selected_github_repos”:,“selected_all_github_repos”:false,“serialization_metadata”:{“custom_symbol_offsets”:}}}],“parent_message_id”:“client-created-root”,“model”:“gpt-5-4-thinking”,“timezone_offset_min”:420,“timezone”:“America/Los_Angeles”,“conversation_mode”:{“kind”:“primary_assistant”},“enable_message_followups”:true,“system_hints”:,“supports_buffering”:true,“supported_encodings”:[“v1”],“client_contextual_info”:{“is_dark_mode”:true,“time_since_loaded”:942,“page_height”:1271,“page_width”:1480,“pixel_ratio”:1,“screen_height”:1440,“screen_width”:2560,“app_name”:“chatgpt dot com”},“paragen_cot_summary_display_override”:“allow”,“force_parallel_switch”:“auto”,“thinking_effort”:“standard”}

Conversation network request response

event: delta
data: {“o”: “add”, “v”: {“message”: {“id”: “1b3044f3-b120-4971-8834-c14d15cde912”, “author”: {“role”: “tool”, “name”: “api_tool”, “metadata”: {}}, “create_time”: 1774770261.345768, “update_time”: null, “content”: {“content_type”: “text”, “parts”: [“Resource not found: /mtg-auto-goldfish-turn-simulation/link_69c889d5b1848191abf6d574518badf6/draw_card_from_top.\nPlease retry your request with an available resource with api_tool.call_tool if relevant. Your available resources are: \n\n{“finite”: true}\n// Draw the very first opening seven-card hand from the stored library for an existing game ID that was created outside MCP. Call this exactly once per game, before any mulligans. Never call this after mulligan, because mulligan already shuffles and draws the replacement seven-card hand.\ntype /mtg-auto-goldfish-opening-hand/link_69c889ac360481918b1bf3dc5f989941/draw_starting_hand = (: {\n// The game ID returned by the regular HTTP create-game endpoint, not by an MCP tool.\ngameId: string,\n}) => any;\n// Return the current opening hand to the library, shuffle, and draw a fresh seven-card hand. This can only be called after the starting hand has been drawn. Important: this tool already draws and returns the replacement hand, so do not call draw_starting_hand after using this tool.\ntype /mtg-auto-goldfish-opening-hand/link_69c889ac360481918b1bf3dc5f989941/mulligan = (: {\n// The game ID returned by the regular HTTP create-game endpoint, not by an MCP tool.\ngameId: string,\n// A short explanation of why this hand is being mulliganed.\nreason: string,\n}) => any;\n// Confirm the final opening hand after all mulligans and any bottoming decisions are complete. Call this exactly once, after you have fully decided to keep and after any required bottoming has already happened.\ntype /mtg-auto-goldfish-opening-hand/link_69c889ac360481918b1bf3dc5f989941/keep_hand = (: {\n// The game ID returned by the regular HTTP create-game endpoint, not by an MCP tool.\ngameId: string,\n// The exact cards in the final kept opening hand after all mulligans and any cards bottomed to the library.\ncards: string[],\n}) => any;\n// Return multiple cards to the top or bottom of the library for an existing game ID, optionally randomizing the order they are returned in.\ntype /mtg-auto-goldfish-opening-hand/link_69c889ac360481918b1bf3dc5f989941/return_cards_to_library = (: {\n// The game ID returned by the regular HTTP create-game endpoint, not by an MCP tool.\ngameId: string,\n// The cards to put back into the library. If randomizeOrder is false, they are inserted in list order, so the last card becomes the outermost card on the chosen side.\ncards: string,\n// Which end of the library to return the cards to.\nside: “top” | “bottom”,\n// Whether to shuffle the returned cards before putting them back.\nrandomizeOrder: boolean,\n}) => any;”]}, “status”: “finished_successfully”, “end_turn”: null, “weight”: 1.0, “metadata”: {“is_visually_hidden_from_conversation”: true, “invoked_plugin”: {}, “chime_version”: 1, “request_id”: “4ed5255d-cc6f-4c3c-af4b-0e52b24991e0”, “message_type”: “next”, “turn_exchange_id”: “7cc6b0ee-e18d-49ed-ba2c-6e28bfe0197a”, “model_slug”: “gpt-5-4-thinking”, “default_model_slug”: “gpt-5-4-thinking”, “thinking_effort”: “standard”, “parent_id”: “d8c95f1b-caf7-4f43-81e4-8db54b59a723”, “model_switcher_deny”: }, “recipient”: “all”, “channel”: “commentary”}, “conversation_id”: “69c8d815-417c-83e8-a617-f8c9676dd092”, “error”: null, “error_code”: null}, “c”: 48}

Tool call list:

Asking ChatGPT why the tool call failed (this is not from the same chat that the above network request data was from):

Thought for a couple of seconds

On draw 16, the tool call failed because the previously available turn-simulation endpoint disappeared and returned a “resource not found” error.

The exact failing endpoint was:

/mtg-auto-goldfish-turn-simulation/link_69c889d5b1848191abf6d574518badf6/draw_card_from_top

The exact error text was:

Resource not found: /mtg-auto-goldfish-turn-simulation/link_69c889d5b1848191abf6d574518badf6/draw_card_from_top.

After that, I re-listed available tools, and the turn-simulation draw endpoints were no longer present.

Thank you for sharing the details. We have our engineering team take a look at this and I will update the thread soon. Thanks again!

Hey everyone, Our team is actively looking into this issue. We will soon have some updates to share. Thank you!