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://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]>>: 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://twitter.com/ehsavoie <http://twitter.com/ehsavoie> [1]: https://github.com/apache/netbeans/pull/9712 <https://github.com/apache/netbeans/pull/9712> --------------------------------------------------------------------- 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
