Anyone else hitting 424 / TaskGroup errors when creating a custom MCP connector?

API Bugs
1

Hi all,

I’m experimenting with MCP connectors in Developer Mode and ran into something odd.

When I try to add a custom MCP connector, the ChatGPT UI fails with a 424 error:

{“detail”:“unhandled errors in a TaskGroup (1 sub-exception)”}

On my side:

  • My MCP server is public and healthy.

  • It responds correctly to initialize, tools/list (with both “search” and “fetch”), and tools/call.

  • Responses are valid JSON-RPC 2.0 and match the MCP docs.

  • Curl checks all return 200 OK.

  • Logs show no new requests at the moment the 424 appears, so it seems to fail in the validator before hitting the server.

Has anyone else seen this recently? Curious whether this is a known validator issue or if there are hidden handshake requirements not in the docs.

Thanks!

2

I’m having the same issue - did you ever figure out what was going on here?

3

+1. Did you figure it out?

4

Runnig into the same issue, testing around with the my mscp server. But surprisinglly the call to the mcp server was retried with identical params and then it succeeded. Could not find anything in the logs but the

mcp_protocol_error

424: unhandled errors in a TaskGroup (1 sub-exception)
5

Same here

{“type”:“http_error”,“code”:424,“message”:“424: unhandled errors in a TaskGroup (1 sub-exception)”,“is_error”:true}

MCP inspector returns results correctly though.

6

I solved this 424 issue after having it all day. I tried everything with chatgpt and what I learned is that this error means it can be anything. that’s why you will see a lot of solutions to this error and maybe none will work for you.

in my case it was the response my server was giving to the “initialize” method , that comes before the “tools/list” method. I had it but openai didnt like it for some reason.

here is the final vertion of the response to initialize:

return response()->json([ ‘jsonrpc’ => ‘2.0’, ‘id’ => $id, ‘result’ => [ ‘protocolVersion’ => ‘2025-03-26’, ‘capabilities’ => [‘tools’ => [‘listChanged’ => false]], ‘serverInfo’ => [‘name’ => ‘rosify-mcp’, ‘version’ => ‘1.0.0’], ], ], 200, [‘Content-Type’ => ‘application/json’]);

7

I’ve been struggling with this issue for several days, and it turns out the problem wasn’t in my code at all.
While inspecting the browser’s network traffic, I noticed something interesting:

Before showing the error message
{ "detail": "unhandled errors in a TaskGroup (1 sub-exception)" },
ChatGPT doesn’t even send a request to my MCP server.

Then, right afterward, I see another response:
{ "detail": "Must use workspace account for this operation" }.

For context, I’m a Plus user, and I started trying to add a custom MCP server after the Apps SDK was announced.

8

I was able to solve this problem, so here’s a solution for posterity.

I hit the same generic error when calling tools through ChatGPT:

ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)

The MCP server itself was healthy, the Secure MCP Tunnel was connected, and ChatGPT could discover the connector and its tools. However, every tool call failed. ChatGPT sometimes presented this as an expired connection, which made it initially look like an authentication or tunnel problem.

The issue was MCP resource discovery. ChatGPT calls resources/list while initializing or using a connector. My server registered tools but did not register any resources. Adding one valid, readable resource fixed every tool call immediately:

server.registerResource(
  "campaign-tracker-about",
  "campaign://tracker/about",
  {
    title: "Campaign tracker information",
    description: "Identifies this MCP server and its purpose.",
    mimeType: "text/plain",
  },
  async (uri) => ({
    contents: [{
      uri: uri.href,
      mimeType: "text/plain",
      text: "Live campaign tracker.",
    }],
  }),
);

The important details were:

  • The resource had a valid URI: campaign://tracker/about.
  • The URI returned by the read callback matched the registered URI.
  • The advertised and returned MIME types matched.
  • Both resources/list and resources/read were tested directly afterward.

I also added this regression test:

const resources = await client.listResources();

assert.deepEqual(
  resources.resources.map((resource) => resource.uri),
  ["campaign://tracker/about"],
);

const about = await client.readResource({
  uri: "campaign://tracker/about",
});

assert.match(about.contents[0].text, /Live campaign tracker/);

After restarting the MCP server and refreshing the ChatGPT connector, get_current_location and the other tools began working through the same tunnel and authentication configuration.

Environment:

Node.js v25.8.0
@modelcontextprotocol/server 2.0.0
@modelcontextprotocol/node 2.0.0
@modelcontextprotocol/client 2.0.0
OpenAI Secure MCP Tunnel

I cannot see the nested exception that ChatGPT swallowed, so I cannot prove the precise internal cause. However, adding a valid resource catalog was the only material server-side change, and it changed the connector from consistently failing to consistently working. A more specific error mentioning resources/list or resource registration would have made this substantially easier to diagnose.