Hi Emmanuel, thanks, and great that you're pushing this. NetBeans really shouldn't be left standing at the station.
I've looked at your branch. The good news: your McpToolProvider fits our tools almost one-to-one. Our tools already have a name, a description and a JSON schema, and they return text plus an error flag, which is exactly what your server turns into content and isError. So plugging them in is mostly a thin adapter. Here's what I'd propose as a split: - You: ACP, the chat window, the MCP server, and the IDE-specific tools (editor, Git, projects). Those are things only a running IDE can offer, and they fit your design well. - Us: the Java tools. find_usages/find_implementations, outline (now also for types of the JDK and dependencies, which agents otherwise guess), compile errors without a build, and the refactorings (rename, change_signature, move, safe_delete, inline) with a compile check after each one. Your JavaRefactoringToolProvider would then become redundant. Your generic rename/find_usages/safe_delete currently share names with ours, so we should sort out the names, e.g. yours stay for files and non-Java content. The one real piece of work is on my side: our tools currently open a workspace folder themselves. Inside the IDE they should use the projects that are already open. I'll adapt that, and then open a PR on your branch with the provider, as you suggested. In the longer run, I'm happy to contribute the Java tools to NetBeans itself as a module, so users get them without an extra plugin. Since the code was written outside the ASF, we'd go through the usual grant and IP clearance for that; If we chose to go this route and the project is willing to accept a donation, I'll take care of it on our side. Otherwise it can stay separate - the beauty of a modular system. Three questions: 1. Which NetBeans release are you aiming for, and does the acp.* code stay in the extra cluster for now? 2. Can we use a published build of your branch to compile against (a snapshot, or the CI dev build), or should I build it locally? 3. Are you OK with dropping JavaRefactoringToolProvider once ours is in, or would you rather keep it as a fallback? Cheers, Toni Am 14.10.26, 16:58 schrieb "ehsavoie" <[email protected] <mailto:[email protected]>>: Hi Anton, That's very nice to read :) I was just trying to do some basic stuff and didn't put much thinking into those tools as I started everything as a PoC. I just wanted to ensure that NetBeans users didn't feel left on the side while the AI train was passing ;-) Also after meeting Geertjan last week I felt like I had to give back mre to the only IDE you need :-) It would be great to find a way to use your MCP tools which are far more advanced than mine as i just wanted to test if the agent would be able to access them :) I would be happy to discuss that further, feel free to open PRs on my branch Cheers, ---------- Emmanuel Hugonnet http://www.ehsavoie.com <http://www.ehsavoie.com> http://twitter.com/ehsavoie <http://twitter.com/ehsavoie> Le mer. 14 oct. 2026 à 16:18, Anton Epple <[email protected] <mailto:[email protected]>> a écrit : > Hi Emmanuel, > > great to see this. I've been working on something closely related, from > the other direction: Dukehoff MCP for Java runs a headless NetBeans as an > MCP server for agents outside the IDE, such as Copilot CLI, Claude Code and > Codex. In VS Code it runs inside the Apache NetBeans extension: Our > extension just ships a cluster in its nbcode/ folder, which the Apache > extension loads. It's Apache 2.0: > > - https://github.com/dukehoff-gmbh/dukehoff-mcp > <https://github.com/dukehoff-gmbh/dukehoff-mcp> > - > https://marketplace.visualstudio.com/items?itemName=dukehoff.dukehoff-mcp-java > > <https://marketplace.visualstudio.com/items?itemName=dukehoff.dukehoff-mcp-java> > > Our tool sets overlap: rename, find usages, safe delete, move and inline > are on both sides. Since we built an evaluation harness early on (real > agent sessions, with and without the tools), a few findings might be useful > for your PR: > > 1. Address symbols by name, not by file and offset. Our tools take > com.acme.Foo#bar(String). Agents know names; offsets cost them an extra > read, go stale after the agent's next edit, and an overload needs its > signature anyway. > 2. Check compilation after every refactoring. Each refactoring reports the > compile errors it introduced, including in files it didn't touch, such as > callers of a method that became private. Then the agent doesn't need a > build to find out. > 3. The server instructions decide whether agents use the tools at all. > Without instructions that map questions like "who calls X" to find_usages, > agents kept grepping. With them, in our tests a rename across NetBeans' own > java/ folder took 5 agent turns instead of 48. > 4. Don't answer while the index is still being checked. We tried it, and > the results were silently incomplete. Agents can't tell; they need a "not > ready yet, call again". > > Beyond that, we have change_signature, compile errors without a build, > structural search and replace with Jackpot rules, and a one-call debugger > stop in a test. > > It would be a pity to end up with two implementations of the same Java > tools in the NetBeans world. I'd be happy to align on this, either by > making our tools available through your McpToolProvider SPI, or by talking > about bringing the Java tools into NetBeans itself. Happy to discuss here > or on a call. > > Best regards, > Toni > > Am 14.10.26, 15:52 schrieb "ehsavoie" <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>: > > > Hello, > I've been playing around to use Agent Client Protocol to connect a coding > agent into NetBeans. > I'm trying to expose NetBeans internal features to the agent for > refactoring or searching code. > It is a work in progress, but part of it is already on a PR [1]. > I've tested in with Github Copilot and IBM Bob so far and I find it nice > for now even if it is a bit rought on the edges. > Cheers > Emmanuel Hugonnet > http://www.ehsavoie.com <http://www.ehsavoie.com> <http://www.ehsavoie.com> > <http://www.ehsavoie.com>> > http://twitter.com/ehsavoie <http://twitter.com/ehsavoie> > <http://twitter.com/ehsavoie> <http://twitter.com/ehsavoie>> > > > > > > > > > [1]: https://github.com/apache/netbeans/pull/9712 > <https://github.com/apache/netbeans/pull/9712> < > https://github.com/apache/netbeans/pull/9712> > <https://github.com/apache/netbeans/pull/9712>> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
