You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had to run docker run -i (interactively), and then paste {"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}} and press enter (push it to stdin of the process)... After which it sends the response to stdout:
root@mcp-test:~/servers# docker run -i --rm -v $PWD:/projects mcp/filesystem /projects
Secure MCP Filesystem Server running on stdio
{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}
{"result":{"tools":[{"name":"read_file","description":"Read t
...
The next mission (not that anyone cares...) is to figure out how to run this remotely as a proper MCP server.
The MCP Filesystem server is working as designed - it's not terminating unexpectedly. Here's what's actually happening:
Technical Explanation
Todo List:
Read the filesystem server source code
Examine the Dockerfile and entry point
Analyze the server's main loop and stdin handling
Check how MCP servers are designed to work
Provide explanation of the behavior
Suggest potential improvements
How MCP Servers Work
MCP (Model Context Protocol) servers are designed to run as stdio-based JSON-RPC servers, not as traditional daemons. They:
Listen on stdin/stdout for JSON-RPC messages
Block waiting for input from the client
Exit when stdin closes (when no client is connected)
The Code Flow
In src/filesystem/index.ts:693-705:
asyncfunctionrunServer(){consttransport=newStdioServerTransport();awaitserver.connect(transport);console.error("Secure MCP Filesystem Server running on stdio");// ... server now waits for stdin input}
The StdioServerTransport creates an event-driven server that:
Reads JSON-RPC requests from stdin
Writes JSON-RPC responses to stdout
Logs messages to stderr
Exits when stdin is closed/EOF
Why Chris's Commands Behave This Way
Without -i flag:
docker run --rm -v $PWD:/projects mcp/filesystem /projects
Docker doesn't attach to stdin (no TTY)
Server starts, prints message to stderr, stdin immediately gets EOF
Server exits cleanly with code 0
With -i flag:
docker run -i --rm -v $PWD:/projects mcp/filesystem /projects
Docker keeps stdin open and attached
Server waits for JSON-RPC messages
When Chris sends {"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}, it responds
Server continues running until stdin closes
This is Normal MCP Behavior
All MCP servers in the repository follow this same pattern:
src/memory/index.ts:413
src/sequentialthinking/index.ts:277
src/everything/stdio.ts:9
They're designed to be used by MCP clients (like Claude Desktop, IDEs, etc.) that manage the stdio connection, not run standalone as services.
Solution for Standalone Usage
If you want to run this as a remote server, you have a few options:
Use stdin piping: echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | docker run -i --rm -v $PWD:/projects mcp/filesystem /projects
Create a wrapper that maintains stdin connection
Use HTTP transport (would require code modifications)
This isn't a bug - it's the intended stdio-based architecture of MCP servers.
Documentation is not comprehensive or concise. The fact that the 'main component' is using stdin/stdout is completely an internal detail - maybe it makes it easier to 'integrate' with claude desktop etc, but it seems completely irrelevant to the MCP protocol. Hence the confusion.
Thanks @chrissound - one thing I was not clear on in your other comment was the statement "figure out how to run this remotely" - filesystem is meant to be run as a local server (which is why it only uses STDIO transport). So I'm not sure on what exactly you are trying to implement remotely - do you just mean run it on a deployed docker container?
I was trying to call the anthropic API directly (without claude code, or claude desktop). And I was investigating how to setup my own MCP server, hence it can only run 'remotely' as that is how anthropic's api interacts with MCP servers - via HTTP.
In other words I thought something like this:
Setup a 'mcp server' that is publicly accessible
Call the anthropic api specifying the publicly accessible mcp server, and asking it to use the mcp server to list files
I see the response from anthropic api showing the ls results.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. The filesystem server is a stdio server and exits when stdin closes, so it must be run with docker run -i by an MCP client; this is expected behavior, not a defect.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see CONTRIBUTING.md.
Activity
chrissound commentedon Aug 8, 2025
I had to run
docker run -i(interactively), and then paste{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}and press enter (push it to stdin of the process)... After which it sends the response to stdout:The next mission (not that anyone cares...) is to figure out how to run this remotely as a proper MCP server.
olaservo commentedon Aug 24, 2025
@claude could you help us understand why Chris is having these issues?
claude commentedon Aug 24, 2025
Claude finished @olaservo's task —— View job
Analysis: MCP Filesystem Server Termination Issue
Root Cause Analysis
The MCP Filesystem server is working as designed - it's not terminating unexpectedly. Here's what's actually happening:
Technical Explanation
Todo List:
How MCP Servers Work
MCP (Model Context Protocol) servers are designed to run as stdio-based JSON-RPC servers, not as traditional daemons. They:
The Code Flow
In
src/filesystem/index.ts:693-705:The
StdioServerTransportcreates an event-driven server that:stdinstdoutstderrWhy Chris's Commands Behave This Way
Without
-iflag:docker run --rm -v $PWD:/projects mcp/filesystem /projectsWith
-iflag:docker run -i --rm -v $PWD:/projects mcp/filesystem /projects{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}, it respondsThis is Normal MCP Behavior
All MCP servers in the repository follow this same pattern:
src/memory/index.ts:413src/sequentialthinking/index.ts:277src/everything/stdio.ts:9They're designed to be used by MCP clients (like Claude Desktop, IDEs, etc.) that manage the stdio connection, not run standalone as services.
Solution for Standalone Usage
If you want to run this as a remote server, you have a few options:
Use stdin piping:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | docker run -i --rm -v $PWD:/projects mcp/filesystem /projectsCreate a wrapper that maintains stdin connection
Use HTTP transport (would require code modifications)
This isn't a bug - it's the intended stdio-based architecture of MCP servers.
chrissound commentedon Aug 24, 2025
Documentation is not comprehensive or concise. The fact that the 'main component' is using stdin/stdout is completely an internal detail - maybe it makes it easier to 'integrate' with claude desktop etc, but it seems completely irrelevant to the MCP protocol. Hence the confusion.
olaservo commentedon Aug 27, 2025
Thanks @chrissound - one thing I was not clear on in your other comment was the statement "figure out how to run this remotely" - filesystem is meant to be run as a local server (which is why it only uses STDIO transport). So I'm not sure on what exactly you are trying to implement remotely - do you just mean run it on a deployed docker container?
chrissound commentedon Aug 27, 2025
I was trying to call the anthropic API directly (without claude code, or claude desktop). And I was investigating how to setup my own MCP server, hence it can only run 'remotely' as that is how anthropic's api interacts with MCP servers - via HTTP.
In other words I thought something like this:
lsresults.cliffhall commentedon Oct 19, 2026
Closing: superseded by the v2 release.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. The filesystem server is a stdio server and exits when stdin closes, so it must be run with docker run -i by an MCP client; this is expected behavior, not a defect.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see
CONTRIBUTING.md.Thanks for taking the time to report it.