Skip to content

Port mount_path support from official SDK聽#370

Description

@repl-uosis-levandauskas

Enhancement Description

Port modelcontextprotocol/python-sdk#540

Use Case

Running multiple MCP servers under a single Starlette app. See #281 for another issue regarding this.

Proposed Implementation

Seems to be a fairly straightforward port.

Activity

  1. added
    enhancementImprovement to existing functionality. For issues and smaller PR improvements.
    on May 8, 2025
  2. jlowin commented on May 8, 2025

    @jlowin
    Member

    Finally!

  3. jlowin commented on May 8, 2025

    @jlowin
    Member

    To be honest after looking more closely I really don't like this solution. It requires the SSE app to know the route it will be mounted under at the time it's created, which is an unrealistic burden and destroys all opportunity to flexibly compose servers. For example, if I create a server at mount path /abc, I simply can not mount it anywhere else -- and any app its mounted in can't be mounted in any other app -- because it will break what is now effectively a hardcoded expected prefix.

    The alternative approach of doubly-specifying the prefix is less bad but seems unnecessary.

    Lastly I really don't like that this introduces yet more config to the FastMCP server for a bug that arguably exists in the SSE transport.

    I'll look into other solutions!

  4. repl-uosis-levandauskas commented on May 8, 2025

    @repl-uosis-levandauskas
    Author

    Fair. If you read the comments on that PR, many people had the same concern. This comment is particularly interesting: modelcontextprotocol/python-sdk#540 (comment). Given that the protocol is changing soon anyway, maybe this simple solution is acceptable in the interim? It is still better than current alternatives, and would keep consistency with official SDK.

  5. jlowin commented on May 8, 2025

    @jlowin
    Member

    True, and I've already merged Streamable HTTP support into FastMCP (we are waiting for the official SDK to release before releasing here) but we can't just drop support for SSE, it has to be maintained properly. In addition, we can't let the tail wag the dog -- poor design decisions aren't strong motivation to keep compatibility.

    That said I am opening a PR to the official SDK to fix this issue properly.

  6. jlowin commented on May 8, 2025

    @jlowin
    Member

    Here is my preferred approach. Fortunately/Unfortunately this has to be changed in the low-level SDK as it is independent of any of the FastMCP machinery. modelcontextprotocol/python-sdk#659

  7. repl-uosis-levandauskas commented on May 8, 2025

    @repl-uosis-levandauskas
    Author

    That is indeed a much better solution that just makes things work as expected without futzing with any settings. Thank you! Now let's see how long it takes them to merge it.

  8. elizabetht commented on May 8, 2025

    @elizabetht

    Yes, I am waiting on this as well. Usually how long does it take to merge and get a release?

  9. jlowin commented on May 9, 2025

    @jlowin
    Member

    Rather than wait I've patched this into FastMCP in #390

  10. jlowin commented on May 12, 2025

    @jlowin
    Member

    modelcontextprotocol/python-sdk#659 has been merged, so we will update after it is released

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementImprovement to existing functionality. For issues and smaller PR improvements.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions