MCP Server passes all JSON-RPC tests but Agent Builder fails with 424 (“Failed Dependency”)

Hi! I’m experiencing a persistent 424 “Failed Dependency” error when connecting my custom MCP server to Agent Builder.

All JSON-RPC tests (initialize, notifications/initialized, tools/list, tools/call) pass successfully via curl, and the server is fully compliant with protocol version 2025-06-18.
However, inside Agent Builder, the UI never reaches my endpoint — the network log shows repeated calls to
https://api.openai.com/v1/dashboard/responses/mcp/list_actions424 (Failed Dependency).

You can verify the server here:
:link: https://invoicereader-production-fod.up.railway.app/debug/last

Based on community threads, this seems to match the known “424 TaskGroup” bug in Agent Builder where the dashboard’s internal list_actions phase fails even though the MCP handshake succeeded.

The problem is not reproducible via API / curl, only within the Agent Builder UICould you please confirm if this is a known dashboard-side issue or a change in how Agent Builder expects to retrieve the tool list (list_actions vs tools/list)?

Thank you!

3 Likes

Hi @FRobledoRuiz Welcome to the forum!

I think this is related to a known issue, please see this github post with a solution

1 Like

I think it’s an issue within the GUI itself, I will make sure it’s raised again though.

1 Like

Thanks a lot! I will see the link and the solution.

Best regards

I’ve conducted some additional tests, and it appears that the problem indeed lies within the GUI. It would be helpful if this case could be reviewed or reopened for further investigation.

1 Like

Hello! We're looking into this, but in the meantime, we've found this is tied to streamable HTTP session lifecycle, and that setting stateless_http=True is the current workaround. Let me know if that works for you.

2 Likes

We’re using stateless_http=True and still seeing this problem (occasionally - maybe 1 in 25 tool calls) with the agent-builder workflow we’re trying to use from our chatkit-based app.

server has mcp==1.16.0, fastmcp==2.12.4 and is behind an openresty LB