feat: default streamable_http_path to "/" for consistency

[tewatia]

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"}

[tewatia]

@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]

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

[tewatia]

@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]

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"}?

[felixweinberger]

Thank you for the contribution and bringing attention to the discrepancy between typescript and python behavior here!

I looked at the issues #1053 and #938 you linked but I'm not sure how they relate to this particular setup?

Given the significant potential for breakage here I'd also err on the side of improving docs for now like @akolotov instead of introducing a breaking change - my understanding is that the doubled up /mcp/mcp mount only actually applies if in your own routing setup you set /mcp as the root and mount a sub-app - it doesn't always just mount at /mcp/mcp, it could be /xyz/mcp or whatever you set as your root in the parent app?

Nonetheless I think the discrepancy between typescript and python is not ideal so we should probably make this change in a future version that permits breaking changes - I'm keeping this PR open and adding it to the milestone for SDK v2.0.0

I've added some proposed improved docs here for now - would this have helped you avoid this rabbit hole? #1172