MCP Inspector displays unnecessary error output even when FastMCP connects successfully

[harshpreet931]

Description

When starting the STDIO server with FastMCP, MCP Inspector displays an error in the terminal even though the connection is established successfully and tools work as expected.

This appears to be misleading, since the error output suggests a failure, but the server is functioning correctly.

Observed Behavior

• STDIO server starts normally
• MCP Inspector shows an error message in the terminal (screenshot below)
• Despite the error, FastMCP connects and tools are callable

Example Code

from fastmcp import FastMCP

mcp = FastMCP(name="StdioExampleServer")

@mcp.tool
def echo(message: str) -> str:
    """Echoes the provided message back to the client."""
    return f"You said: {message}"

@mcp.tool
def api_fetch(url: str) -> str: 
    """Fetches data from the provided URL."""
    import requests
    response = requests.get(url)
    return response.text if response.status_code == 200 else f"Error fetching {url}: {response.status_code}"

if __name__ == "__main__":
    mcp.run()

Version Information

MCP Inspector version:                                                                       0.16.5
FastMCP version:                                                                                 2.11.3
MCP version:                                                                                        1.13.0
Python version:                                                                                    3.12.11
Platform:                                                                     macOS-15.6-x86_64-i386-64bit
FastMCP root path: /Users/harshpreet.singh/Desktop/Projects/MCP_Examples/venv/lib/python3.12/site-packages

[olaservo]

Hi @harshpreet931 , I think that this is because the STDIO uses the stderr output for any logging, even if its not technically an error being logged? So it all shows up as 'red' even if its not failing.

[harshpreet931]

Thanks for the clarification, @olaservo. I understand that stderr is being used for logging, but it seems to be mixing successful connection messages with actual errors. Could you help me understand why this happens, and if there’s a recommended way to distinguish between normal logs and real errors?

[olaservo]

@harshpreet931 I think one way to differentiate would be for the message to include some consistent prefix to clearly indicate the actual log level, eg prefixing what gets logged with [INFO] vs [ERROR], then when stderr gets logged we could try to match based on that.

[cliffhall]

@harshpreet931 I think one way to differentiate would be for the message to include some consistent prefix to clearly indicate the actual log level, eg prefixing what gets logged with [INFO] vs [ERROR], then when stderr gets logged we could try to match based on that.

Just an observation: if the messages were sent as JSON-RPC logging messages rather than output to stderr they would not appear here, but rather in the server notifications field. I think we need to encourage this behavior in stdio servers vs stderr where possible.

[cliffhall]

Closing, as this isn't actually an issue, it's behavior of FastMCP writing to stderr instead of logging.

[strawgate]

The logging notifications serve a different purpose than writing to stderr as logging notifications are meant to land at the client and are thus inappropriate for a number of logging use-cases.

Writing logs to stderr is the standard for logging.

It seems like MCP Inspector should perhaps place the logs into a server logs section and elevate the recent logs in the UI if the process exits with a non-zero exit code.

For an other example, i believe the GitHub MCP Server logs GitHub MCP Server running on stdio to stderr on startup

[harshpreet931]

@strawgate That makes perfect sense! Having a dedicated "server logs" section in MCP Inspector with elevated visibility for errors (non-zero exit codes) would be the ideal solution. This would preserve the standard stderr logging behavior while making the UI more intuitive for users.

@cliffhall While I understand this isn't technically a bug in FastMCP, from a user experience perspective it's quite confusing when successful connections appear as errors. strawgate's suggestion would address this at the MCP Inspector level without requiring changes to how servers handle logging.

[cliffhall]

Having a dedicated "server logs" section in MCP Inspector with elevated visibility for errors (non-zero exit codes) would be the ideal solution. This would preserve the standard stderr logging behavior while making the UI more intuitive for users.

There's already a section for server logs, it's just shown in red because it comes from stderr.

with elevated visibility for errors (non-zero exit codes)

I don't think this is possible, it's all just strings output to STDERR.

AFAIK, there's no way to distinguish between...

• console.error("Welcome to my great product")
  ...and...
• console.error("Oh, my. We seem to have had a catastrophic failure.")

@harshpreet931 @strawgate
I'll work on this. I have some other related changes to make anyway.

[strawgate]

I actually meant that when the process exits with a non zero exit code that could be the time to present the log information in a more "in your face" kind of way.

I.e.. The logs exist in a logs tab until the process exits with a non zero exit code and when that happens the location below the connect button shows the most recent log messages or perhaps a link "the process exited unexpectedly. See recent logs..."

[cliffhall]

I actually meant that when the process exits with a non zero exit code that could be the time to present the log information in a more "in your face" kind of way.

@strawgate It's just strings on stderr there's no exit codes. Currently StdioClientTransport swallows the error code so it's not something that can be captured in our proxy and sent to the client.

We can try to detect specific output and send a leveled logging message to the client like we do here, but it has to be something common:

[cliffhall]

Okay, folks. Here's the PR.

Turns out, there's not going to be a separate tab / panel for stderr output.

The way those messages were being differentiated from normal logging notifications on the client was that there was an out-of-spec message type being used to send them (notifications/stderr instead of notifications/message). My other related change was planning to make was to remove support for that invalid message type.

The only way to communicate with the client is via JSON-RPC messages, and the valid type for logging is what I'm sending. I am, however, inspecting the message, so if it includes an RFC 5424 Syslog Protocol level, it will be sent with that level.