Enable the other MCP calls

[joseph-wortmann]

for resources and prompts, thereby rounding out hyper-mcp

[tuananh]

when we add that, maybe add an example plugin that use prompts/resources as well, for demonstration purpose.

[joseph-wortmann]

Sounds good. I'll need to add some anyhow so that I can generate unit tests.

[joseph-wortmann]

@tuananh This is shaping up to be a pretty big change, since once we do prompts and resources the interface with the plugins changes pretty significantly (and the server does too).

I can deprecate existing functionality by leaving what is in place there, and attempting the new model executions, falling back to the old version, and then we could choose at some point in the future to remove the old, tools-only mechanisms.

I'd like to know your thoughts before I invest the probably 20-40 hours to do this. I think the functionality is valuable and necessary to really make hyper-mcp the MCP server to use.

[tuananh]

since once we do prompts and resources the interface with the plugins changes pretty significantly (and the server does too).

can you explain more about this?

[joseph-wortmann]

Breaking changes (assuming no deprecation):

• "describe" becomes more complex than just describing tools.
• "call" should probably be renamed "call_tool" for consistency.
• The format of the information sent to "call_tool" changes to remove method (which we never send anyhow) and collapsing to just the arguments.
• Some additional imports to plugins to allow for bidirectional communication with peers (necessary for some of the MCP functionality, just not for tools).
• There may be others that I haven't found yet.

Note that I can allow for the existing protocol, deprecate it, and create the new protocol on the side.

Internal changes:

• MCP is a stateful protocol, but currently we do not indicate to our plugins what session they are responding to. Additionally, we only create 1 plugin per load, meaning that if any state is recorded by the plugin, it is applied to all sessions. This works fine when there is only 1 client per execution of hyper-mcp, but it falls down when hyper-mcp is a shared resource. We really should create a set of plugins per session (and possibly inform the plugin of the session that they are part of/peer they are talking to).
• MCP allows for communication not just from the client to the server, but also from the server to the client. We need to model these as additional host functions exposed by hyper-mcp to the plugins.
• There are many notifications that MCP supports that we do not. I believe that we can support these notifications in the hyper-mcp server and not bother the plugins with them, but they still need to be implemented for completeness.
• There may be others that I haven't found yet.

If we do all of that and do it well, we will have a stateful, complete and extremely fast MCP platform for plugin creators that requires a plugin creator to have almost no MCP expertise.

[joseph-wortmann]

@tuananh So you're OK with all of this? If so, would you like me to deprecate the old functionality or simply make a fully breaking change?

[tuananh]

can we make a flag for it? this would break all the plugins right now right.

[joseph-wortmann]

Yes, I can leave it in place and flag it as deprecated, and then build the new functionality (plugin 2.0 standard) alongside of it.

[tuananh]

sounds good to me