JetBrains IDE MCP Server is built into current IntelliJ-based IDEs and lets a compatible external client call selected IDE functions. It replaces the need to recommend the older separate proxy repository for modern supported IDE versions.
Key takeaways
- Built into IntelliJ-based IDEs since the documented 2025.2 generation.
- Operates with the project and permissions of the running IDE.
- The older
JetBrains/mcp-jetbrainsproxy is deprecated for this path.
What is JetBrains IDE MCP Server?
MCP server built into current IntelliJ-based IDEs for exposing selected IDE project and development functions to external agents. MCP standardizes how a compatible client discovers and invokes tools, but it does not make those tools safe automatically. The client, server, credentials and upstream service remain separate trust boundaries.
What tools does it expose?
- Inspect project files and IDE-provided code context.
- Use supported navigation, search and analysis functions.
- Run selected IDE or project actions exposed by the server.
- Connect local MCP clients through the IDE configuration.
The exact catalog can change by release, account, enabled feature or server configuration. Inspect the live tool list and JSON schemas before enabling it. A descriptive tool name is not an authorization control, and a read-sounding operation can still reveal sensitive metadata.
What is a safe first test?
Open a disposable read-only sample project and connect a local client. Test code search and inspection before enabling file modification, terminal or run-configuration actions.
Use a test account or project, allow only the required tools and record the client configuration, server version and arguments. Verify the result directly in the upstream service. Add write tools only after read-only behavior, authentication expiry, error handling and audit logs have been reviewed.
What data and credentials can it access?
The server can expose project code, IDE indexes, diagnostics and other functions made available by the IDE. Actions run in the context of the open project and local user.
Credentials should be supplied through the documented OAuth flow, a secret manager or a restricted environment variable, never pasted into prompts or committed to source. The upstream account should expose only the resources required for the pilot.
Which permissions should you grant?
- Only the disposable project opened in the IDE.
- Read-only client behavior for the first session.
- No production credentials in project run configurations or environment.
Prefer project-scoped, read-only or restricted tokens. Where the server offers tool filters, combine them with upstream authorization rather than treating filtering as the only control. Separate development and production identities and rotate test credentials after the evaluation.
What should a security review cover?
- Do not open a multi-project workspace containing unrelated sensitive code.
- Review every requested edit or execution action.
- Keep the server local unless JetBrains documents a secure remote setup.
Assume tool results can contain prompt injection or hostile content. Keep approval gates in application code for financial, administrative, destructive or public actions. Apply network restrictions, timeouts, output-size limits and audit logging at the host or gateway layer.
What are the main limitations?
- Requires a supported JetBrains IDE and version.
- Available tools depend on the IDE and plugins.
- IDE access can indirectly reach build scripts, terminals and credentials.
This is a documentation-based profile checked on 2026-10-04; Anavem did not connect the server or test it against a live account. Tool catalogs, transport support, pricing, licensing and authentication methods can change. Verify the current first-party documentation before installation.