sse_app() ignores mount prefix, resulting in 404 from client

[allieus]

Describe the bug

When mounting sse_app() from FastMCP with a URL prefix using Starlette’s Mount, the SSE stream still returns the default /messages/ endpoint without the prefix. This causes the MCP client to resolve an incorrect URL (e.g., /messages/ instead of /mcp/messages/), resulting in a 404 error.

To Reproduce

Steps to reproduce the behavior:

1. Define an MCP server as below:

from mcp.server.fastmcp import FastMCP
from starlette.applications import Starlette
from starlette.routing import Mount

mcp = FastMCP(
    # sse_path="/sse",  # default
    # message_path="/messages/",  # default
)


application = Starlette(
    routes=[
        Mount("/mcp", app=mcp.sse_app()),  # HERE !!!
    ]
)

2. Start the server and navigate to http://127.0.0.1:8000/mcp/sse in your browser
3. Observe the response in the browser. You will receive an SSE event like:

event: endpoint
data: /messages/?session_id=...

At this point, the MCP client performs a urljoin operation between the SSE URL (http://127.0.0.1:8000/mcp/sse) and the endpoint path (/messages/). This causes the resolved endpoint URL to become http://127.0.0.1:8000/messages/.

4. The client tries to connect to http://127.0.0.1:8000/messages/, which results in a 404.

Expected behavior

The SSE stream should return the correct full path reflecting the prefix, e.g.:

data: /mcp/messages/?session_id=...

This would allow the client to connect to the actual valid message endpoint.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: macOS
• Browser : Arc
• Version : 1.87.1 (60573)

Smartphone (please complete the following information):

• Device: N/A
• OS: N/A
• Browser : N/A
• Version : N/A

Additional context

This behavior seems to originate from hardcoded endpoint generation inside sse_app():

python-sdk/src/mcp/server/sse.py

Line 98 in c2ca8e0

session_uri = f"{quote(self._endpoint)}?session_id={session_id.hex}"

It would be great to have support for specifying a prefix in sse_app() or for the prefix to be auto-detected from the ASGI scope.

Thank you!

[JorgeRuizITCL]

This might be related with #386

[richardhundt]

This might be related with #386

The clients shouldn't be patching the endpoints. The server should just give it the right endpoint during the handshake.

[earonesty]

is there any workaround?

application = Starlette(
routes=[
Mount("/", app=mcp.sse_app()), # HERE !!!
]
)

can't get the routes either?

what's the standard way of linking a fastapi/starlette app with mcp? i need some custom routes

[pztrick]

This is all going to change once streamable HTTP lands, but my work-around for now is to just update /etc/hosts (MacOS/Linux) or Hosts File Editor (Windows) to add two hostnames backend and mcp. Then just serve MCP/SSE on only the mcp hostname.

Something like:

# entrypoint.py
from starlette.applications import Starlette
from starlette.routing import Mount, Host

from django.core.asgi import get_asgi_application
django_http_app = get_asgi_application()

from backend.server import mcp_app

routes = []

application = Starlette(routes=routes)

application.router.routes.append(Host('backend', app=django_http_app))
application.router.routes.append(Host('mcp', app=mcp_app.sse_app()))

[MarkDunne]

There is in issue currently with message routing for non-root mounts. It seems to be ignored by sse_app. Here is a workaround.

As FastAPI is a subclass of Starlette, this works just as well for FastAPI. This is just a slight modification of the sse_app method

def register_mcp_router(
    starlette_app: Starlette,
    mcp_server: FastMCP,
    base_path: str,
):
    sse = SseServerTransport(f"{base_path}/messages/")

    async def handle_sse(request: Request) -> None:
        async with sse.connect_sse(
            request.scope,
            request.receive,
            request._send,  # noqa: SLF001
        ) as (read_stream, write_stream):
            await mcp_server._mcp_server.run(
                read_stream,
                write_stream,
                mcp_server._mcp_server.create_initialization_options(),
            )

    starlette_app.add_route(f"{base_path}/sse", handle_sse)
    starlette_app.mount(f"{base_path}/messages/", sse.handle_post_message)

Other issues/PRs raising the same bug

• Wrong data path when MCP server mounted as ASGI SSE app under some subpath #464
• SSE MCP server fails when URL contains subpaths #490
• Fix SSE client handling of nested path URLs #386

[alexellis]

I ran into this also and am trying the above. A complete example would be really helpful.

In my example the MCP server is written within an openfaas function mounted at http://127.0.0.1:8080/function/mcp - then /sse and /messages are sub-paths. The path of /function/mcp is stripped by the openfaas gateway before the request hits the HTTP server.

I still seem to get the same errors from the client with the above workaround

from fastmcp import Client
from fastmcp.client.transports import (
    SSETransport
)
import os
from dotenv import load_dotenv
import asyncio
import httpx

load_dotenv()

API_KEY = os.getenv('API_KEY')

async def main():
    base_url = "http://127.0.0.1:8080/function/mcp/sse"
    # Connect to a server over SSE (common for web-based MCP servers)
    transport = SSETransport(
        f"{base_url}"
    )

    async with Client(transport) as client:
        await client.ping()
        print(await client.call_tool("list_functions"))

asyncio.run(main())

Error in post_writer: Client error '404 Not Found' for url 'http://127.0.0.1:8080/messages/?session_id=7054b5ed39574cb28470f6308868c6a8'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404

In other words, the server needs to be mounted at / to work... since all paths are stripped off before /function/mcp - but it also needs to reply back as if it were mounted at /function/mcp since the client is unable to understand relative paths.

[rkondra-eightfold]

Have a potential fix. #524

[anchen-007]

I’m experiencing a very similar issue, but in my case, the URL prefix is not defined inside the application code using Mount. Instead, my MCP service is deployed behind an external reverse proxy that uses a multi-level path to distinguish between services.

For example, my SSE server is mounted at /sse, but it's exposed publicly at:
https://****-mcp-server/my/sse

In this case, /my is part of a multi-level URL path added by the reverse proxy, which forwards requests to the root of my MCP server.

When I configure the MCP client to use this kind of multi-level path, I encounter a 404 error.

[rkondra-eightfold]

#540 is the latest on this

[xorcus]

I just hit the same problem. Could you please consider allowing for the base_path to be supplied?
Example modification in python-sdk/src/mcp/server/fastmcp/server.py:

    def sse_app(self, base_path: str = '') -> Starlette:
        """Return an instance of the SSE server app."""
        sse = SseServerTransport(f'{base_path}{self.settings.message_path}')

The original code looks like this:

    def sse_app(self) -> Starlette:
        """Return an instance of the SSE server app."""
        sse = SseServerTransport(self.settings.message_path)

        async def handle_sse(request: Request) -> None:
            async with sse.connect_sse(
                request.scope,
                request.receive,
                request._send,  # type: ignore[reportPrivateUsage]
            ) as streams:
                await self._mcp_server.run(
                    streams[0],
                    streams[1],
                    self._mcp_server.create_initialization_options(),
                )

        return Starlette(
            debug=self.settings.debug,
            routes=[
                Route(self.settings.sse_path, endpoint=handle_sse),
                Mount(self.settings.message_path, app=sse.handle_post_message),
            ],
        )

Exposing the base_path as suggested would allow for mounting with Starlette as follows:

    Mount('/mcp', mcp.sse_app(base_path='/mcp')),

It is a bit redundant, but it works.