Skip to content

feat: default streamable_http_path to "/" for consistency #1007

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tewatia
Copy link

@tewatia tewatia commented Jun 23, 2025

feat: default streamable_http_path to "/" for consistency

Previously, this default was "/mcp", which led to URLs like /mcp/mcp when the base was already mounted at /mcp. This nested path confused the developers. Switching to "/" aligns with the TypeScript SDK behavior and prevents double mounting.

Summary of changes:

  • Updated default of streamable_http_path to /.
  • Added inline comment in MCPServerConfig.

Motivation and Context

Avoids double-mount confusion and brings parity with the TypeScript SDK.

How Has This Been Tested?

  • Ran uv run pytest.
  • Verified types with uv run pyright.
  • Ensured linting/formatting via uv run ruff check . and uv run ruff format ..
  • Tested local server routing on both / and /mcp mounts.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Breaking changes:
Users relying on the old default must now explicitly set:

settings={"streamable_http_path": "/mcp"}

Previously, this default was "/mcp", which led to URLs like
/mcp/mcp when the base was already mounted at /mcp. Switching
to "/" aligns with the TS SDK behavior and prevents double
mounting.
@tewatia
Copy link
Author

tewatia commented Jun 24, 2025

@dsp-ant Hi David, could you take a look at this? I discovered that when the app is mounted at /mcp, the server endpoint ends up at /mcp/mcp, which isn’t documented and prevented my client from connecting—this cost me two days of debugging. I’ve seen others report the same issue in the tracker, and the TypeScript SDK doesn’t exhibit this behavior. I’m confident that updating the default path to / will resolve it. Please let me know if there’s anything else I can do to help get this merged, or if there’s a specific reason for the current default.

@akolotov
Copy link

akolotov commented Jul 2, 2025

I would vote for keeping it /mcp by default for backward compatibility but provide ability to reconfigure it.

@tewatia
Copy link
Author

tewatia commented Jul 2, 2025

@akolotov @dsp-ant I just went through the first 2 pages of issues list and found atlesst 2 issues related to this - #938 #1053
I think it's time either this is changed or it is made abundantly clear in the documentation that the server is reachable at base_url/mcp/mcp.
I think this behaviour must has caused frustration for even those who eventually got the server working.

@akolotov
Copy link

akolotov commented Jul 2, 2025

Let's discover a common ground

it is made abundantly clear in the documentation that the server is reachable at base_url/mcp/mcp.
I think this behaviour must has caused frustration for even those who eventually got the server working.

In my case the server work base_url/mcp/ without additional mcp:

import uvicorn
from mcp.server.fastmcp import FastMCP

mcp = FastMCP(name=SERVER_NAME, instructions=composed_instructions)

mcp.settings.stateless_http = True
mcp.settings.json_response = True

asgi_app = mcp.streamable_http_app()

uvicorn.run(asgi_app, host=http_host, port=http_port)

What will be changed after your PR merged in my setup if I don't add settings={"streamable_http_path": "/mcp"}?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants