Move, Delete, Rename, run, and debug through JetBrains IDE mechanisms instead of reconstructing project relationships from text alone.
AI coding agents are good at producing patches. The harder problem begins when a change crosses file, package, module, or runtime boundaries.
Move a class through the file system and its package may become wrong. Delete an entity without checking usages and another module may stop compiling. Rename a symbol as text and unrelated strings can change with it.
JetBrains IDEs already resolve many of these relationships. Explyt 5.17 gives agents a direct path to that project knowledge.
The central change in Explyt 5.17 is simple: an agent can ask the IDE to perform and inspect engineering operations that the IDE already understands.
Why Are File Edits Not Enough?
A repository is more than a collection of text files.
Code entities are connected through:
resolved symbol references;
imports and package declarations;
module and source-root boundaries;
run configurations;
debugger state;
framework and language support;
generated code and configuration.
A text edit can produce a clean-looking diff while missing one of those connections. Explyt 5.17 reduces that risk by routing supported refactoring operations through native JetBrains IDE mechanisms.
The IDE contributes indexes, symbol resolution, usage search, conflict detection, and refactoring support. The agent contributes task planning, tool selection, and follow-up verification.
What Changed in Refactoring?
Earlier versions already supported Rename. Explyt 5.17 adds Move and Delete.
Move
Move can relocate supported files, folders, and code entities through IDE refactoring.
For a class moved to another package, the IDE can update the package declaration, imports, and resolved references it recognizes in the open project. Before the operation is applied, the agent receives information about affected locations and conflicts.
This is materially different from moving a file and repairing references afterward with a sequence of searches and edits.
Delete
Delete checks usages before removing a supported entity.
The agent can inspect the dependencies found by the IDE, revise its plan, and handle affected code before deletion. This makes the usage check part of the operation rather than an optional cleanup step after the entity has disappeared.
Rename
Rename continues to operate on code entities and their resolved references rather than every matching character sequence.
Depending on the language, entity type, and IDE support, the operation may also include related elements. Renaming a class, for example, may include its file name.
What Does the Agent See Before a Change?
Explyt can expose the IDE's refactoring preview and conflict information to the agent.
Before Move, Delete, or Rename is applied, the operation can identify:
the elements selected for the change;
files and references included in the refactoring;
conflicts that block or complicate the operation;
related entities the IDE proposes to update.
That preview matters most when a task spans several packages or modules. It gives the agent evidence about the scope before files are written and creates a checkpoint where the plan can change.
inspect scope → review conflicts → apply a bounded refactoring → build → test → inspect the diff
This loop is stronger than treating a successful tool call as proof that the task is complete.
Where Does IDE Analysis Stop?
IDE-backed refactoring improves the evidence available to an agent. It does not guarantee complete dependency discovery.
Results depend on:
language and framework support in the installed JetBrains IDE;
successful completion of project indexing;
the relationships the IDE can resolve;
reflection and other dynamic references;
generated code;
configuration files and templates;
references held in external systems;
text mentions that are not symbol references.
A large refactoring still needs a diff review, a build of affected modules, and relevant tests. If the change touches runtime behavior, reproduce the affected path or inspect it with the debugger.
Can External Agents Use the Same IDE Tools?
Yes. Explyt 5.17 includes an MCP server that runs inside the IDE.
It can connect Claude Code, Codex, Cursor, OpenCode, and other MCP-compatible clients to selected IDE operations in the context of the open project.
The external client keeps control of its own model, prompts, context, and call sequence. Explyt executes the selected IDE tool calls and does not provide inference in this mode.
The MCP server is available free without an Explyt subscription.
This gives developers a practical way to keep their preferred agent while adding structured access to JetBrains IDE capabilities.
Which Tool Groups Can You Expose?
The server configuration lets you enable only the groups required for the current task:
project navigation;
run configurations;
debugger operations;
IDE refactoring.
The client does not receive every IDE capability automatically. Its available tools depend on the selected server configuration.
That boundary supports a narrower setup: a client investigating a failing test may need navigation, run, and debugger tools but no refactoring access. A client reorganizing packages may need navigation and refactoring, followed by a run configuration for verification.
How Do You Inspect MCP Calls?
The MCP server window includes a call log.
For each request, you can inspect:
the tool requested by the external agent;
the arguments sent with the call;
the response returned by the IDE tool;
the step at which an error occurred.
This creates a concrete record of the interaction between the agent and the IDE. If a debugger workflow fails, you can see whether the problem came from the selected tool, its arguments, the run configuration, or the returned state.
Before sharing logs or server configurations, review them for local paths, source code, and other project data that should remain inside the working environment.
What Does Chat Branching Actually Separate?
Explyt 5.17 can create a new chat from a selected message.
The new conversation inherits history up to that point. From there, the two chat histories develop independently. This is useful when one investigation produces several directions:
tests in one chat and documentation in another;
implementation in one chat and code review in another;
competing architecture discussions from the same initial context;
a fresh path after an unsuccessful approach.
The separation applies to conversation history, not to project files.
Both chats continue to work with the same open project and the same file system. A change made from one chat is visible to the other. Chat branching does not create a Git branch, worktree, project copy, or isolated workspace.
Use Git branches or worktrees when parallel alternatives must not modify the same files.
What Else Improved in 5.17?
The release reduces unnecessary background work by refreshing the context panel less often and processing internal project data more efficiently. Internal log growth is limited as well.
It also fixes reliability issues in several paths:
background tools resume work in chats more reliably;
tool calls recover more correctly from incomplete arguments;
absolute Windows paths are handled correctly;
issues involving enterprise models are fixed;
large MCP server responses are handled more reliably.
These fixes require no extra configuration after the update.
A Practical Verification Loop
IDE access is useful when it shortens the distance between a proposed change and evidence about its effect.
For a refactoring task, use this loop:
Wait for indexing to finish.
Ask the agent to identify the target entity and affected scope.
Inspect the IDE preview and conflicts.
Apply one bounded Move, Delete, or Rename operation.
Review the resulting diff, including configuration and generated-code boundaries the IDE may not resolve.
Build the affected modules through the relevant run configuration.
Run focused tests.
For runtime-sensitive changes, reproduce the path and inspect state through the debugger.
Repeat with the next bounded operation.
For an external MCP client, add two checks:
enable only the tool groups needed for the task;
confirm the first request, arguments, and response in the call log.
This keeps the agent's work observable and makes completion depend on project evidence, not on a plausible patch.
Try Explyt 5.17
Update Explyt from Settings | Plugins | Installed, restart the IDE if prompted, open the project, and wait for indexing to finish before the first refactoring.
If you use Claude Code, Codex, Cursor, OpenCode, or another MCP client, open the Explyt MCP Server window, select the required tool groups, start the server, connect the client, and inspect its first call in the log.
Explyt is available from the download page.
Sources
Explyt 5.17: IDE refactoring and an MCP server for external agents - product facts, capabilities, limitations, setup, and release fixes.
Building a Fair Benchmark for AI Agent Memory Systems - editorial reference for article pacing and section structure only; its benchmark topic, claims, and wording were not reused.
Top comments (0)