When an Operation is changed in Explorer and synced to MCP server, the MCP server can no longer serve requests

MCP Server
1

Seeing something a bit wonky when using explorer to manage and update MCP tools in the Apollo MCP server. running v1.6.0. When an Operation is changed in Explorer and synced to MCP server, the MCP server can no longer serve requests.

Steps to reproduce:

  1. Set up an operation in explorer to sync to MCP
  2. Start MCP server
  3. Edit the operation and save it
  4. wait for it to sync
  5. request to that tool fails
1 Like
2

Thanks for reporting the issue and sharing the detailed steps, @mjfaga! We were able to replicate the problem. A collection sync error is being treated as fatal when it shouldn’t be, which is causing the server to crash even though it was healthy and handling traffic. We’re working on a fix, and I’ll keep you updated.

3

Awesome, thanks for taking a look and jumping on it!

1 Like
4

Hang gang - any update on this. Would be happy to help test an RC if you guys want to send me an image reference.

1 Like
5

Hi @mjfaga, I just cut an RC for you. You can pull the image:

docker pull ghcr.io/apollographql/apollo-mcp-server:canary-20260213T211530Z-a65567d

Let me know if this solves your issue. If it works, we will schedule a release for next week.

6

Doesn’t seem fully functional yet. I can see the tools reloading, but the MCP still becomes unresponsive…

When I asked a follow up after a tool refresh, I saw this error:
{“code”:401,“type”:“http_error”,“message”:“Received error from MCP server: Unauthorized: Session ID is required”}

And a second follow up, I got this error:
{“code”:424,“type”:“http_error”,“message”:"424: "}

In a brand new conversation, it also just fails.

In datadog, I see these two logs only after initial load, not after the refresh. Not sure if that is relevant or not:

CleanShot 2026-02-13 at 18.43.52@2x
CleanShot 2026-02-13 at 18.43.52@2x2154Ă—130 30 KB

7

Thanks for the follow-up! It’s great that you’re seeing the tools reload, which means the server is handling the sync properly now. However, the session errors you’re experiencing seem to be a different issue.

The Session ID is required error indicates that the MCP client is losing its session after it gets the tool list change notification. I think this was previously hidden by the crash. When the server went down, the client would reconnect with a new session. Now that the server is stable and sending notifications, the client needs to manage it without dropping the session.

I have a couple of questions that could help us narrow this down:

  • Which MCP client are you using?
  • Can you share the server logs from around the time of the tool refresh? I’m specifically looking for any Failed to notify peer messages.
  • Are you running with stateful_mode: true in your transport config?
8
  • I’m testing with Claude Desktop, as well as an OpenAI agents on our server (via hostedMcpTool w/Agent class).
  • Didn’t see anything like that. I can send you the DEBUG log output from the MCP after reproducing if it will help? Maybe you will see something. Let me know where to send it.
  • Yes, using stateful_mode: true, as it’s the default and we don’t currently override it.
9

I did some more digging on my side as well… I’m going to disable stateful_mode for now. Seems like there isn’t an option to take the in-memory state that is associated with that and stick it in an external store to avoid losing the memory on restarts/deployments?

Also - I noticed that JSON output makes a ton of noise in logs… i don’t see a configuration for being smarter about how JSON is logged (a single log vs. multiple lines when writing to SDOUT) A m I missing something there?

10

One more thing - when I disable stateful_mode and set it to false, I don’t have these problems, which makes sense given what we are seeing.

This has effectively resolved my issues. Happy to close this out if you want?

1 Like
11

Glad to hear that resolved it! You’re right that stateful_mode: false sidesteps the session issue. The stateful session state is purely in-memory which provided by the underlying MCP SDK, so it won’t survive restarts or deployments and there’s no external store option currently.

On the logging. You’re not missing anything. There’s no compact or structured JSON format option today. Setting logging.level: info instead of debug should cut out most of the verbose output.

Thanks for the thorough testing and follow-ups! It really helped us nail down the original crash.

1 Like