[MCP] Hosted MCP endpoint intermittently fails on fresh sessions (-32000 / -32602)

Data Access mcp
1

Hi Open Targets team,

First of all, we really appreciate the MCP offering in the first place; it’s a helpful way to work with Open Targets programmatically!

We’ve run into intermittent issues with the hosted MCP endpoint (https://mcp.platform.opentargets.org/mcp) and wanted to report them.

Using a minimal MCP client outside of Codex, we see:

  • slow connect() times (~20–30s)

  • sometimes slow listTools()

  • inconsistent behavior across repeated fresh-session runs:

    • success in some runs

    • MCP error -32000: Rate limit exceeded for client: global in others

    • MCP error -32602: Invalid request parameters during connect/init in others

We also tested the same MCP server locally with the same client and request pattern. Local runs are fast and stable, including repeated fresh-session tests and search_entities calls.

That makes us suspect this is more likely related to the hosted deployment / rate-limiting / session-init path than the server implementation itself.

Happy to share a minimal repro and logs if that would help.

Thanks!

Tobias Tilly

1 Like
2

Hi Tobias!

Thanks for the feedback on this. Ye, we’re struggling a bit with hard limits on Google’s Cloud Run instances.

We’ve made some changes in there, could you give it another try and report back?

2 Likes
3

Hi Javi,

Thanks for the update. We gave it another try, and things do look better with the Open Targets MCP.

In our latest tests, the public MCP endpoint was reachable and manual Streamable HTTP MCP requests worked for initialize, tools/list, and tools/call. So from what we could tell, the Open Targets MCP itself was responding correctly for the basic MCP flow.

The issue we still hit seems to be specific to Codex’s MCP client startup (connection closed: initialize response), rather than a general outage of the Open Targets MCP. We found similar Codex reports against other remote MCP servers as well, and Codex’s own issue tracker notes that Streamable HTTP currently relies on an experimental Rust MCP client, so there may still be some rough edges there.

We did still see one Rate limit exceeded for client: global response on a follow-up query, but that looked separate from the handshake/startup issue.

So overall, this does seem improved from our side. If compatibility with Codex and other agent clients is something you’d like to support over time, it may still be worth doing an interoperability pass on the MCP transport/lifecycle behavior, but I wouldn’t describe what we’re seeing now as a general endpoint failure.

Thanks again for taking a look at it.

All the best,

Tobias

4

Thanks for reporting back!

I’ll forward that Codex issue to the person in charge of the MCP for them to take a look at it.