Repository navigation
fix(database): find public getMcpTools in IntelliJ 2026.2 (build 262) - #1179
Merged
Merged
Conversation
JetBrains made McpServerService.getMcpTools public, dropping the Kotlin $intellij_mcpserver mangling. JetBrainsMcpProxy only looked up the mangled name, so tool discovery threw NoSuchMethodException and no database proxy tools were registered. Probe the plain name first, then the mangled one, for both the 5- and 4-parameter signatures. When nothing matches, the error now lists the getMcpTools overloads that do exist, and the warning no longer points at the wrong plugin.
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Loading the 2026.2 invocation-mode class before the legacy fallback can break tool discovery on older supported IDEs.
1 open finding
What changed in this PR
Updates reflective MCP tool discovery for IntelliJ 2026.2 while retaining older method names and signatures.
Changes:
- Supports public and Kotlin-mangled
getMcpToolsnames. - Adds diagnostic output and focused lookup tests.
| File | Description |
|---|---|
JetBrainsMcpProxy.java |
Updates reflective discovery and diagnostics. |
JetBrainsMcpProxyTest.java |
Tests method-name lookup behavior. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
…ls on 2026.1 Review feedback on #1179: invokeGetMcpTools loaded com.intellij.mcpserver.McpToolInvocationMode before probing for any overload. That class only exists from 2026.2, so on 2026.1 and earlier Class.forName threw ClassNotFoundException and the four-parameter overload was never reached, leaving the database tools unregistered. The original code only loaded it in the fallback for the five-parameter overload. - loadOptionalClass: a missing class gives null instead of aborting discovery. - findGetMcpTools: tries the five-parameter overload only when the invocation-mode class exists, then falls back to the four-parameter one. The DIRECT constant is only looked up when the five-parameter overload was chosen. - Tests for selection with and without the class (fake services standing in for 2026.1, build 262 and early 2026.2 builds), and for loadOptionalClass. - Class Javadoc now describes both method names and the optional fifth parameter.
IDE Compatibility Matrix
Generated from the real-IDE integration bench (
Logged IDE errors (non-gating)Scraped from the IDE log during the run. These do not fail a matrix cell (the cell reflects the tool's MCP response) — they are listed for visibility while the bench matures.
|
Clean as you code, for the code this PR touches: - invokeGetMcpTools took 9 parameters (limit 7). The three classes it received only existed to build the base parameter-type array, so discoverTools now builds that array and passes it once (7 parameters). - findDeclaredMethod probed names with getDeclaredMethod, catching NoSuchMethodException in an empty block silenced with //NOSONAR. It now scans the declared methods for a matching name and parameter types, in name-priority order, so there is no exception flow and no suppression. - invocationModeClass is nullable by design, so the DIRECT lookup was flagged as a possible NPE. The four-parameter path is now taken explicitly when the class is absent. - The fake services in the test no longer have unused parameters.
|
catatafishen
pushed a commit
that referenced
this pull request
Oct 12, 2026
…ls on 2026.1 Review feedback on #1179: invokeGetMcpTools loaded com.intellij.mcpserver.McpToolInvocationMode before probing for any overload. That class only exists from 2026.2, so on 2026.1 and earlier Class.forName threw ClassNotFoundException and the four-parameter overload was never reached, leaving the database tools unregistered. The original code only loaded it in the fallback for the five-parameter overload. - loadOptionalClass: a missing class gives null instead of aborting discovery. - findGetMcpTools: tries the five-parameter overload only when the invocation-mode class exists, then falls back to the four-parameter one. The DIRECT constant is only looked up when the five-parameter overload was chosen. - Tests for selection with and without the class (fake services standing in for 2026.1, build 262 and early 2026.2 builds), and for loadOptionalClass. - Class Javadoc now describes both method names and the optional fifth parameter.
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On IntelliJ 2026.2 (build 262) no database proxy tools are registered.
JetBrainsMcpProxydiscovers the JetBrains MCP Server plugin's tools by reflection onMcpServerService.getMcpTools. Earlier builds had that method module-internal, so Kotlin mangled its name togetMcpTools$intellij_mcpserver, and that is the only name we looked up. Build 262 made it public under the plain namegetMcpTools, so the lookup throwsNoSuchMethodException, tool discovery fails, and the database tools are silently absent.Fix
McpToolInvocationMode, the fifth parameter's type, only exists from 2026.2, so it is loaded optionally: when it is absent the four-parameter overload is used instead of discovery failing on the missing class.findDeclaredMethodso it can be tested without the JetBrains plugin.NoSuchMethodExceptionnow lists thegetMcpTools*overloads that do exist on the class, so the next signature change is diagnosable from the log.Tests
JetBrainsMcpProxyTestuses small fake service classes: finds the public method (build 262), finds the mangled one (earlier builds), prefers the plain name when both exist, and returnsnullwhen no overload matches the parameter types. Selection is also tested with and without the invocation-mode class (fake services standing in for 2026.1, build 262 and early 2026.2 builds). Fullplugin-coresuite: 11,067 tests, 0 failures.Not verified
The tests cover the lookup only, against fake classes. I have not re-run tool discovery against the real MCP Server plugin in a live IDE in this session, so please confirm on a 2026.2 build that the database tools show up again.