I wish Starlette allowed some reflection on where a route was mounted. This kind of handshake could benefit from that, and I'm guessing the Starlette folks never thought it would be needed. That mount point duplication in settings just seems superfluous, but looking at the Starlette internals, I couldn't see a way of getting at those values either. Perhaps asking them nicely to add this capability would work.

I wish Starlette allowed some reflection on where a route was mounted. This kind of handshake could benefit from that, and I'm guessing the Starlette folks never thought it would be needed. That mount point duplication in settings just seems superfluous, but looking at the Starlette internals, I couldn't see a way of getting at those values either. Perhaps asking them nicely to add this capability would work.
Here's the comment content in English:

@richardhundt I agree that Starlette's lack of reflection on mount points is a bit unfortunate. While we wait for that capability, I was thinking of adding a syntactic sugar method that could help avoid the duplication:

def get_mount(self, mount_path: Optional[str] = None) -> Mount:
    """
    Configure mount_path and return a Mount object for Starlette routing.
    
    Args:
        mount_path: Optional override for the mount_path setting
    
    Returns:
        Starlette Mount object configured for this FastMCP server
    """
    # Set mount_path setting
    if mount_path:
        self.settings.mount_path = mount_path
    
    # Return configured Mount object
    return Mount(self.settings.mount_path, app=self.sse_app())

This would allow for more concise code:

# Current approach
github_mcp.settings.mount_path = "/github"
routes = [Mount("/github", app=github_mcp.sse_app())]

# Proposed approach
routes = [github_mcp.get_mount("/github")]

What do you think? This could help prevent mount path mismatches and simplify the API.

Looks like this will all be moot soon. The updated specification reduces all communication to just a single endpoint supporting both SSE and transactional (request/response) style HTTP interactions (controlled by the Accept header). It complicates the clients a bit because they need to distinguish SSE streaming from transactional responses, but that's manageable and solves all of these routing issues.

https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http

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.

+1 to this ... being able to set a base path would unblock my use case.

I've implemented a solution for this issue by adding a mount_path parameter to the sse_app method, similar to what you suggested with base_path. This change gives
users multiple options for configuring the mount path:

1. Using settings.mount_path for persistent configuration
2. Passing the path directly to sse_app(mount_path="...") for ad-hoc mounting
3. Passing to run(transport="sse", mount_path="...") for direct execution

The implementation also properly handles path normalization through the existing _normalize_path method to ensure paths are correctly combined.

Your example of Mount('/mcp', mcp.sse_app(base_path='/mcp')) now works with our implementation as Mount('/mcp', mcp.sse_app('/mcp')).

All tests have been updated and are passing, and the README has been expanded with examples showing the different approaches. @xorcus

1bd89ff

For anyone else wanting a fix for this problem, I wrote a middleware that works around it by rewriting the endpoint url in the initial message that is sent back by the server upon connection to SSE endpoint.

Source here: https://github.com/dwayn/fastmcp-mount
It is also uploaded to PyPi: https://pypi.org/project/fastmcp-mount/

sse_app(mount_path="/foo/bar") is already implemented here 😄 @dwayn

Hi @tim-watcha I am following your example as in README. But can't find the apps running at the different mount paths. If my endpoint was /cars/v1/sse, I am not seeing the route being found in this approach - getting 404 not found for /cars/v1/sse

if __name__ == "__main__":
  routes = []
  for endpoint, mcp_app in mcp_servers.items():
    routes.append(Mount(endpoint, mcp_app.sse_app(mount_path=endpoint)))

  main_app=Starlette(routes=routes)
  uvicorn.run(main_app, host="0.0.0.0", port=8000)

Hi @tim-watcha I am following your example as in README. But can't find the apps running at the different mount paths. If my endpoint was /cars/v1/sse, I am not seeing the route being found in this approach - getting 404 not found for /cars/v1/sse

if __name__ == "__main__":
  routes = []
  for endpoint, mcp_app in mcp_servers.items():
    routes.append(Mount(endpoint, mcp_app.sse_app(mount_path=endpoint)))

  main_app=Starlette(routes=routes)
  uvicorn.run(main_app, host="0.0.0.0", port=8000)

1. Which client did you use?
2. If the endpoint was /cars/v1/sse, the client should connect via /cars/v1/sse/sse and /cars/v1/sse/messages
   @elizabetht

@tim-watcha, so the url routing after this merge if it was set to /cars/v1 it resolves to /cars/v1/sse and /cars/v1/messages will be handled as routes,

however, If there's no extra / towards the end of messages route|url I'm seeing a 307 redirect /cars/v1/messages/ will solve the redirect, why is this happening does this solve the trailing slash and make it consistent with queryStrings for sessionIds ?

sse_app(mount_path="/foo/bar") is already implemented here 😄 @dwayn

So, in my digging into all of this (and finding several hacky methods to solving this) I ended up learning about how Starlette ASGI apps/routers/middleware/etc are supposed to handle being mounted at an arbitrary path, and the expected behavior is that when a request comes in, it should use scope['root_path'] as a prefix to any url it generates that is based on its own relative paths.
Either that or the client is going to have to figure out what the relative base path is, but that could get weird if the sse_path and messages_path are custom configured with distinctive sub paths, eg: sse_path="/foo/sse" and messages_path="/bar/messages/". Client would know that it connected to /some/path/to/foo/sse but would not have the context based on endpoint=/bar/messages/?sess.... to connect to /some/path/to/bar/messages/", the best guess it could come up with is /some/path/to/foo/bar/messages/..., so this is why the server, when constructing the endpoint should combine root_pathfrom the incoming request scope withself.messages_path` to create a complete absolute path for the client to connect to the endpoint.

So, in the fastmcp-mount middleware, it does exactly that. The fastmcp app should just be configured as if it is mounted on root, the the mount middleware i wrote will intercept the endpoint message from the server and prefix it with the root_path it is supposed to have, no need to tell it what the mount path is at all.
For example with the middleware I wrote to fix the behavior, this works:

mcp_server = FastMCP(title="My Mounted Server")

@mcp_server.tool()
def my_tool(param: str) -> str:
    return f"Processed: {param}"

sse_app = mcp_server.sse_app()

app = FastAPI(title="Main API")
app.mount("/mcp/my-server", app=MountFastMCP(app=sse_app), name="my_mcp_server")

// Since the prefixing is dynamically added, you can mount the same app in multiple places and it is fine
app.mount("/admin/tooling/mcp/my-server", app=MountFastMCP(app=sse_app), name="admin_my_mcp_server")

The real fix to the mcp library (and this is going to be needed for the Streamable HTTP implementation for when it tells the client to connect to an SSE session) is to use the scope['root_path'] of the incoming request from the client to prefix any urls that are generated for the client to connect to.
This should be able to be completely automatically handled in such a way that if i wanted to mount the same exact FastMCP.sse_app() Starlette app on two different places in an API it should just work like above.

@dwayn good news - the strategy you describe was implemented in #659

@dwayn good news - the strategy you describe was implemented in #659

@jlowin This is awesome news! I just checked out the PR and it looks great, this is the true fix that was needed for it.

I think the only other concern is to ensure that the same handling is applied to the Streamable HTTP server transport implementation to ensure that the URLs handed out for SSE connections get their dynamic prefixes as well.
Not sure who is working on that implementation, but definitely worth pointing out to ensure it doesn't get missed, since this fix to SSE is coming in now, shortly before it is deprecated, and I would bet the transport implementation is probably close to finished.