How to Properly Clean Up Application State When Server Disconnects or Closes? (STDIO)

[Mr-Yaya]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Hi all,

I’m working with the Go SDK and the MCP protocol, and I’m trying to ensure my application state is properly cleaned up when the server disconnects or closes. Here’s a simplified version of my code:

func (s *Server) Run() error {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	serverErrChan := make(chan error, 1)
	go func() {
		serverErrChan <- s.Server.Run(ctx, &mcp.StdioTransport{}) // Run using the mcp go sdk
	}()

	s.start3pApplication()
	defer s.stop3pApplication()

	exitChan := make(chan os.Signal, 2)
	signal.Notify(exitChan, os.Interrupt, syscall.SIGTERM)

	select {
	case <-exitChan:
		return nil
	case err := <-serverErrChan:
		if err != nil && err != context.Canceled {
			return err
		}
		return nil
	}
}

Problem:
When I run this with go run and hit Ctrl+C, everything works as expected: stop3pApplication is called and cleanup happens.
However, when I run the same code via Claude Desktop or the MCP Inspector, stop3pApplication is never called. I suspect these tools are handling disconnects differently (not sending a signal?), so my cleanup code in defer isn’t triggered.

Question:

• How can I reliably detect when the connection is closed or the server is disconnected, especially in these environments?
• Is there a better way to ensure that stop3pApplication is always called, regardless of how the server is stopped/disconnected?
• Are there any best practices or examples for handling cleanup in this kind of context/protocol setup?
  Any advice or pointers would be greatly appreciated!

[cananoo]

For a stdio server, the reliable lifecycle signal is the transport closing (usually EOF/read error), not a signal from the MCP client. Claude Desktop and MCP Inspector do not need to send SIGINT; when they close the stdio connection, Server.Run should return. The current SDK documents Server.Run as blocking until the client terminates the connection or the context is cancelled.

You can therefore keep the application lifecycle directly around Server.Run:

func (s *Server) Run() error {
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer stop()

    if err := s.start3pApplication(); err != nil {
        return err
    }
    // Make this idempotent: it may also be called from an application-level
    // shutdown path.
    defer s.stop3pApplication()

    err := s.Server.Run(ctx, &mcp.StdioTransport{})
    if errors.Is(err, context.Canceled) || errors.Is(err, io.EOF) {
        return nil
    }
    return err
}

This removes the extra goroutine and select: cleanup runs when Run returns for either a client-side stdio close or a signal-driven context cancellation. Also make stop3pApplication safe to call more than once and pass the handler ctx to any per-request work so that in-flight work can stop when its request is cancelled.

If the peer keeps stdin open but simply stops sending messages, stdio has no protocol-level disconnect event, so no implementation can detect that immediately. In that case use an application-level timeout/heartbeat only if it matches your server semantics; do not use a short idle timeout for normal MCP clients.

Relevant SDK code: Server.Run, StdioTransport, and the hello stdio example.