Connect StdioClientServer does not terminate when errors occurs.

[adamglin0]

Describe the bug

When connecting to StdioClientServer, if an error occurs in the Process, the connect method never returns and there are no error logs.

To Reproduce

RUN THIS CODE

connectFileSystemServer()
private suspend fun connectFileSystemServer() {
    val client = Client(
        clientInfo = Implementation(name = "example", version = "1.0.0"),
    )

    val transport =
        defaultStdioTransport(ProcessBuilder("npx", "-y", "@modelcontextprotocol/server-filesystem", "/fold-is-not-exists/111").start())
    client.connect(transport)

    client.listTools()?.tools?.forEach { tool ->
        println(tool.toString())
    }
}

Expected behavior
Should return immediately when an error occurs and report the error.

If we run in bash

npx -y @modelcontextprotocol/server-filesystem /fold-is-not-exists/111
Error accessing directory /fold-is-not-exists/111: Error: ENOENT: no such file or directory, stat '/fold-is-not-exists/111'
    at async Object.stat (node:internal/fs/promises:1031:18)
    at async file:///Users/adamglin/.npm/_npx/a3241bba59c344f5/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js:33:23
    at async Promise.all (index 0)
    at async file:///Users/adamglin/.npm/_npx/a3241bba59c344f5/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js:31:1 {
  errno: -2,
  code: 'ENOENT',
  syscall: 'stat',
  path: '/fold-is-not-exists/111'
}

[vprud]

If you run the server straight from the command line, it'll behave exactly as you specified. But if you run the exact same command through MCP Inspector, the client won't crash.

The SDK actually matches MCP Inspector's behavior (it's the official manual testing tool, after all).

But I totally agree this behavior isn't developer-friendly. Maybe we could add an error callback to handle this? What do you think?

[adamglin0]

If you run the server straight from the command line, it'll behave exactly as you specified. But if you run the exact same command through MCP Inspector, the client won't crash.

The SDK actually matches MCP Inspector's behavior (it's the official manual testing tool, after all).

But I totally agree this behavior isn't developer-friendly. Maybe we could add an error callback to handle this? What do you think?

MCP Inspector at least displays errors and retries. Adding an error callback seems to me to be the best way to handle it. However, the kotlin-sdk can't even display errors ATM.

[vprud]

@e5l what do you think if I create a PR to add a callback for errors? Perhaps you have some ideas on how best to implement it?

[e5l]

Hey, I think it can be a part of the DSL (both for client and server). If you need it only for logging, please consider use logging directly

[vprud]

@adamglin0 can you share implementation of the function defaultStdioTransport ?

[adamglin0]

@adamglin0 can you share implementation of the function defaultStdioTransport ?

Just a simple wrapper.

internal fun defaultStdioTransport(process: Process): StdioClientTransport {
    return StdioClientTransport(
        input = process.inputStream.asSource().buffered(),
        output = process.outputStream.asSink().buffered()
    )
}

[vprud]

@e5l hey, I’ve identified the issue and unfortunately only way to resolve it is by extending the StdioClientTransport constructor. Below, I’ll explain the problem and propose solution.

Currently StdioClientTransport only reads the stdout and stdin of the process launched for the MCP server. Errors occurring in this process are written to stderr, which is not accessible in the current implementation of StdioClientTransport.

I suggest adding an optional argument (for backward compatibility) to StdioClientTransport constructor to handle error output. Example usage:

val process = ProcessBuilder(...).start()

val transport = StdioClientTransport(
    input = process.inputStream.asSource().buffered(),
    output = process.outputStream.asSink().buffered(),  
    error = process.errorStream.asError().buffered()
)

This would allow us to read stderr when errors occur in the MCP server process and wrap the error message in an exception.

As an alternative we could redirect stderr to stdout, but this is less intuitive. The advantage is that it wouldn’t require changes to constructor’s contract.

What do you think about proposal?

[vprud]

@e5l kind remind

[vprud]

@devcrocod hi, what do you think about proposal above?