Executes a safe command inside the project folder. This is the default command execution tool — use it whenever you are not sure whether a command is dangerous. Commands outside the project or that look dangerous are rejected automatically. If the tool returns isError:true with a rejection message (dangerous or directory_escape), DO NOT try to bypass it by rewriting the command or immediately switching to run_destructive_command without asking the user first. For dangerous operations use run_destructive_command with confirm:true. NOTE: 60s limit (optionally extend via timeoutMs) — not suitable for dev servers / watch mode. Run test suites (jest/npm test), typecheck and builds through this tool or run_command_grep, NOT through the built-in terminal. If the task targets a project other than the primary one (MCP_PROJECT_ROOT), always pass the "cwd" parameter. Get the list of allowed roots via the "list_allowed_roots" tool.

Use ONLY when run_safe_command rejected the command AND the user explicitly confirmed in the chat that they want to run it despite the risk. NEVER set confirm:true automatically in reaction to a rejection from run_safe_command. First restate the risk to the user in your own words (exactly what the command will do and what it could break) and wait for their explicit 'yes' or 'I confirm' in the next message. If the user is not present in the conversation (e.g. an automated run without a human), do not use this tool at all. EXAMPLE: If the user says 'do it' for a general task and you then hit a dangerous rejection, that is not sufficient confirmation — you must explain the specific risk and get a new explicit confirmation. If the task targets a project other than the primary one (MCP_PROJECT_ROOT), always pass the "cwd" parameter. Get the list of allowed roots via the "list_allowed_roots" tool.

Reads a slice of a log file by the given line range. Use this tool instead of re-running the same command with a higher maxLines when you already have the log path saved from a previous run_safe_command / run_destructive_command response. NOTE: the file is read directly via Node.js (not through the shell), so it also works for logs in os.tmpdir().

Runs a command and returns only lines matching the given pattern (case-insensitive regex). Use instead of run_safe_command when you know in advance that the output will be long and you only care about a specific pattern (e.g. searching for 'error' in build output, finding a specific test in test runner output). The command runs in the directory given by the cwd parameter and is subject to the same safety checks as run_safe_command. This is the replacement for Unix 'grep' on Windows — filtering happens in-process, so grep/head/tail are not needed. LIMITATION: The matches themselves can be too long — if you need more control, use run_safe_command first and then read_log_slice on the saved log file. Instead of Unix patterns like 'cmd /c ... | findstr ... & echo DONE' use THIS tool with a pattern — it filters in-process. If the task targets a project other than the primary one (MCP_PROJECT_ROOT), always pass the "cwd" parameter. Get the list of allowed roots via the "list_allowed_roots" tool.

Returns the allowed-roots configuration of this MCP server: the primary project (MCP_PROJECT_ROOT), all registered roots (MCP_EXTRA_ROOTS, including globs), the existing projects under them (the list of directories you can use as "cwd") and whether MCP_BLOCK_CROSS_ROOT_READS is enabled. Use THIS tool whenever you need to find out whether — and with which "cwd" parameter — you can run a command in another project. It runs no commands — it only reads the configuration and lists directories. A project with a friendly name is shown as { path, name } and you can pass its "name" as "cwd".

Verifies whether the given path (or a friendly project name) is inside the allowed roots of this MCP server and returns the exact "cwd" to use for running commands. Use this tool when you need to find out whether — and with which "cwd" — you can work in a specific project (e.g. your workspace folder). On success: { ok: true, cwd, matchedRoot, name? }; on failure: { ok: false, error, roots }. Runs no commands — it only validates the configuration.

Find all occurrences of a symbol across a workspace. Structured output with file, line, column, context. Optional language-aware mode (rust/typescript/python/cpp) adds role annotations: declaration, import, or usage. Use this tool BEFORE any refactoring session to understand what will break when a symbol is renamed or moved.

Read the full text of a function, struct, class, or method from a file. Returns precise line range + content. Includes leading annotations (#[derive], @decorator, /// doc comments). String/comment-aware bracket matching prevents false depth counts from braces inside strings or comments.

Split a large file into multiple smaller files based on top-level declarations. Optionally generates a combining file (mod.rs / index.ts / init.py). Use dryRun: true (default) to preview the layout before writing.

Apply multiple file edits atomically with rollback on failure. Validates all edits first — if any search string is not found, NO files are modified. Use dryRun: true (default) to preview changes.

Generate a new module file with correct imports, declarations and visibility. Reads the source file, extracts the specified symbols, and writes them to the target module path. Returns error with unknownSymbols list if any symbols are not found.

Semantic diff between old and new code. Catches accidental deletions before compilation. Checks: function count, signatures, export count, imports, comment ratio. Intentionally conservative — renames appear as errors requiring explicit confirmation.

Report a bug, improvement, or feature request about any MCP tool in this server. Writes structured feedback to .mcp/FEEDBACK.md (project-specific, gitignored). Use this when a tool produces unexpected results, crashes, or when you need a new capability. Entries are idempotent — duplicate reports are skipped.

List feedback entries from .mcp/FEEDBACK.md. Optionally filter by type, tool name, or status. Use this to check existing feedback before creating new entries, or to review reported issues.

Close an existing feedback entry by ID — sets status to "closed" and optionally adds resolution text. Use this to mark feedback items as resolved after fixing them.

List all available MCP tools with descriptions. Use this to discover available tools before starting a task.

Get detailed help for a specific MCP tool — parameters, types, defaults, description.