MCP Server

Analysis tools

build_project

Triggers building of the project or specified files, waits for completion, and returns build errors. Use this tool to build the project or compile files and get detailed information about compilation errors and warnings.

You have to use this tool after performing edits to validate if the edits are valid.

Parameters:

• rebuild: Whether to perform a full rebuild of the project. Defaults to false. Effective only when filesToRebuild is not specified.

• filesToRebuild: If specified, only compile files with the specified paths. Paths are relative to the project root.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

get_file_problems

Analyzes the specified file for errors and warnings using IntelliJ inspections. Use this tool to identify coding issues, syntax errors, and other problems in a specific file.

Returns a list of problems, including severity, description, and location information.

Parameters:

• filePath: Path relative to the project root.

• errorsOnly: Whether to include only errors or both errors and warnings.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

get_project_dependencies

Returns a list of all dependencies defined in the project. Provides structured information about library names.

Parameters:

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

get_project_modules

Returns a list of all modules in the project with their types. Provides structured information about each module, including its name and type.

Parameters:

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Code insight tools

get_symbol_info

Retrieves information about the symbol at the specified position in the specified file. Provides the same information as IntelliJ IDEA's Quick Documentation feature. The information may include the symbol's name, signature, type, documentation, and other details, depending on the programming language.

If the position references a symbol, the tool will return a code snippet with the symbol's declaration, if available. Use this tool to understand a symbol's declaration, semantics, and location.

Parameters:

• filePath: Path relative to the project root.

• line: 1-based line number.

• column: 1-based column number.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Database-specific tools

To guarantee strictly read-only access for an AI agent, use a database user with properly restricted (read-only) privileges and configure the data source to use that user.

get_database_object_description

Retrieves the structure of a database object (columns, types, keys, indexes) within a particular schema as a hierarchical text representation.

In case of ambiguity returns definitions of all applicable objects.

Parameters:

• connectionId: Unique connection ID.

• databaseName: Name of the database the schema belongs to. Can be empty if the DBMS has no databases but only schemas.

• schemaName: Name of the schema.

• kind: Set this parameter to a particular object kind code to list only objects of that kind. Set it to null to retrieve all objects in the schema.

• objectName: Object name of the specified kind (e.g., table or view name). May not be empty.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

list_database_connections

Retrieves a list of configured database connections or data sources in the project. For each connection returns its unique ID, name, DBMS, and driver name.

test_database_connection

Returns connection diagnostic info:

• Flag indicating if the connection is problematic: yes, no, or unknown.

• Detailed information about the database connection such as DBMS type, version, and JDBC driver.

• Summary of the connection attempt result. In case of a failure, contains a DBMS-provided error description.

Parameters:

• id: Unique connection ID.

list_database_schemas

Retrieves a list of database schemas in the specified database connection.

For each schema, the tool returns the schema's own name as well as the database name (empty if not applicable).

Parameters:

• connectionId: Unique connection ID.

• selectedOnly: True if only the schemas selected in the database tree should be listed; false if all schemas should be listed.

list_schema_object_kinds

Retrieves a list of supported schema object kinds for the given database connection. For each object kind, returns the object kind unique code and human-readable name.

Parameters:

• connectionId: Unique connection ID.

list_schema_objects

Retrieves a list of database objects within the given schema. For each object, returns the object name within the schema and its kind.

Parameters:

• connectionId: Unique connection ID.

• schemaName: Name of the schema.

• databaseName: Name of the database the schema belongs to. Can be empty if the DBMS has no databases but only schemas.

• kind: Set this parameter to a particular object kind code to list only objects of that kind. Set it to null to retrieve all objects in the schema.

list_recent_sql_queries

This feature is not available in free subscription plans.

Retrieves a list of recent, including currently running, queries for the given database connection.

For each query returns:

• Unique ID of a query session.

• Time spent on running the query (in milliseconds).

• The current state of the query. For example, running, cancelling, finished, and so on.

• Completion status of the query. For example, success, finished with error, cancelled, and so on.

• Text of the query.

Parameters:

• connectionId: Unique connection ID.

cancel_sql_query

Cancel a running query using its unique ID.

Parameters:

• sessionId: Query session ID.

execute_sql_query

Execute a SQL query against the given database connection.

The tool reports execution status: success or error. For errors, it also provides an error description.

If the query returns data, it is appended to the tool response in CSV format.

Parameters:

• connectionId: Unique connection ID.

• queryText: SQL query to be executed.

preview_table_data

Returns preview data of the table, view, materialized view, or other table-like object using a given database connection.

The tool returns table content in CSV format.

Parameters:

• connectionId: Unique connection ID.

• schemaName: Name of the schema.

• databaseName: Name of the database the schema belongs to. Can be empty if the DBMS has no databases but only schemas.

• tableName: Name of the table.

• maxRowCount: Maximum number of rows to return. Default is 100.

Developer kit MCP tools

find_lock_requirement_usages

Analyzes the usage of the Read/Write lock for the method under the caret. Also analyzes call paths to some depth. Use this tool to identify possible usages of Read/Write lock requirements. Returns a list of lock requirements with the call path to them.

Parameters:

• filePath: Path relative to the project root.

• line: Line where cursor is located.

• column: Column where cursor is located.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

find_threading_requirements_usages

Analyzes the usage of threading constraints (i.e., whether the method needs to run on the UI thread or on the background thread) for the method under the caret. Also analyzes call paths to some depth. Use this tool to identify possible usages of threading requirements. Returns a list of threading requirements with the call path to them.

Parameters:

• filePath: Path relative to the project root.

• line: Line where cursor is located.

• column: Column where cursor is located.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Execution tools

execute_run_configuration

Run either an existing run configuration by name or a temporary run configuration created from a code location (filePath + line) in the current project, then wait up to the specified timeout for it to finish. Use this tool with either a configuration name returned by get_run_configurations, or with a run point (filePath + line) returned by get_run_configurations(filePath = ...).

Optional launch overrides (programArguments, workingDirectory, envs) are applied only for this run and are not persisted. Do not pass these override parameters unless you explicitly need to change the configured launch values for this run. Missing/null override parameters keep existing run configuration values unchanged. For string overrides (programArguments, workingDirectory), missing/null or empty string ("") keeps the existing value unchanged. Pass a whitespace-only string such as " " to clear an existing value for this launch.

Pass either configurationName, or filePath together with line. These modes are mutually exclusive.

Behavior:

• When waitForExit=true, waits up to timeout milliseconds for process termination. If the timeout expires, the process keeps running in the background and exitCode is omitted from the result.

• When waitForExit=false, waits only for the process to start, then returns immediately without applying timeout.

• fullOutputPath points to a temp file with the full raw output and may continue growing while the process is alive.

Returns the execution result including current output snapshot, optional exit code, and optional fullOutputPath.

Parameters:

• configurationName: Name of the existing run configuration to execute.

• filePath: File path relative to the project root. Provide together with line to create and execute a temporary run configuration from code context.

• line: 1-based line number for filePath. Provide together with filePath and do not combine with configurationName.

• timeout: Timeout in milliseconds.

• waitForExit: Whether to wait for process termination. If false, the tool returns immediately after the process starts and ignores timeout.

• programArguments: Optional program arguments override for this launch only. Missing/null or empty string keeps the existing value; whitespace-only string clears it.

• workingDirectory: Optional working directory override for this launch only. Missing/null or empty string keeps the existing value; whitespace-only string clears it.

• envs: Optional environment variable overrides for this launch only. Missing/null keeps existing env unchanged; when provided, values are merged over existing env.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

get_run_configurations

Returns either project run configurations or executable code locations, depending on the input.

Without filePath, this tool lists the project's existing run configurations. The result includes configuration names and, when available, launch details such as program arguments, working directory, environment variables, and supportsDynamicLaunchOverrides.

supportsDynamicLaunchOverrides is the source-of-truth capability flag for one-time launch overrides (programArguments, workingDirectory, envs) in execute_run_configuration and xdebug_start_debugger_session. Only pass those override parameters when this flag is true for the selected configuration.

With filePath, this tool discovers executable entry points (run points) in that file, such as test methods, main methods, or other executable entry points where the IDE shows a Run gutter icon. The result contains filePath and runPoints; use the returned line numbers with execute_run_configuration to run from code.

Parameters:

• filePath: Optional file path relative to the project root. When provided, returns run points (executable entry points) in the file instead of project-wide run configurations.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

File tools

create_new_file

Creates a new file at the specified path within the project directory. Optionally, writes the provided text into the file.

Parameters:

• pathInProject: Path where the file should be created relative to the project root.

• text (optional): Content to write into the new file.

• overwrite: Whether to overwrite an existing file. If set to false, an exception is thrown in case of a conflict.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

find_files_by_glob

Searches for all files in the project whose relative paths match the specified glob pattern. The search is performed recursively in all subdirectories of the project directory or a specified subdirectory. Use this tool to find files by a glob pattern (for example, **/*.txt).

Parameters:

• globPattern: Glob pattern to search for. The pattern must be relative to the project root. Example: src/**/*.java.

• subDirectoryRelativePath (optional): Subdirectory relative to the project to search in.

• addExcluded: Whether to add excluded/ignored files to the search results. Files can be excluded by the user or by ignore rules.

• fileCountLimit: Maximum number of files to return.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

find_files_by_name_keyword

Searches for all files in the project whose names contain the specified keyword (case-sensitive). Use this tool to locate files when you know part of the file name.

Parameters:

• nameKeyword: Substring to search for in the file names.

• fileCountLimit: Maximum number of files to return.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

get_all_open_file_paths

Returns the paths of all files opened for editing in the active editor or any other open editors, relative to the project root. Use this tool to explore currently open editors.

Parameters:

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

list_directory_tree

Provides a tree representation of the specified directory in the pseudo-graphic format, similar to the tree utility. Use this tool to explore the contents of a directory or the entire project. Prefer this tool over command-line utilities like ls or dir for directory listing.

Parameters:

• directoryPath: Path relative to the project root.

• maxDepth: Maximum recursion depth.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

open_file_in_editor

Opens the specified file in the JetBrains IDE editor. Requires a filePath parameter containing the path to the file to open. The file path can be absolute or relative to the project root.

Parameters:

• filePath: Path relative to the project root.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Formatting tools

reformat_file

Reformats the specified file in the JetBrains IDE. Use this tool to apply code formatting to a file identified by its path.

Parameters:

• path: Path relative to the project root.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

IDE action tools

invoke_ide_action

Invokes an IDE action by its action ID. Use this to trigger any IDE action programmatically (for example, open a tool window or toggle a setting).

Optionally provide file/folder context via filePaths so that actions requiring a selected file, folder, or module work correctly (for example, MarkExcludeRoot, ReformatCode, NewFile).

Parameters:

• actionId: The action ID to invoke (for example, ActivateTerminalToolWindow, TogglePresentationMode).

• filePaths: Optional file/folder paths (relative to project root) to provide as context for the action.

search_ide_actions

Searches for IDE actions by text query. Use this to discover available actions before calling invoke_ide_action.

Parameters:

• query: Text to search for in the action ID, name, and description (case-insensitive substring match).

• limit: Maximum number of results to return (default: 50).

• includeGroups: Whether to include action groups in results (default: false).

Inspection generator MCP Tools

validate_inspection_kts

Validates an inspection.kts script against specification examples. Compiles the inspection and runs it against positive/negative examples. Returns compilation status and detailed verification results.

Positive examples should trigger the inspection (problems expected). Negative examples should NOT trigger the inspection (no problems expected on forbidden lines).

Returns overall success, per-example results, and aggregation statistics.

Parameters:

• inspectionKtsCode: The inspection.kts script content to compile and validate.

• pathToSpecification: Path to specification with examples to validate against.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Inspection KTS MCP tools

generate_inspection_kts_api

Returns the Inspection KTS API documentation for the target language. Provides available classes and functions that can be used when writing inspection.kts files.

Parameters:

• language: Target language: 'Java' or 'Kotlin'.

• wrapInTags: If true, wraps the API content in <API> and <api.kt> tags.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

generate_inspection_kts_examples

Returns example inspection.kts templates for the target language to guide code generation. Provides XML-wrapped examples showing how to write inspections using the InspectionKts API.

Parameters:

• language: Target language: 'Java' or 'Kotlin'.

• includeAdditionalExamples: If true, includes additional curated examples besides templates.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

generate_psi_tree

Creates a PSI tree for the provided Java or Kotlin code and returns it as indented text. Use this tool to understand the PSI structure of code snippets when writing inspections. The output shows element types and their hierarchy, with hints about when node.children() is needed.

Parameters:

• code: Source code snippet to parse.

• language: Target language: 'Java' or 'Kotlin'.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

run_inspection_kts

Compiles an inspection.kts script and runs it against a target file. Returns compilation errors if any, or the list of problems found by the inspection. Use this tool to test inspection.kts scripts during development.

Parameters:

• inspectionKtsCode: The inspection.kts script content to compile and run.

• contextPath: Relative path of the target file inside project to analyze (for example, src/my/package/Example.kt).

• targetFileContent: The content of the target file to analyze. If not provided, the file must exist in the project.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Inspection tools

get_inspections

Analyzes a file using the IDE's inspections. Returns problems with severity, description, location, and available quick fixes. Use this tool after editing files to validate the code.

Each problem includes available quick fixes that can be applied using apply_quick_fix.

Parameters:

• filePath: Path relative to the project root.

• minSeverity: Minimum severity level: ERROR, WARNING, WEAK_WARNING, INFORMATION. Default: WEAK_WARNING.

• timeout: Timeout in milliseconds.

apply_quick_fix

Applies a quick fix to resolve an inspection problem.

Use the quickFix information from get_inspections result to identify which fix to apply. The tool will re-run the highlighting at the specified location and apply the matching fix.

Parameters:

• filePath: Path relative to the project root.

• line: 1-based line number where the problem is located.

• column: 1-based column number where the problem is located.

• quickFixName: The name of the quick fix to apply (from quickFixes[].name in get_inspections result).

PHP debugger tools

xdebug_single_file

Starts an Xdebug session for a single PHP script.

Parameters:

• path: Absolute path to the PHP script to debug.

xdebug_start_server

Starts PHP's built-in dev server and the Xdebug listener. After calling this, use xdebug_set_breakpoint to set breakpoints, then xdebug_request to debug a specific URL.

Parameters:

• projectRoot: Absolute path to the PHP project root directory.

• host: Host to bind the dev server to (default: localhost).

• port: Port for the dev server (default: 8081).

xdebug_request

Makes an HTTP request to the dev server and starts debugging it. Automatically establishes the debug connection and applies all breakpoints. Returns the debugger state: if a breakpoint was hit, the session is paused and you can inspect with xdebug_stack, xdebug_context, or step with xdebug_step_over/xdebug_step_into. If no breakpoint was hit, the script ran to completion.

Parameters:

• url: Full URL to request, for example http://127.0.0.1:8081/add?a=3&b=5.

xdebug_stop_server

Stops the PHP dev server and the XDebug listener. Use this when you are completely done debugging.

Parameters: none.

xdebug_set_breakpoint

Sets a line breakpoint. Can be called before or during a debug session. Breakpoints persist across requests — they are automatically re-applied on each new xdebug_request call.

Parameters:

• line: Line number to set breakpoint on.

• file: File path (absolute or relative to project root). Optional for single-script mode.

xdebug_run

Resumes execution until the next breakpoint or end of script. If a breakpoint is hit, the session pauses and you can inspect or step. If the script ends, the session is finished.

Parameters: none.

xdebug_step_into

Steps into the next function call. The session pauses at the first line of the called function. Use xdebug_stack and xdebug_context to inspect.

Parameters: none.

xdebug_step_over

Executes the current line and pauses at the next line in the same scope. Use xdebug_stack and xdebug_context to inspect.

Parameters: none.

xdebug_step_out

Runs until the current function returns, then pauses in the caller. Use xdebug_stack and xdebug_context to inspect.

Parameters: none.

xdebug_stack

Returns the current call stack with file paths and line numbers. Only available when paused at a breakpoint.

Parameters: none.

xdebug_context

Returns all variables in scope at the given stack depth (default: 0 = current frame). Includes locals and superglobals. Only available when paused at a breakpoint.

Parameters:

• stackDepth: Stack depth to inspect (default: 0 = current frame).

xdebug_status

Returns the current debugger session state (starting, running, break, stopping).

Parameters: none.

xdebug_pause

Pauses execution at the current point. Use when the script is running and you want to inspect where it is.

Parameters: none.

xdebug_eval

Evaluates a PHP expression in the current scope and returns the result. Only available when paused at a breakpoint. Examples: $user->getName(), count($items), $a + $b.

Parameters:

• expression: PHP expression to evaluate.

xdebug_property_get

Returns the value of a specific variable by name. Supports nested properties like $obj->field or $arr[0]. Only available when paused at a breakpoint.

Parameters:

• name: Variable name, e.g. $myVar, $this->field.

• stackDepth: Stack depth to inspect (default: 0 = current frame).

xdebug_property_set

Changes the value of a variable in the current scope. Only available when paused at a breakpoint.

Parameters:

• name: Variable name, e.g. $myVar.

• value: New value as a PHP literal, e.g. 42, \"hello\", true.

xdebug_breakpoint_list

Lists all breakpoints currently set in the XDebug engine.

Parameters: none.

xdebug_breakpoint_remove

Removes a breakpoint by its ID. Use xdebug_breakpoint_list to find breakpoint IDs.

Parameters:

• id: Breakpoint ID to remove.

xdebug_detach

Ends debugging and lets the PHP script finish normally. Use this when debugging with the dev server — the HTTP response completes and the server is ready for the next xdebug_request.

Parameters: none.

xdebug_stop

Terminates the PHP script immediately and ends the debug session. Use this when debugging a single script with xdebug_single_file.

Parameters: none.

PHP project context tools

get_composer_dependencies

Returns all Composer packages installed in the project with their exact versions.

Reads from the already-indexed composer.lock data — no disk I/O or network calls. In monorepo setups, packages from all composer.json sub-projects are included.

Use this to determine which libraries and versions are available before generating code.

Parameters:

• nameFilter: Glob pattern to filter packages by name (e.g. "laravel/*", "*phpunit*", "symfony/console"). Case-insensitive. Omit to return all packages.

get_php_project_config

Returns the PHP project configuration as seen by PhpStorm.

Includes: configured PHP language level, interpreter details (name, path, local/remote), and PHP runtime information (exact version, loaded extensions, php.ini path, debuggers).

This data comes from IDE settings and cached interpreter metadata — no disk I/O or network calls. Use this to understand the project's PHP environment before generating or analyzing code.

The language level may differ from the system PHP version (e.g. project targets 8.1 while system runs 8.3). For remote interpreters (Docker/SSH), this is the only way to get PHP info.

Parameters: none.

Monorepo developer kit MCP tools

get_project_status

Check if the project is ready for code analysis operations. Returns indexing and scanning status. Use before heavy operations like lint_files or get_file_problems to avoid timeouts.

Parameters:

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Read tools

read_file

Reads a file in the project directory or from any project dependency or other project source root. Can read sources inside Jar/Jrt files and decompile Java class files inside Jar/Jrt files or on disk. Returns numbered lines (1-indexed) as text.

Modes:

• slice

• lines

• line_columns

• offsets

• indentation

Mode details:

• slice uses start_line and max_lines.

• lines uses start_line/end_line (inclusive).

• line_columns uses start_line/start_column and end_line/end_column (end is exclusive; end_line defaults to start_line).

• offsets uses start_offset/end_offset (end is exclusive).

• indentation uses start_line with max_levels/include_*.

max_lines caps the total output in all modes; context_lines applies to range modes (per side).

Parameters:

• file_path: Path to the file. Supports project-relative paths, paths with '..', absolute paths, archive entries like /path/lib.jar!/pkg/Foo .class, and URLs such as file://, jar://, and jrt://. Any path returned from the other tools can be passed as is (e.g. paths from search_* tools).

• mode: Read mode: slice, lines, line_columns, offsets, or indentation.

• start_line: 1-based line number to start reading from.

• max_lines: Maximum number of lines to return (slice uses as line count; all modes cap output).

• end_line: 1-based end line for lines/line_columns mode (inclusive for lines; exclusive for line_columns).

• start_column: 1-based start column for line_columns mode.

• end_column: 1-based end column for range read (exclusive).

• start_offset: 0-based start offset for offsets mode (requires end_offset).

• end_offset: 0-based end offset for offsets mode (exclusive).

• context_lines: Number of context lines to include around the range (per side).

• max_levels: Indentation mode: maximum indentation levels to include (0 = only anchor block).

• include_siblings: Indentation mode: include sibling blocks at the same indentation level.

• include_header: Indentation mode: include header comments/annotations directly above anchor.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Refactoring tools

rename_refactoring

Renames a symbol (variable, function, class, etc.) in the specified file. Use this tool to perform rename refactoring operations.

Unlike a simple text search-and-replace, the rename_refactoring tool is a context-aware utility that understands the code's structure. It intelligently updates all references to the specified symbol throughout the project, ensuring code integrity and preventing broken references. It is always the preferred method for renaming programmatic symbols.

The tool returns a success message if the rename operation was successful, or an error message if the file or symbol cannot be found, or if the rename operation fails.

Parameters:

• pathInProject: Path relative to the project root.

• symbolName: Name of the symbol to rename.

• newName: New name for the symbol.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Search tools

search_file

Searches for files by glob pattern within the project. Use this tool when you need to match file paths using glob syntax.

Glob patterns are relative to the project root.

Examples:

• "**/*.kt"

• "src/**/Foo*.java"

• "build.gradle.kts"

Patterns without '/' are treated as "**/pattern". paths are optional additional glob filters relative to the project root.

Parameters:

• q: Glob pattern to search for.

• paths: Optional list of project-relative glob patterns to filter results. Supports ! excludes. Trailing / expands to **. Patterns without / are treated as **/pattern. Empty strings are ignored.

• includeExcluded: Whether to include excluded/ignored files in results.

• limit: Maximum number of results to return.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

search_regex

Searches for regex matches within project files. Use this tool when you need regex search with snippet results. Results include match coordinates when available (1-based line/column, 0-based offsets).

Paths are glob patterns relative to the project root.

Examples:

• ["src/**", "!**/test/**"]

• ["**/*.kt"]

• ["foo/"]

Parameters:

• q: Regex pattern to search for.

• paths: Optional list of project-relative glob patterns to filter results. Supports ! excludes. Trailing / expands to **. Patterns without / are treated as **/pattern. Empty strings are ignored.

• limit: Maximum number of results to return.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

search_symbol

Searches for symbols (classes, methods, fields). Use this tool for semantic lookup by identifier fragments. Results include match coordinates when available (1-based line/column, 0-based offsets).

Paths are glob patterns relative to the project root.

By default, this searches project symbols only. If you don't find a suitable result, try again with include_external=true to search SDK and library symbols too.

Parameters:

• q: Symbol query text.

• paths: Optional list of project-relative glob patterns to filter results. Supports ! excludes. Trailing / expands to **. Patterns without / are treated as **/pattern. Empty strings are ignored.

• include_external: Whether to include SDK and library symbols. Disabled by default; if nothing suitable is found, try again with include_external=true.

• limit: Maximum number of results to return.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

search_text

Searches for a text substring within project files. Use this tool for fast text search with snippet results. Results include match coordinates when available (1-based line/column, 0-based offsets).

Paths are glob patterns relative to the project root.

Examples:

• ["src/**", "!**/test/**"]

• ["**/*.kt"]

• ["foo/"]

Parameters:

• q: Text to search for.

• paths: Optional list of project-relative glob patterns to filter results. Supports ! excludes. Trailing / expands to **. Patterns without / are treated as **/pattern. Empty strings are ignored.

• limit: Maximum number of results to return.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Structural search tools

search_structural

Searches for code patterns using Structural Search (SSR). Unlike text/regex search, SSR understands code structure semantically.

Pattern syntax examples (PHP)

Basic patterns:

• $a$->$b$() - any method call on any object.

• new $Class$() - any constructor call.

• class $a$ extends $b$ {} - class inheritance.

• $a$ = $b$ - any assignment.

Variables in patterns:

• $name$ denotes a pattern variable (matches any element of that kind).

• $a${2,5} - count constraint: matches 2 to 5 occurrences.

• $a$+ - one or more occurrences.

• $a$* - zero or more occurrences.

Use get_structural_patterns to see predefined PHP patterns with descriptions.

Known limitations

PHP SSR has some limitations compared to Java SSR:

• Some class modifiers (for example, readonly) may not be matched.

• Complex nested patterns with constraints may not work as expected.

• Use get_structural_patterns to discover reliably working patterns.

Constraints

You can add constraints to pattern variables via the constraints parameter. Variable names in constraints use the name without dollar signs (for example, "b" for $b$):

• regex: Match variable text against a regex (for example, "^get.*" for methods starting with "get").

• invertRegex: Invert the regex match (match if NOT matching).

• minCount/maxCount: Occurrence count bounds.

• exprType: Match expression type (for example, "string", "int").

Example constraints:

{ "b": {"regex": "^get.*", "minCount": 1, "maxCount": 1} }

Parameters:

• pattern: SSR pattern to search for (for example, $a$->$b$() for method calls).

• fileType: File type name for the language to search (for example, PHP, Java, Kotlin, Python).

• directoryToSearch: Directory to search in, relative to project root. If not specified, searches the entire project.

• constraints: Variable constraints as a map from variable name (without dollar signs) to constraint object. Example: {"b": {"regex": "^get.*"}}.

• maxResults: Maximum number of matches to return. Default: 100.

• timeout: Timeout in milliseconds.

get_structural_patterns

Lists predefined PHP structural search patterns with descriptions.

These patterns provide common search templates that can be used directly or as a reference for creating custom patterns.

Categories:

• General: Class, interface, trait definitions and structure.

• Expressions: Assignments, method calls, field access, etc.

• Suspicious: Potentially problematic code patterns.

Parameters:

• category: Filter patterns by category: 'General', 'Expressions', 'Suspicious'. If not specified, returns all patterns.

Terminal tools

execute_terminal_command

Executes a specified shell command in the IDE's integrated terminal. Use this tool to run terminal commands within the IDE environment.

Important features and limitations:

• Checks if a process is running before collecting output.

• Limits output to 2000 lines (truncates any excess).

• Times out after the specified timeout, with a notification.

• Requires user confirmation unless Brave Mode is enabled in the settings.

Returns possible responses:

• Terminal output (truncated if over 2000 lines).

• Output with an interruption notice if the command times out.

• Error messages for various failure cases.

Parameters:

• command: Shell command to execute.

• executeInShell: Whether to execute the command in the user's default shell (bash, zsh, etc.). Useful if the command is a shell script or if it is important to preserve the real environment of the user's terminal. If set to false, the command will be started as a process.

• reuseExistingTerminalWindow: Whether to reuse an existing terminal window to avoid creating multiple terminals.

• timeout: Timeout in milliseconds.

• maxLinesCount: Maximum number of lines to return.

• truncateMode: How to truncate the text: from the start, in the middle, at the end, or do not truncate at all.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

Text tools

get_file_text_by_path

Retrieves the text content of a file using its path relative to the project root. Use this tool to read file contents when you have the file's project-relative path.

Parameters:

• pathInProject: Path where the file should be created relative to the project root.

• truncateMode: How to truncate the text: from the start, in the middle, at the end, or do not truncate at all.

• maxLinesCount: Maximum number of lines to return.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

replace_text_in_file

Replaces text in a file with flexible options for find-and-replace operations. Use this tool to make targeted changes without replacing the entire file content. This is the most efficient tool for file modifications when you know the exact text to replace.

Returns one of the following responses:

• ok – replacement was successful.

• project dir not found – the project directory cannot be determined.

• file not found – the specified file does not exist.

• could not get document – the file content cannot be accessed.

• no occurrences found – the text to replace was not found in the file.

Parameters:

• pathInProject: Path to target file relative to the project root.

• oldText: Text to be replaced.

• newText: Replacement text.

• replaceAll: Whether to replace all occurrences.

• caseSensitive: Whether the search is case-sensitive.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

search_in_files_by_regex

Searches for a regex pattern within all files in the project using IntelliJ's search engine. Prefer this tool over reading files with command-line tools because it is much faster.

Occurrences in the results are surrounded with || characters. For example: some text ||substring|| text.

Parameters:

• regexPattern: Regex pattern to search for.

• directoryToSearch: Directory to search in, relative to project root. If not specified, searches the entire project.

• fileMask: File mask to search for. If not specified, searches for all files. Example: *.java.

• caseSensitive: Whether the search is case-sensitive.

• maxUsageCount: Maximum number of entries to return.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

search_in_files_by_text

Searches for a text substring within all files in the project using IntelliJ's search engine. Prefer this tool over reading files with command-line tools because it is much faster.

Occurrences in the results are surrounded with || characters. For example some text ||substring|| text.

Parameters:

• searchText: Text substring to search for.

• directoryToSearch: Directory to search in, relative to project root. If not specified, searches the entire project.

• fileMask: File mask to search for. If not specified, searches for all files. Example: *.java.

• caseSensitive: Whether the search is case-sensitive.

• maxUsageCount: Maximum number of entries to return.

• timeout: Timeout in milliseconds.

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.

VCS tools

get_repositories

Retrieves the list of VCS roots in the project. Use this tool to identify all repositories in a multi-repository project.

Parameters:

• projectPath: The project path. Always provide this value if known to reduce ambiguous calls. If only the current working directory is known, you can use it as the project path.