Feat/sse server parameters client

[QuantGeekDev]

I added the SseServerParameters class to client/sse.py

Motivation and Context

I noticed that Stdio have StidoServerParameters, and it's a nice way to organize it. When I tried to use the same from SSE, I found that it doesn't export SseServerParameters. Hence the nature of this pull request. For reference, the typescript SDK does export different classes for Stdio and Sse. And the initial steps have been taken in the python sdk with StdioServerParameters. SseServerParameters class is a simple change that takes a step to a more maintainable codebase.

How Has This Been Tested?

Tested with SSE servers in deployed application

Breaking Changes

Yes, this is a breaking change because it changes how the Sse server is instantiated but 1) this should've been in the sdk, it's a pattern used in the stdioserver of this same repo, and in the typescript versions of the sdk. 2) it's early enough that barely anyone has written SSE servers since most people focusde on STDIO, so this is a good time to add this as it's still early.

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

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

[QuantGeekDev]

To verify this PR, just look at how client/stdio is implemented. It's a great pattern and we should use it in client/sse.py too

[Kludex]

This is a breaking change, and I'd prefer to actually do the opposite everywhere else.

[QuantGeekDev]

This is a breaking change, and I'd prefer to actually do the opposite everywhere else.

I disagree with your opinion about doing the opposite everywhere else. Can you please give some arguments as to why?

[Kludex]

This is a breaking change, and I'd prefer to actually do the opposite everywhere else.

I disagree with your opinion about doing the opposite everywhere else. Can you please give some arguments as to why?

First, this is Python, not TypeScript. There's no need to encapsulate configuration in a related class. That just adds one more import, it takes more time to find what you want on your IDE, since you'll not get the configuration options you have available on the main object you are interested, and you usually have to extract information via model_dump to get a dictionary, as you did on this PR.

It's just unnecessary complexity.

[QuantGeekDev]

This is a breaking change, and I'd prefer to actually do the opposite everywhere else.

I disagree with your opinion about doing the opposite everywhere else. Can you please give some arguments as to why?

First, this is Python, not TypeScript. There's no need to encapsulate configuration in a related class. That just adds one more import, it takes more time to find what you want on your IDE, since you'll not get the configuration options you have available on the main object you are interested, and you usually have to extract information via model_dump to get a dictionary, as you did on this PR.

It's just unnecessary complexity.

Thanks for your thoughts on this. I see your point, I believe it comes down to personal preference but I do favor the simplicity of not needing an extra class for parameters (your approach). The nature of my PR was to make it more consistent with client/stdio in this same repository and the Typescript SDK. Following this line of reasoning, we should remove the StdioServerParameters for client/stdio, right? I think it's strange to have one pattern in one file, and then have another pattern in the only other file that implements a transport. I'm in favor of consistency, be it removing a parameter class or adding one. It's not a priority but we need this codebase to be more consistent

[Kludex]

[...] right?

Right.

---

Is there a deprecation policy or something, or can we add breaking changes? @dsp-ant

[QuantGeekDev]

[...] right?

Right.

Is there a deprecation policy or something, or can we add breaking changes? @dsp-ant

I'd love to work on that PR and add my 2 cents to this effort :) I think now is better than later, seems like we're on the cusp of a big adoption increase. Would be good to get that change in before it grows even more to minimize disruption

[QuantGeekDev]

@Kludex Submitted a new PR with this alternative approach: https://github.com/modelcontextprotocol/python-sdk/pull/306/files

[Kludex]

@Kludex Submitted a new PR with this alternative approach: #306 (files)

Let's continue the discussion there. 🙏