Shutdown listener?

[damien-urruty-sonarsource]

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

Hello,

When we start our MCP server in STDIO mode, we start a bunch of other services. When the stdin is closed, we need to shutdown those services. Would there be a way to listen to the shutdown via the SDK? Is this something you would consider? Or do we need to wrap stdin on our side to detect termination? We are using StdioServerTransportProvider with McpServer.sync().

Thanks

[dongyikuan919]

The SDK currently does not expose an EOF/shutdown callback from StdioServerTransportProvider. On EOF it closes the MCP session and completes its internal inbound stream, but that lifecycle signal is not public, so wrapping System.in is not necessary or especially reliable.

For a process-based STDIO server, the practical solution is to own cleanup at the application boundary and register an idempotent JVM shutdown hook:

var closed = new AtomicBoolean();
Runnable cleanup = () -> {
    if (closed.compareAndSet(false, true)) {
        serviceA.close();
        serviceB.close();
    }
};

Runtime.getRuntime().addShutdownHook(new Thread(cleanup, "mcp-cleanup"));

This covers the normal MCP client lifecycle where the parent closes stdin and then terminates the child process. Also call the same cleanup runnable from your normal application shutdown path so it works when you close the server yourself.

One caveat: closing stdin alone does not force an arbitrary Java process to exit. If your other services own non-daemon threads, your main/application lifecycle must exit after EOF (or those services must be stopped by the cleanup path). A public termination signal on the transport would make this cleaner; today the provider only exposes closeGracefully() in the opposite direction.

The EOF behavior is in StdioServerTransportProvider.startInboundProcessing.

[damien-urruty-sonarsource]

This is exactly the use case we have: our MCP server manages some non-daemon threads. A shutdown hook would not be triggered in this case. I still think we need a way to be notified that the SDK MCP server has finished

[ryux1]

You are right: a JVM shutdown hook alone does not solve this case. If stdin
reaches EOF while your services keep non-daemon threads alive, JVM shutdown has
not started, so the hook will not run.

Current main still has no public server/transport termination publisher. The
actual path is:

1. StdioServerTransportProvider reads null from its BufferedReader.
2. Its finally block calls the internal McpServerSession.close().
3. The session's onClose callback runs, but that callback is supplied
   internally by McpAsyncServer for session cleanup and is not exposed through
   McpServer.sync() or the feature builder.

Until the SDK exposes that signal, you can pass the transport a small
EOF-notifying input wrapper. Let the SDK remain the only reader; the wrapper
only observes the result of its reads:

final class EofNotifyingInputStream extends FilterInputStream {
    private final Runnable onEof;
    private final AtomicBoolean notified = new AtomicBoolean();

    EofNotifyingInputStream(InputStream in, Runnable onEof) {
        super(in);
        this.onEof = onEof;
    }

    private int observe(int result) {
        if (result == -1 && notified.compareAndSet(false, true)) {
            onEof.run();
        }
        return result;
    }

    @Override
    public int read() throws IOException {
        return observe(super.read());
    }

    @Override
    public int read(byte[] bytes, int offset, int length) throws IOException {
        return observe(super.read(bytes, offset, length));
    }
}

Pass that stream instead of System.in to StdioServerTransportProvider.
Make the cleanup runnable idempotent, and preferably have it hand work to your
application lifecycle executor rather than blocking the SDK's inbound reader
thread. Use the same cleanup routine for explicit application shutdown.

This is a workaround, not an ideal API. A public Mono<Void>/callback that
completes when the STDIO transport terminates would be appropriate, and it
should cover EOF and read failure while firing exactly once. The current EOF
implementation is here:
https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/StdioServerTransportProvider.java#L226-L273

[damien-urruty-sonarsource]

Yep, this is what I suggested in my original post, but this is a poor workaround. Please stop answering with AI-generated answers. I would happily get some feedback from the maintainers, and I'm eager to contribute if needed