Update mcp-proxy to only enable capabilities that are exported by the server

[allenporter]

This fixes an issue where clients attempt to call capabilities that do not exist and get stuck. Adds test coverage that exercises a fake server and the same fake server through the proxy to ensure the behavior is the same on both.

[allenporter]

Background: I was looking to build a small proxy like this, then thought it would be better to contribute here. I have a few more changes if you're open to them. Also, would love to also help get this published on pypi for users to install if you are open to that too.

[sparfenyuk]

Thank you, looks good. I was about to address it the same way. I just worry about the mcp-server capabilities itself. It seems like we can't redact them after the connection has been established.

Special thanks for implementing the tests. Will add a GA to run them on PRs.

[allenporter]

Thank you, looks good. I was about to address it the same way. I just worry about the mcp-server capabilities itself. It seems like we can't redact them after the connection has been established.

I agree that it seems like it's something static, configured at startup. Can you elaborate on the concerns you have here?

Special thanks for implementing the tests. Will add a GA to run them on PRs.

Thanks! What do you think about also making some automation to push to pypi on new releases? For example, this is what i'm currently using

For context, what i'm wanting to do is use this for connecting to a home assistant MCP integration using SSE and put examples using mcp-proxy in the documentation

[sparfenyuk]

Can you elaborate on the concerns you have here?

Since we spin up the proxy-server without capabilities, clients may not expect some functionality like resources or tools update. The behavior can be broken. It can be solved by asking a user to specify those manually in the config file. I don't think it's feasible in the runtime.

What do you think about also making some automation to push to pypi on new releases?

Sure thing, let me add this step too.

[sparfenyuk]

@allenporter here we go https://pypi.org/project/mcp-proxy/

[allenporter]

@allenporter here we go https://pypi.org/project/mcp-proxy/

Awesome, thank you!

[allenporter]

Can you elaborate on the concerns you have here?

Since we spin up the proxy-server without capabilities, clients may not expect some functionality like resources or tools update. The behavior can be broken. It can be solved by asking a user to specify those manually in the config file. I don't think it's feasible in the runtime.

I'm not sure I totally follow. My impression is this will ask the downstream server what capabilities it supports then expose those in the server that ends up getting started. Are you talking about (1) dynamically changing capabilities over time e.g. tools are not supported then become supported by the downstream server? or (2) notifications on updates (not yet supported, but could be) or (3) some other kind of startup bug?

By the way, I also have a need for the reverse of this proxy e.g. i'd like to add MCP client support to Home Assistant and make a way to run many of the example stdio only servers as an SSE server. Would it make sense to also support the reverse direction in mcp-proxy or leave that to a separate project?

[sparfenyuk]

By the way, I also have a need for the reverse of this proxy e.g. i'd like to add MCP client support to Home Assistant and make a way to run many of the example stdio only servers as an SSE server. Would it make sense to also support the reverse direction in mcp-proxy or leave that to a separate project?

To me, it is fine to extend the existing proxy with the reverse case. Thanks for idea!

[sparfenyuk]

I'm not sure I totally follow. My impression is this will ask the downstream server what capabilities it supports then expose those in the server that ends up getting started.

Yes, you're right. I was unsure it would infer from what is already exposed. I checked the source code and now I see the method Server.get_capabilities() which is indeed called during the initialization.