Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pydev-mcp run the tests in my current project and summarize failures"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
pydev-mcp gives LM Studio local models tools for trusted local Python work: run code, manage files, install packages, and check / lint / test code on your own machine.
This plugin executes Python code on the local machine. It is trusted local execution, not a sandbox.
Code can read and write files and run operations under your operating-system permissions. pip install and pip uninstall can run package-maintainer code. Only run code and install packages you trust.
Related MCP server: MCP Python Interpreter
LM Studio with plugin support.
A local Python 3 installation (the tools auto-detect it).
When installed from LM Studio Hub, this plugin creates a .venv virtual environment inside its default Workspace (<pluginDir>/Workspace/.venv/). All MCP tool calls (pydev_run_code, pydev_install_module, …) run inside that venv, so pip-installed packages stay isolated to the project and system Python is untouched. The venv is shared by every project scaffolded under the Workspace, so you only need to set it up once. If no usable .venv exists, it falls back to system python3 / python.
Manual setup:
Linux/macOS: run ./setup-venv.sh (or npm run setup-venv). It creates Workspace/.venv/, upgrades pip/setuptools/wheel, and installs the dev tools these plugins use (ruff, pytest, mypy, coverage, pytest-cov, bandit, build). Idempotent.
Windows: open a terminal in the plugin's Workspace folder and run python -m venv .venv.
Troubleshooting: If pydev_install_module reports "pip not found", ensure Python 3 is installed, then re-run the setup script to recreate .venv/. To force a fresh venv, delete <pluginDir>/Workspace/.venv/ and run LM Studio again.
In any chat where this plugin is enabled, open the chat settings sidebar and set "Workspace Folder Path" to a custom directory if you want files and venv operations elsewhere. Leave it empty to use the default — which is <pluginDir>/Workspace after first install from LM Studio Hub.
How the workspace root affects the venv:
pydev_setup_venvandpydev_get_setup_statusalways operate on<pluginDir>/Workspace/.venv. If you leave it unset, that is<pluginDir>/Workspace/.venv; if you set a custom path, the venv still lives at<pluginDir>/Workspace/.venv/. Every project created withpydev_create_project_structureshares this one venv.
Single Workspace Root Model: All file operations (read, write, search, list) are scoped within this single workspace root. Paths outside it are blocked for safety.
The workspace root defaults to
<pluginDir>/Workspaceafter first install and can be changed via the LM Studio chat settings sidebar.
These tools use the currently selected interpreter. pydev_run_code reports pythonExecutableUsed so you can see which executable ran the code. Use pydev_switch_python_version to list or switch interpreters; you may need to ensure Python is installed and discoverable, then optionally select an explicit path.
Note: The shared
.venvalways lives at<pluginDir>/Workspace/.venv/regardless of which workspace root you configure. The Python interpreter used is always resolved from that venv'sbin/python(orScripts/python.exeon Windows). If you need to use a different interpreter, set thePYDEV_MCP_WORKSPACEenvironment variable before runningscripts/setupVenv.mjs, or manually create a venv at a custom path.
cwd) BehaviorAll tools execute Python with a single, deterministic working directory — this resolves the earlier
"ran in /tmp" and "inconsistent cwd" problems. The rule (implemented once in
src/utils/safePaths.ts's resolveRunCwd) is, in order:
Explicit cwd — if a tool accepts cwd and you pass one, it is validated (must exist and be a
directory) and used as-is.
Otherwise, the target file's directory — when a concrete .py target exists (pydev_run_file,
pydev_run_with_debugger with filePath, …), the working directory is that file's directory.
Otherwise, the workspace root — for tools without a target file (pydev_run_code, pydev_coverage,
pydev_type_check, …) execution happens at the workspace root, never an arbitrary process.cwd().
This keeps from solution import Solution-style imports resolvable no matter where the plugin launched.
Coverage path guarantee: pydev_coverage runs pytest from the workspace root and reports file paths
relative to the workspace root (e.g. src/foo.py, not /mnt/md0/.../Workspace/src/foo.py). The
returned sourcePath / testPath fields are also workspace-relative.
Error-message guarantee: When you pass a path where a directory is expected (the common mistake of
passing a file to sourcePath / testPath), the tool now fails with a message that names the
parameter, states it is a file, and hints at the correct sibling — e.g.
testPath must be a directory, but it is a file: <path>. Point this at your tests directory or a test file.
Install pydev-mcp from LM Studio Hub, then enable or use the plugin in a chat where tools are available. Exact interface wording may vary between LM Studio versions.
41 tools, grouped by task. All file paths are relative to the workspace root — the single directory all tools operate inside. Params marked ? are optional.
Tool | Purpose | Key params |
| Run a short Python string; return output, exit code, timeout, interpreter used |
|
| Run an existing |
|
| Write a string to a temp |
|
| Open an existing |
|
| Open a persistent Python REPL session for step-by-step interactive execution (Jupyter-like) |
|
Tool | Purpose | Key params |
|
|
|
|
|
|
| List or switch the interpreter used by these tools |
|
Tool | Purpose | Key params |
| Create or overwrite ANY text file (any extension) in the workspace |
|
| Read ANY text file (optional line range) |
|
| List files/folders (recursion / filter) |
|
| Exact string replace (not regex) on any text file; optional backup |
|
| Edit any text file by line number: replace / insert / delete |
|
Tool | Purpose | Key params |
| Static syntax/lint check of a string (does not run it) |
|
| Same static check for a file ( |
|
|
|
|
|
|
|
| Run pytest; return pass/fail/skip counts, an actionable summary listing each failing test with file:line + one-line reason, structured |
|
| Compare imports vs installed packages (skips stdlib); suggests install cmd |
|
Tool | Purpose | Key params |
| Create a new project: |
|
Tool | Purpose | Key params |
| Show Python version, active venv path, installed package count, and key environment variables | none |
| Run code or a .py file and print a full traceback with per-frame variable inspection |
|
| Project-wide static type check (mypy/pyright); deeper than pydev_check_for_bugs |
|
| Generate a pytest test-file skeleton (fixture imports + assertion patterns) for a .py file |
|
| Write requirements.txt from pip freeze or from analyzed missing imports |
|
Tip: use pydev_inspect_environment to confirm the active interpreter, pydev_type_check for project-wide type checking, and pydev_run_with_debugger when you need variable values at each traceback frame.
Tool | Purpose | Key params |
| Grep-style content search across a directory tree: returns file paths and matching line numbers for a substring or regex pattern. Great for locating symbols, subroutines, and usages quickly. |
|
| Browse files by filename substring or extension (e.g. |
|
Both stay inside the workspace root and skip noise such as .venv/, node_modules/, and __pycache__/. Use pydev_search_directory to find where code lives; use pydev_find_files to list files by name or extension.
Tool | Purpose | Key params |
| Runs pytest with |
|
| Runs |
|
| Builds Python packaging artifacts (sdist + wheel via |
|
| Static syntax/lint check of a string (does not run it) |
|
| Same static check for a file ( |
|
|
|
|
|
|
|
| Compare imports vs installed packages (skips stdlib); suggests install cmd |
|
| Run cProfile on a Python project to identify performance bottlenecks. Returns top-N functions by total time, call counts, flamegraph-style call tree, and optional natural-language explanation of hotspots. |
|
Tool | Purpose | Key params |
| Ensure | none |
| Report | none |
| Show Python version, active venv path, installed package count, and key environment variables | none |
Tool | Purpose | Key params |
| Grep-style content search across a directory tree: returns file paths and matching line numbers for a substring or regex pattern. Great for locating symbols, subroutines, and usages quickly. |
|
| Browse files by filename substring or extension (e.g. |
|
Both stay inside the workspace root and skip noise such as .venv/, node_modules/, and __pycache__/. Use pydev_search_directory to find where code lives; use pydev_find_files to list files by name or extension.
Tool | Purpose | Key params |
| List all tool names and descriptions (confirms pydev_run_repl is registered) |
|
| Return the current workspace root (absolute path) — the single top-level directory all tools operate inside. Use at session start to confirm the active environment. | none |
All tool paths are relative to the workspace root. Params marked ? are optional. This catalog groups the 41 tools by task and shows a copy-pasteable usage example for each. For full schemas, call pydev_list_tools(includeDetails=true) — it now returns name, group, description, and example for every tool.
run) — 5 toolsTool | Example |
|
|
|
|
|
|
|
|
|
|
packages) — 3 toolsTool | Example |
|
|
|
|
|
|
files) — 5 toolsTool | Example |
|
|
|
|
|
|
|
|
|
|
search) — 2 toolsTool | Example |
|
|
|
|
quality) — 9 toolsTool | Example |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
testing) — 2 toolsTool | Example |
|
|
|
|
scaffold) — 2 toolsTool | Example |
|
|
|
|
environment) — 3 toolsTool | Example |
|
|
|
|
|
|
dev) — 2 toolsTool | Example |
|
|
|
|
meta) — 2 toolsTool | Example |
|
|
|
|
41 tools across 12 sections. The Tools section above gives each tool's purpose and key params; this catalog focuses on quick, copy-paste examples.
Newest tools — AST-based refactoring, docstring auditing, reference generation, migration planning, and instant repo context. All paths are workspace-relative.
Tool | Example |
|
|
|
|
Tool | Example |
|
|
|
|
Tool | Example |
|
|
Tool | Example |
|
|
These tools use the currently selected interpreter. pydev_run_code reports pythonExecutableUsed so you can see which executable ran the code. Use pydev_switch_python_version to list or switch interpreters; you may need to ensure Python is installed and discoverable, then optionally select an explicit path.
pydev_run_code_interactive and pydev_run_file_interactive open a visible terminal window where supported and return immediately. The window stays open so you can read output and errors. Windows desktop sessions are best supported; if no window opens, use the non-interactive tools or check platform support.
pydev_run_repl opens a persistent Python REPL session for step-by-step interactive execution (a Jupyter-like experience) and also returns immediately — ideal for debugging and exploratory analysis.
For full usage, exact parameters, examples, and an LLM self-check flow, see skills/pydev-mcp.md.
Run this Python code and show stdout.
Save this script as hello.py.
Run hello.py with these arguments.
Check this code for syntax errors.
Install colorama for the selected interpreter.
prompt example:
Use the `pydev-mcp` MCP tools to solve the programming task described below.
Follow these steps in order:
1. Create a Python project using the appropriate MCP tool.
- Derive the project name from the programming question.
2. Verify that the project’s virtual environment (`venv`) is configured and working.
3. Implement the solution in Python.
- Save the source code under `<project>/src/`.
- Run linting checks.
- Debug and fix any issues.
- Execute the code and verify that the output is correct.
- Save the final corrected implementation.
4. Create and run tests.
- Use `<project>/tests/` as the test working directory.
- Ensure the tests pass.
5. Generate code coverage and security scan report.
6. Create the following documentation under `<project>/doc/`:
- An implementation document explaining the solution.
- A project report summarizing the implementation, validation, coverage, security and test results.
Do not skip any step. Confirm the result of each step before proceeding to the next one.
---
Programming task:
(...)prompt_examples/new_project.txt prompt_examples/source_tree_analysis.txtprompt_examples/hotfix_rework.txtprompt_examples/refactory.txtprompt_examples/performance_optimization.txtprompt_examples/dependency_version_migration.txt prompt_examples/security_hardening.txtprompt_examples/test_coverage_expansion.txtPython not found: install Python locally and make sure it is discoverable.
Wrong interpreter selected: use pydev_switch_python_version to list and select the intended interpreter, then check pythonExecutableUsed.
Interactive window does not open: use non-interactive tools or check whether visible terminal windows are supported on your platform.
Package install fails: confirm the selected interpreter can run pip, the package name is valid, and the machine has the required permissions and network access.
File path rejected: use a path inside the configured workspace.
This plugin is licensed under the Apache License 2.0.
Run these from the plugin root:
npm install
npm run typecheck
npm run build
lms dev
lms login
lms pushpostinstall runs scripts/setupVenv.mjs, which creates <pluginDir>/Workspace/.venv/ and installs the essential dev tools ruff, pytest, mypy, coverage, pytest-cov, bandit, and build (then verifies each is importable). If the venv is missing, run ./setup-venv.sh to fix it.
Config file note: The
.pydev-mcp-config.jsonfile created byscripts/setupVenv.mjspersists only theworkspaceRootfield. It does NOT persist apythonExecutablePath. The Python interpreter used is always resolved from<pluginDir>/Workspace/.venv/bin/python. If you need to use a different interpreter, set thePYDEV_MCP_WORKSPACEenvironment variable before runningscripts/setupVenv.mjs, or manually create a venv at a custom path.
Fork from soumyajit7038/python-tools
Add macOS/Linux support
Add Python venv
Add workspace folder setting
Add code quality tools
Add code security tool
Add more grep-like search for source tree travel
Add software engineering guideline in skills/pydev-mcp.md
Add default workspace root under <pluginDir>/Workspace, persisted to .pydev-mcp-config.json on install
Refactor: simplify to single workspace root model
Refactor: update all file path resolution to use only workspace root
Refactor: reduce tool count from 36 → 41
Add pydev_run_repl — a persistent interactive Python REPL tool (Jupyter-like, step-by-step execution) with optional cwd and timeoutSeconds
Add pydev_profile — run cProfile on a Python project to identify performance bottlenecks, returning top-N functions by total time, call counts, flamegraph-style call tree, and optional natural-language explanation of hotspots
Refactor: unify working-directory (cwd) resolution — every run / debug / coverage tool now executes from one deterministic cwd (explicit cwd → target file's directory → workspace root) via resolveRunCwd; debug & inline-code targets live under <workspaceRoot>/.pydev-tmp, never system /tmp
Refactor: pydev_coverage reports workspace-relative paths — the coverage table and sourcePath / testPath result fields are relative to the workspace root, eliminating opaque absolute paths (e.g. /mnt/md0/.../Workspace/...)
Improve: contextual error messages — ensureDirectory / validateWorkingDirectory now distinguish "not found" from "is a file", name the offending parameter, and add usage guidance
Docs: add "Working Directory (cwd) Behavior" guarantee section documenting the unified cwd rule, the coverage path guarantee, and the error-message guarantee
Version bump 2.2.0 → 3.0.0 (major release: breaking tool-name simplification + removal of pydev_run_file_with_args)
Add new features required by LLM.
This server cannot be deployed
Run Python code from natural language prompts, with optional PyPI package install.
Build, deploy, and sell AI agents for local-service businesses - from your IDE.
Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.
Manage SysML2 projects and files directly through your coding agent.
