quarkus
quarkus copied to clipboard
quarkusio
Dev UI MCP
This PR adds a SSE Endpoint on the existing WS Dec UI JsonRPC Services.
It also adds some MCP JsonRPC Endpoints (tools/list and resources/list for now)
It does not work yet :) But sharing it here as a draft so that @mkouba can see :)
TODO:
- [ ] Making sure the SSE Endpoint is handling all requests expected from Goose or similar. (@mkouba I have not yet looked at the code you shared.)
- [x] Implement the resources from build time data
- [x] Implement the resources from recorded values
- [ ] Implement the resourcesTemplates from Workspace Items
- [x] Add the parameters to the runtime tools
- [x] Add the parameters to the deployment tools
- [x] If the auto description is not enough, find a way to add descriptions.
- [x] Maybe have a filter to filter out some methods to not be used in MCP ?
- [ ] Populate the Dev UI MCP Server page with info on how to use this.
🎊 PR Preview 55e0ee38d188e00b8bb733c6a06694de088f7d1b has been successfully built and deployed to https://quarkus-pr-main-47414-preview.surge.sh/version/main/guides/
- Images of blog posts older than 3 months are not available.
- Newsletters older than 3 months are not available.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This has so much potential and we should do whatever we can to get it up and running ASAP!
~~One thing I see that we will need is to also be able to provide metadata for tool arguments, not just the tool method itself.~~ Never mind, I just saw that @JsonRpcDescription can also be applied to method params.
Making sure the SSE Endpoint is handling all requests expected from Goose or similar.
Is this missing entirely or is it just not working currently? Asking because I didn't anything relevant in the code
There is a sse endpoint, but goose (and the mcp spec) has some init handshake that still needs to be implemented.
I believe we should only implement the basic part of the streamable HTTP server stuff (so only HTTP POST responses). @mkouba WDYT, should be simple, no?
If you agree, I'll copy and adapt a bunch of stuff from the MCP Server code here.
I was looking at that, but seems like Goose does not support that yet... We can either wait for tools to support it, or implement SSE for now and add Streamable later
There is a PR in Goose, so hopefully support will probably land soon. My vote is for just implementing Streamable HTTP as we don't want to accumulate dept on such a new feature.
@mkouba WDYT?
I'm also wondering whether it would make sense to not have any protocol implementation in the DevUI, but instead launch an MCP server (which of course would be implemented using @mkouba's extension).
The idea is to take advantage of all the MCP support the extension already has and not have to do any duplicate work here.
The downsides are not trivial though:
- It would require launching the server on a different port -
- It would require the vertx module to depend on something that is outside of the core repo (in a similar why as the assistant is I guess).
@cescoffier What do you think?
The problem with this is the same as with the current Chappie/Assistant. Then we have to have some remote (probably HTTP) communication. That means loosing CP, serialisation etc.
Then we have to have some remote (probably HTTP) communication
Indeed
That means loosing CP, serialisation etc.
Is this really a problem? If so, what sort of scenarios do you have in mind that would be problematic?
Well , as it is, we already have the 3 ways we expose a JSON-RPC Service (Runtime, Deployment and Recorded). Now if the JSON RPC Service move to some other app (that we start) , how do we use this already refined services from DEv UI ? All we really want is the transport. We are now going to have a JsonRPC calling another JsonRPC ? Except if we drop the whole idea to reuse the JsonRPC from Dev UI.
We are now going to have a JsonRPC calling another JsonRPC
Yeah, that is what I have in mind. Having started to implement it, I do think that it would involve more code than we would save, so let's just scratch my idea.
So in conclusion I think the Streamable HTTP transport is the way to go here but I would like input from @mkouba and @cescoffier
That's where I would like to see a websocket transport to avoid the complexity of streamable http. We added that transport to the roadmap, but it's not there yet.
Well that would be even better as Dev UI already use that. The problem is that no other tool will use that. So if we want any tool (Goose , Claude Desktop, VSCode etc) to just work out of the box, we need to support the protocol they support.
That's where I would like to see a websocket transport to avoid the complexity of streamable http. We added that transport to the roadmap, but it's not there yet.
The problem is that most clients will not support WS transport unless it becomes a "standard".
Well that would be even better as Dev UI already use that. The problem is that no other tool will use that. So if we want any tool (Goose , Claude Desktop, VSCode etc) to just work out of the box, we need to support the protocol they support.
Exactly. And currently most of the clients support SSE (legacy) and Streamable.
Right. And as streamable is the future I think we should just do that and be done with it
Right. And as streamable is the future I think we should just do that and be done with it
Yes, until they decprecate it and introduce a new "shiny" one in the next version of the spec :facepalm:.
I pushed what is essentially a WIP commit that copies a bunch of stuff of quarkus-mcp-server and simplified it. There are still a ton of TODOs, but @phillip-kruger what you need to do is replace this with the actual tool list method, while also doing the same here for the tool invocation.
Note that this WIP already works with MCP inspector for listing and invoking tools
:waning_crescent_moon: This workflow status is outdated as a new workflow run has been triggered.
Status for workflow Quarkus CI
This is the status report for running Quarkus CI on commit 7df155a3c65ff0288f2d39b0450a0ec8c2d0bdf7.
:white_check_mark: The latest workflow run for the pull request has completed successfully.
It should be safe to merge provided you have a look at the other checks in the summary.
[!WARNING] There are other workflow runs running, you probably need to wait for their status before merging.
![quarkus-bot[bot] avatar](https://avatars.githubusercontent.com/in/90234?v=4 "Published by a pub.dev verified publisher"){kind=small}
@cescoffier @geoand - I think we are good to to for the initial version:
- Only dev-ui internal json-rpc methods has been exposed as mcp (by adding a description)
- By default (for now) the mcp server is disabled. You need to switch this on with config. This will allow us to play with this until we are happy.
- Resource is also working. I have only tested with the "info" extension. We can add more resources from other extensions in followup PRs.
- I'll add and update documentation in a follow up PR.
- I'll follow up with PRs for each extension to expose their relevant json-rpc methods as mcp.
There are still a few things we can implement, like promps, resourceTemplates and certain notifications (we would need SSE for that). But I think this is a workable start.