A Model Context Protocol server integrated as a JetBrains IDE plugin that provides tools for interacting with JetBrains IDEs (IntelliJ, PyCharm, etc.) including file operations, text selection/replacement, and terminal command execution
Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This JetBrains IDE plugin exposes 8 tools for IDE manipulation and terminal access. Critical issues: (1) NO parameter descriptions visible in the source for ANY tool, all 8 tools declare inputs but provide no descriptions for their parameters. This is a HARD FAIL per the rubric: 'Every parameter needs a description.' (2) Tool descriptions are present but minimal (15-50 chars), below the production baseline of 194 chars average. (3) NO output schemas are documented, responses are completely opaque to the LLM. (4) NO error handling, validation, or recovery guidance. (5) Dangerous irreversible operations (execute_terminal_command, replace_current_file_text, create_new_file_with_text) lack confirmation patterns or dry-run capability. (6) No distinction between read-only and write operations in tool names or annotations. (7) STDIO transport means this is not remotely accessible. Collectively, these gaps make this server unsuitable for production agent use.
Tools (8)
create_new_file_with_textwrite33/100
Create a new file with the given path and content in the current project
execute_terminal_commandirreversible32/100
Execute any terminal command in JetBrains IDE
get_current_file_pathread only37/100
Get the current file path in JetBrains IDE
get_current_file_textread only37/100
Get the current contents of the file in JetBrains IDE
get_selected_textread only37/100
Get the currently selected text in the JetBrains IDE
get_terminal_textread only37/100
Get the current contents of a terminal in JetBrains IDE
replace_current_file_textwrite32/100
Replace the entire contents of the current file in the JetBrains IDE with new text
replace_selected_textwrite33/100
Replace the currently selected text in the JetBrains IDE with new text
NO output schemas documented. Tools return results but the LLM has no way to know what fields to expect. For example, 'get_current_file_text' likely returns file content, but the exact response structure is invisible. LLMs need to know what fields to expect.'
Add 50 - 150 character descriptions to ALL 8 tools. Current descriptions (15 - 50 chars) lack context. Example: 'get_current_file_text' should be 'Retrieve the complete text content of the file currently open in the editor. Returns empty string if no file is active or file is binary. Use this to read code before making edits.'
Add REQUIRED parameter descriptions for all 4 parameterized tools. Example for 'replace_selected_text': parameter 'text' needs 'The replacement text. May contain multiple lines. Will replace the current selection or insert at cursor if nothing is selected.' Similar for 'path' in create_new_file_with_text: 'The file path relative to the project root (e.g., src/main.py). Must not traverse outside the project (../ not allowed). Parent directories created if needed.'
Document output schemas for all 8 tools. Example: 'get_current_file_text returns {"content": string, "encoding": string, "line_count": number}'. 'execute_terminal_command returns {"exitCode": number, "stdout": string, "stderr": string}'. This enables LLMs to chain tools correctly.
Add dry-run / confirmation for irreversible operations. For 'execute_terminal_command', add optional boolean 'dry_run' param: 'If true, show what would execute but do not run. Use to preview dangerous commands.' For 'replace_current_file_text', require an optional 'confirm' param or return a pending state requiring user approval via Multi-Round-Trip Requests (MCP pattern: 'input_required').
Implement input validation with actionable error messages. Example: 'path' in create_new_file_with_text should reject paths containing '..' and return 'Path traversal not allowed. Paths must be within project directory. Got: ../../../etc/passwd'. For 'execute_terminal_command', validate against a whitelist of safe commands and return 'Command not in allowed list. Permitted: [ls, cat, find, grep, ...]. Got: rm -rf'.
Destructive operations lack confirmation or dry-run. 'execute_terminal_command' can run arbitrary shell code (irreversible; could delete files, terminate processes). 'replace_current_file_text' overwrites entire files without preview. 'create_new_file_with_text' may silently overwrite existing files.
Tool descriptions are too brief (15-50 chars vs. production baseline of 194 chars). Descriptions like 'Get the current file text' lack context for WHEN to use the tool, what it returns, or how it differs from similar tools. State WHAT the tool does, WHEN to use it, and any prerequisites.'
No tool annotations for read-only vs. destructive operations. The rubric baseline includes 'tool annotations (readOnlyHint/destructiveHint/idempotentHint)' in current protocol patterns. This server marks tools with Risk categories (READ_ONLY, WRITE, IRREVERSIBLE) but does not expose these to the protocol, so LLMs cannot reason about operation safety.
Parameter naming lacks specificity for some inputs. 'execute_terminal_command' accepts 'command' (string) but provides no constraint (length, injection risk, allowed commands). 'create_new_file_with_text' accepts 'path' with no description of allowed directory scope, preventing path traversal attacks.
create_new_file_with_textexecute_terminal_command
Add tool annotations to expose operation safety. Register tools with destructiveHint=true for replace_*, create_*, execute_terminal_command, and readOnlyHint=true for get_* tools. This enables the MCP client to apply safety guardrails.
Clarify parameter constraints. For 'execute_terminal_command', add to description: 'Standard shell commands only. Does not support pipes, redirects, or variable expansion. Use single command only (e.g., "ls -la" not "ls | grep foo").' For 'create_new_file_with_text', specify: 'Path must be relative to project root. Characters . / \ allowed; .. not allowed to prevent directory traversal.'
Add per-tool error recovery hints. Example error for 'get_current_file_text' when no file is open: 'No file currently open in editor. Open a file first by clicking on a file in the Project pane, or call another tool that returns file paths to discover available files.' This follows the pattern:recovery-guide.
Consider adding batch operations. If an agent edits multiple files, batch 'replace_file' or 'create_files' tools would reduce round-trips and token overhead per pattern:tool-chain.
Document idempotency. Clarify which tools are safe to retry (all get_* are idempotent; replace_* and execute_terminal_command are NOT, retrying can duplicate edits or re-run commands). Add 'idempotentHint=true' annotation for get_* tools.