JetBrains MCP Server Gives Codex Real Android Studio Smarts, Not Just File Access

This article is based on the JetBrains MCP Server and Codex configuration as of August 2026. Different Android Studio versions may vary slightly; please refer to the actual situation.

Many AI programming tools can already read files, search code, and execute shell commands, but this does not mean they truly understand the IDE. They might know which Kotlin files exist in a project, but not how Android Studio resolves a specific symbol; they can run ./gradlew, but not the Run Configuration you have already set up; they can perform global text replacement, but cannot complete IDE-level safe renaming.

JetBrains MCP Server solves this gap. Through the Model Context Protocol (MCP), it opens up the code indexing, Inspection, project model, run configurations, and refactoring capabilities inside the JetBrains IDE to external AI clients like Codex.

In other words, after integration, Codex is no longer just "an AI running next to the project directory," but a development agent that can invoke some of Android Studio's capabilities.

1. What is JetBrains MCP Server

MCP is an open protocol that allows AI clients to discover and invoke external tools. JetBrains MCP Server runs on the IDE side, wrapping a set of IDE operations into structured tools, such as:

• Building the project and returning compilation errors;
• Running existing Run Configurations in Android Studio;
• Getting module and project dependencies;
• Querying symbols, types, signatures, and Quick Documentation;
• Invoking IDE Inspection to check specified files;
• Searching project files, text, and code symbols;
• Reading project source code, dependency source code, and decompiled JAR/JRT classes;
• Using the JetBrains refactoring engine to rename symbols;
• Formatting files according to project Code Style;
• Creating files, applying patches, and opening files in the editor;
• Executing commands in the IDE integrated terminal.

This is not another LSP service. LSP mainly solves language capabilities like completion, navigation, and diagnostics between editors and language servers; MCP allows AI to execute more complete IDE workflows through tool invocation. JetBrains MCP can also directly utilize JetBrains' PSI, indexing, Inspection, and project model, and its capability boundaries are generally broader than ordinary text search or simple LSP queries.

2. How to Enable in Android Studio / JetBrains IDE

1. Check the MCP Server Plugin

JetBrains official documentation states that IntelliJ IDEA has built-in MCP Server plugin enabled by default since 2025.2. The actual situation for Android Studio depends on the version and distribution package used. If there is no MCP Server in settings:

1. Open the MCP download link;
2. Download an available MCP version based on the Android Studio version;

3. Install or enable the local plugin;

1. Restart the IDE as prompted.

If you can already see Settings → Tools → MCP Server, the plugin is available.

2. Enable the Service

Go to:

Settings / Preferences → Tools → MCP Server

Click Enable MCP Server. When enabling for the first time, the IDE will prompt about what project access capabilities external programs will gain; confirm to continue.

MCP Server requires the IDE to remain running and the target project to be opened in the IDE. When multiple IDE windows or projects exist, it's best to specify the project path in tasks given to Codex to avoid calls landing on the wrong project.

3. Configure Exposed Tools

Enter the Exposed Tools page to control which capabilities are allowed to be called by external AI by toolset. Common groups include Analysis, Code Insight, Execution, File, Formatting, Patch, Read, Refactoring, Search, Terminal, and VCS.

All are checked by default.

JetBrains MCP's permission filtering and Codex's own approval and sandbox mechanisms are two layers of control: the IDE decides "whether to expose this tool," and Codex decides "whether to allow this call." Keeping both layers is generally safer than unconditionally opening all operations.

4. Choose Transport Method

The JetBrains settings page can generate various client configurations:

• STDIO: The client starts a local proxy process, communicating via standard input/output;
• HTTP Stream: The client connects to the Streamable HTTP service provided by the IDE via a local address;
• SSE: Mainly used for compatibility with clients that still rely on the old SSE transport.

Codex currently natively supports STDIO and Streamable HTTP. For new configurations, it is recommended to choose one of these two, with Streamable HTTP being the suggested option.

The easiest method is to find Codex in Clients Auto-Configuration, click Auto-Configure, and then restart Codex. JetBrains will write the corresponding configuration based on the detected client.

[mcp_servers.studio]
url = "http://127.0.0.1:64342/stream"

You can also open the menu next to Auto-Configure to view the configuration file or copy the configuration.

3. Benefits After Integration

This section is the real reason JetBrains MCP is worth using.

1. AI Gets IDE Semantics, Not Just File Text

When relying only on file reading, AI sees a set of strings. It needs to judge on its own whether a name is a class, extension function, resource reference, or a variable with the same name, and is easily confused by generated code, dependency source code, and symbols with the same name.

Through get_symbol_info, symbol search, and IDE Inspection, Codex can directly use the index already built by JetBrains to obtain a symbol's declaration, type, signature, documentation, and location. For Kotlin overloading, Java/Kotlin mixed compilation, Android resources, and large multi-module projects, this significantly reduces situations where "the text was searched, but the wrong code was found."

2. Can Complete True IDE-Level Refactoring

Renaming is a very typical example. Text replacement can mistakenly change comments, strings, or symbols with the same name, and may also miss Java calls, XML references, and cross-module references.

rename_refactoring calls JetBrains' semantic refactoring capability. The IDE first resolves the target symbol, then updates all references it can recognize. This allows Codex to handle tasks like "rename this class or method and keep the project compilable," rather than leaving the risk to a global replacement.

3. Reuse Existing Run Configurations

The running conditions for Android projects are often hidden in IDE configurations: Build Variant, launch Activity, environment variables, program arguments, test targets, and working directory can all affect results. Letting AI piece together commands itself often requires multiple rounds of trial and error.

get_run_configurations can list existing run configurations in the project and also discover test methods with Run icons in the code, main() and other executable entry points. execute_run_configuration can then directly run the corresponding configuration and return the current output, exit code, and the full output file path.

This way, Codex can reuse the running environment already verified by the team, rather than reinventing a set of launch commands.

4. Forms a "Modify—Check—Build—Run" Closed Loop

Ordinary chat-style AI often ends after generating code. After integrating JetBrains MCP, a more reliable verification chain can be formed:

1. Locate symbols and related files through the IDE index;
2. Read implementation and dependency source code;
3. Apply patches or perform semantic refactoring;
4. Format using project Code Style;
5. Call Inspection to check files;
6. Build the project and read compilation errors;
7. Execute the target Run Configuration or test;
8. Continue correcting based on results.

The key improvement is not that "AI has a few more commands," but that the verification process uses the same IDE context as the developer.

5. Easier to Understand Large Gradle Multi-Module Projects

Just parsing settings.gradle.kts and each module's build scripts does not always yield the real project structure after the IDE imports it. Version catalogs, Convention Plugins, composite builds, and dynamic dependencies further increase the difficulty.

Module and dependency query interfaces can directly return the model already resolved by the IDE. Codex can therefore more easily answer:

• Which module a certain class belongs to;
• What modules the current project has;
• Which dependency a certain capability comes from;
• Which consumers might be affected by modifying a common module;
• What the source code or decompiled implementation of a certain library is.

6. Can Read Dependency Source Code and Decompilation Results

JetBrains' reading interface is not only for the project directory but can also read project dependencies and source code within JAR/JRT, returning decompiled class file content when needed.

This is very practical when troubleshooting SDK behavior. Codex can first query external symbols, then read the library implementation, without having to extract the entire JAR into the project or rely on online code snippets that may not match the current version.

7. More Precise Output and More Context-Efficient

Letting AI recursively read a large number of files is not only slow but also consumes context. The IDE's symbol index, file problem list, and structured build errors can narrow the scope to truly relevant locations.

For example, querying a symbol's declaration is usually cleaner than a project-wide search for strings with the same name; getting the Inspection results for a specified file is also more efficient than repeatedly feeding the complete build log to the model.

8. Clearer Support Boundaries for Android Logs

The current set of tools can directly return console output from builds and Run Configurations, but there is no dedicated interface for reading the Android Studio Logcat panel.

If the Terminal tool is enabled, Codex can indirectly execute a limited range of ADB queries, for example:

adb logcat -d -v threadtime -t 300

In actual use, it's best to continue filtering by PID, package name, or Tag. Terminal interfaces usually have timeout and output line number limits, making them unsuitable for hanging on real-time log streams for long periods.

4. How to Verify the Configuration is Actually Working

Don't just look at the "connected" status; it's best to do three layers of verification.

First, test read-only capabilities:

Use JetBrains MCP to list the modules and dependencies of the current project, do not call Shell.

Then test IDE semantic capabilities:

Use JetBrains MCP to query the symbol information of MainActivity and check the IDE Inspection issues in this file.

Finally, test execution capabilities:

Use JetBrains MCP to get existing Run Configurations, select a test configuration to execute, and summarize the failure reasons.

If Codex always falls back to Shell, you can explicitly require "Use JetBrains MCP, do not use terminal commands" in the prompt. If tools are completely invisible, check in order:

• Is the IDE running and is the target project open;
• Is MCP Server enabled;
• Are the corresponding tools checked in Exposed Tools;
• Has Codex been restarted;
• Does codex mcp list or /mcp show the service as connected;
• In the case of multiple windows, has the project path been explicitly provided;
• Did build tools interrupt due to timeout.

5. Security Recommendations

MCP Server gains actual IDE and project operation capabilities; do not ignore permission boundaries during configuration:

• Only connect trusted local AI clients;
• Do not expose tools that are not needed;
• It is recommended to keep approval for Terminal, Patch, File Creation, and Run Configuration;
• Before enabling Brave Mode, understand which IDE confirmations it will skip;
• Do not expose the local MCP service to the public internet for convenience;
• After executing modifications, continue to use Git diff, Inspection, build, and test to verify results.

Conclusion

The greatest value of JetBrains MCP Server is not giving Codex another way to read files, but handing over the "semantics, project model, and execution context" that the IDE already possesses to the AI.

Before integration, Codex relied more on the file system and command line to infer the project; after integration, it can query real symbols, call Inspection, execute safe refactoring, reuse Run Configurations, and complete modification and verification in the same workflow. For Android, Kotlin, Java, and large Gradle multi-module projects, this difference will be very noticeable.

If you only plan to enable a few tools, prioritize symbol query, Inspection, modules and dependencies, semantic renaming, build, and Run Configuration—these are also the parts hardest to replace with ordinary Shell.

References

Note: Some content generated by AI.

• JetBrains: MCP Server
• JetBrains Marketplace: MCP Server Plugin
• OpenAI: Model Context Protocol in Codex
• Model Context Protocol Official Introduction