How do I use LocalREPL MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LocalREPL MCP Server compute the first 10 Fibonacci numbers" 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.

LocalREPL MCP Server

by angrysky56

Overview Schema Source Related Servers Discussions Admin

Python

Local

LocalREPL MCP Server

A locally-running Python REPL server that integrates with Claude Desktop through the Model Context Protocol (MCP).

`local-repl-cli` skill

This repo ships an agent skill at local-repl-cli-skill/ that teaches Claude to drive modern, token-efficient CLI tools (rg, fd, ast-grep, bat, sd, jq, yq, tokei, eza, dust, procs, delta, hyperfine, watchexec, just) through the LocalREPL shell bridge — with a count-before-enumerate discipline, structured --json output, and the MCP-subprocess gotchas documented under local-repl-cli-skill/reference/.

Deploy it to ~/.claude/skills/ as a live symlink (no copying, no drift):

just deploy-skill          # symlinks ~/.claude/skills/local-repl-cli -> local-repl-cli-skill/
just check-skill-tools     # verify the expected CLI tools are installed

For a general, execution-agnostic version of this CLI knowledge (cross-platform, not tied to LocalREPL or any one MCP), see the separate AI-CLI skill in the ai_workspace.

Related MCP server: MCP Python Toolbox

Features

Local REPL: Runs a Python REPL server locally

1. System Discovery Workflow

Purpose: Methodical exploration of the full system capabilities
Approach: Phase-by-phase discovery with comprehensive documentation
Output: Complete system mapping and enhancement opportunities

2. Advanced Workflow Orchestration

Purpose: Complex multi-stage workflows with dependency management
Features: Task execution engine, error handling, performance monitoring
Templates: Data analysis, research, multi-agent coordination workflows

3. Strategic Capability Enhancement

Purpose: Systematic enhancement of system capabilities
Framework: Phase 1 (Planning) → Phase 2 (Execution) → Phase 3 (Adaptation)
Implementation: Sample agent communication and performance monitoring systems

**4. Agent Communication and Performance Monitoring

Persistent Agent Intelligence with JSON state storage
Empowerment Optimization Framework with energy tracking
Advanced Memory Systems with categorization and tagging
Workflow Orchestration capabilities
Evolution Database tracking agent learning
Multi-REPL Coordination for parallel processing

5. Other Advantages

Completely Local: Run Python code directly on your machine without any remote dependencies
State Persistence: Maintain state between code executions (completely local)
MCP Integration: Fully compatible with Claude Desktop through the Model Context Protocol
No API Keys: No registration or signup required
Privacy-Focused: Your code never leaves your machine if you use local models
Simple & Secure: Straightforward implementation with minimal dependencies
New Additions: See Modular-Empowerment-README.md or just try the prompts!

Potential Use Cases for LocalREPL

There are several powerful use cases for a local Python REPL integrated with Claude:

1. Interactive Learning Environment

Perfect for teaching programming concepts with immediate feedback
Step through algorithms with Claude explaining each part
Build understanding iteratively without switching between tools

2. Data Analysis Workflow

Process and analyze data with state persistence
Incrementally build analysis pipelines with guidance from Claude
Visualize results and refine approach without context switching

3. Secure Code Experimentation

Experiment with sensitive code or data that shouldn't leave your machine
Test financial algorithms, personal automation, or proprietary code
Avoid exposing intellectual property to third-party services

4. Incremental Development

Build solutions step-by-step with Claude's guidance
Maintain context and state throughout development sessions
Refine code based on immediate feedback and results

5. Local AI Integration Testing

Test integrations with local AI models
Process inputs and outputs for AI systems
Build preprocessing and postprocessing pipelines

6. Automated Documentation Generation

Generate documentation from code inspection
Test and refine documentation examples
Create interactive tutorials with working code examples

7. Private API Testing

Explore internal or sensitive APIs without exposing credentials
Build up complex API requests incrementally
Test authentication flows and data handling

8. Local System Automation

Control and interact with local services securely
Build automation scripts that don't require internet access
Test system modifications in a controlled environment

9. Continuous Computational Context

Maintain a persistent computational environment between conversations
Build on previous calculations without starting over
Create complex multi-step analyses with Claude's guidance

10. Educational Demonstrations

Create interactive coding tutorials
Demonstrate concepts with working code examples
Allow students to experiment safely within Claude

alt text

Installation

Prerequisites

Python 3.10 or higher
Claude Desktop

Setup

Clone this repository

git clone https://github.com/angrysky56/local-repl-mcp.git

Quickstart:

You can just copy this into your mcp config json edit the path to your own, and should be good to go:

{
  "mcpServers": {
    "LocalREPL": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/local-repl-mcp",
        "run",
        "-m",
        "local_repl"
      ]
    }
  }
}

alt text

Usage

Some of these packages will take some time to install, I suggest you do this if they take too long to install:

Optional: Install additional packages you want to use in your REPL:

cd local-repl-mcp

# Using uv (recommended)
# uv .venv/bin/activate && uv pip install <required-packages>
# If you don't have uv installed, you can install it with:
# pip install uv
# Then if not made by the server activating via Claude you can create then activate the virtual environment with:
# uv venv --python 3.12 --seed
# Then you can activate the virtual environment with:
uv .venv/bin/activate
# And install the packages with:
uv add numpy pandas matplotlib scipy scikit-learn tensorflow torch torchvision torchtext torchaudio seaborn sympy requests networkx beautifulsoup4 jupyter fastapi

Once the server is installed in Claude Desktop, you can use the following tools,

This info and much more is also available to Claude via the prompts folder and attachable by the + in the Desktop UI or /LocalREPL in others:

create_python_repl() - Creates a new Python REPL and returns its ID
run_python_in_repl(code, repl_id) - Runs Python code in the specified REPL
list_active_repls() - Lists all active REPL instances
get_repl_info(repl_id) - Shows information about a specific REPL
delete_repl(repl_id) - Deletes a REPL instance

Shell, Streaming, and Operational Memory (v0.2)

As of v0.2 the REPL is no longer Python-only. Three modules expand it into a full CLI orchestration layer:

Shell bridge (`shell_bridge.py`)

Run one-shot commands with structured output. Every call auto-logs to evolution.db so past executions become queryable memory.

run_shell(command, repl_id, timeout_seconds=30, cwd=None, use_shell=False, env_extra=None) Returns {command, cwd, stdout, stderr, exit_code, duration_ms, timed_out, truncated_stdout, truncated_stderr}. use_shell=True enables pipes/redirects via /bin/sh. Blocklist refuses sudo, rm -rf /, dd of=/dev/…, shutdown/reboot, fork bombs, and chained variants like echo x && sudo poweroff.
set_repl_cwd(repl_id, path) / get_repl_cwd(repl_id) - track a working directory per REPL so subsequent run_shell calls start there.

Streaming (`streaming.py`)

Long-running processes with non-blocking output drain.

spawn_shell(command, repl_id, cwd=None, use_shell=False) → returns proc_id (separate from OS PID to avoid reuse issues).
tail_shell_output(proc_id, n_lines=50, stream='both', drain=False) - read recent lines without blocking. Use drain=True in polling loops so the next call sees only NEW output.
send_to_shell(proc_id, input_text) - write to stdin for interactive REPLs/servers.
kill_shell(proc_id, signal_name='SIGTERM') - supports SIGTERM/SIGKILL/ SIGINT/SIGHUP.
wait_shell(proc_id, timeout_seconds=30) - block until exit.
list_shells() / reap_exited() - inventory and cleanup.

Operational memory (`evolution_memory.py`)

SQLite-backed log of every shell command. Like Atuin, but queryable by the agent directly.

query_command_history(pattern=None, repl_id=None, only_failures=False, only_timeouts=False, since=None, limit=20) - pattern uses SQL LIKE (%ripgrep%), since accepts '1h', '30m', '2d', or ISO timestamps.
command_stats(since=None, top_n=5) - total/pass/fail, success rate, top commands, top failures, slowest runs.
tag_command(command_id, tags) - attach ['flaky', 'solved'] etc.
forget_command(command_id) - delete rows that captured secrets.
vacuum_memory(keep_last_n=5000) - cap db size.

Virtual Environment Execution (`venv_exec.py`)

Run Python code inside isolated virtual environments with their own packages and interpreters.

run_python_in_venv(code, venv_path, repl_id=None) - Run Python code inside a specified virtual environment path.
find_venv(path=None) - Discover python virtual environments automatically.

Verify the install

After pulling these changes:

uv run python -m local_repl.doctor

Expects all 9 checks green before you restart Claude Desktop.

Note on unified server: The entry point modules server.py and __main__.py have been fully unified. The pyproject script command local-repl-mcp is now 100% feature-complete, containing all REPL, shell, streaming, memory, and virtual environment execution tools!

Recommended CLI Toolchain

The shell bridge shines when paired with modern CLI utilities that produce structured, predictable output (exit codes, JSON flags, counts-first patterns). The recipes below assume Pop!_OS 24.04 / Ubuntu 24.04; other distros use the same package names with their own package manager.

Tier A — apt (one sudo command)

sudo apt update
sudo apt install -y bat git-delta hyperfine

fd / bat naming fix (no sudo). Debian/Ubuntu ship fd-find / bat as fdfind / batcat to avoid name collisions. Symlink the usual names so scripts work unchanged:

mkdir -p ~/.local/bin
ln -sf "$(which fdfind)" ~/.local/bin/fd
ln -sf "$(which batcat)" ~/.local/bin/bat
echo "$PATH" | tr ':' '\n' | grep -q '\.local/bin' && echo OK

ast-grep and nvm-installed npm binaries. If you use nvm, npm installs global binaries under ~/.nvm/versions/node/<ver>/bin/. That path is added to $PATH by shell init files, which don't fire when an MCP server launches via launchd/systemd. Symlink into ~/.local/bin so it's visible to any subprocess regardless of how the parent was started:

ln -sf "$(npm root -g)/../bin/ast-grep" ~/.local/bin/ast-grep
ast-grep --version

Tier B — user-space (no sudo)

# ast-grep: structural code search/rewrite.
npm install -g @ast-grep/cli

# tokei: per-language code statistics.
cargo install tokei

# just: self-documenting command runner via uv (no sudo, no cargo compile).
uv tool install rust-just

watchexec — prebuilt `.deb` (skip cargo)

Don't cargo install watchexec-cli. As of watchexec 2.5.1 the crate uses fmt::from_fn, still nightly-only on Rust 1.95 (debug_closure_helpers tracking issue #117729; stabilization PR #146099 pending). Compilation fails with error[E0658]. Use the upstream .deb instead:

WATCHEXEC_VER=2.5.1
cd /tmp
curl -fsSLO "https://github.com/watchexec/watchexec/releases/download/v${WATCHEXEC_VER}/watchexec-${WATCHEXEC_VER}-x86_64-unknown-linux-gnu.deb"
echo "9bf40f223b3651e59c99ed463c44635fa71ab3f81b69927b5343b3935a4fdb14  watchexec-${WATCHEXEC_VER}-x86_64-unknown-linux-gnu.deb" | sha256sum -c -
sudo dpkg -i "watchexec-${WATCHEXEC_VER}-x86_64-unknown-linux-gnu.deb"

For future versions, grab the matching checksum from https://github.com/watchexec/watchexec/releases/download/v<VER>/watchexec-<VER>-x86_64-unknown-linux-gnu.deb.sha256.

Verify the toolchain

for cmd in rg jq fd bat delta tokei hyperfine watchexec ast-grep just; do
  printf "%-12s " "$cmd"
  command -v "$cmd" >/dev/null && echo "✓ $($cmd --version 2>/dev/null | head -1)" || echo "✗ MISSING"
done

Ten green checkmarks = ai-cli skill has its full toolkit.

Why these specific tools

ToolReplacesAI-relevant winrggrepRespects .gitignore; --json output; blazing fastfdfindSimpler syntax, parallel walks, respects .gitignoreast-grepregex for codeMatches code by AST pattern, not text — kills "old_string not unique" edit failuresjqsed/awk on JSONSafe, predictable JSON parsingtokeiwc -l + findPer-language code stats in one call — great first-touch overviewbatcatLine numbers + git change markers give the agent immediate contextdeltadiff viewerSide-by-side, syntax-aware diffshyperfinetime ...Statistical benchmarking with JSON exportwatchexecpolling loopsReactive file-change triggers instead of pollingjustbash scriptsSelf-documenting recipes; just --list shows every task

Known gotchas

sg is not ast-grep. On Debian/Ubuntu sg is the setsid/script-grep binary from util-linux. Use the full name ast-grep — the ast-grep team dropped the sg shortname in 2024 for this exact reason.
ast-grep pattern syntax is specific. $$$ binds to argument lists, not arbitrary bodies. To match "any function by name" use def $NAME, not def $NAME($$$): $$$ — the latter silently returns zero matches.
use_shell=True runs under /bin/sh, not bash. No brace expansion {a,b}, no [[ ]], no process substitution. Use POSIX sh syntax or invoke bash -c '...' explicitly.
rg and stdin. Ripgrep's is_readable_stdin heuristic hangs waiting on stdin if the parent's stdin is a pipe. The shell bridge handles this by passing stdin=DEVNULL by default.
stdin_input parameter with JSON payloads. The MCP tool-call serializer auto-parses JSON-looking strings into dicts, failing Pydantic's str check. Workaround: pipe via use_shell=True with echo '{...}' | jq ....

Example Workflow

# First create a new REPL
repl_id = create_python_repl()

# Run some code
result = run_python_in_repl(
  code="x = 42\nprint(f'The answer is {x}')",
  repl_id=repl_id
)

# Run more code in the same REPL (with state preserved)
more_results = run_python_in_repl(
  code="import math\nprint(f'The square root of {x} is {math.sqrt(x)}')",
  repl_id=repl_id
)

# Check what variables are available in the environment
environment_info = get_repl_info(repl_id)

# When done, you can delete the REPL
delete_repl(repl_id)

Development

To run the server during development:

mcp dev server.py

Try this stuff if you need to, untested:

Create a virtual environment:

# Using uv (recommended)
uv venv --python 3.12 --seed

# Or using standard venv
python -m venv .venv

Activate the virtual environment:

# On Linux/macOS
. .venv/bin/activate

# On Windows
.venv\Scripts\activate

cd local-repl-mcp Install the package:

# Using uv
uv pip install -e .

# Using pip
pip install -e .

No idea if this works:

Run the following command to generate a configuration file for Claude Desktop:

mcp install server.py

Troubleshooting

EPIPE errors: If you see EPIPE errors, restart the Claude Desktop application
Missing packages: If your code requires specific packages, install them in the same virtual environment
Connection issues: Ensure the server path in your configuration is correct
MCP tools not appearing: Check your Claude Desktop configuration and restart the application

License

MIT

Available Tools

23 tools

command_statsA

Aggregate metrics across the command log.

    Args:
        since: Window to analyze (ISO or '1h'/'1d' etc). None = all time.
        top_n: How many entries to return in each top-list.

ParametersJSON Schema

Name	Required	Description	Default
`since`	No
`top_n`	No

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It indicates aggregation and top-lists but omits behavioral traits like read-only status, side effects, or rate limits. The term 'aggregate' is vague regarding safety or mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a single-purpose sentence and a clear parameter list. It avoids fluff, though structure could be slightly improved (e.g., separating description from parameter details). Still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only 2 parameters with good semantic explanations, no output schema, and no annotations, the description is fairly complete for an aggregation tool. It lacks output details but is sufficient for selecting the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds significant meaning: 'since' is explained (ISO or shorthand, default all time) and 'top_n' (number of entries per top-list). This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Aggregate metrics across the command log', specifying both the verb (aggregate) and resource (command log metrics). It distinguishes well from sibling tools like query_command_history (raw history) and tag_command (tagging), making purpose unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. It only implies use for aggregated stats, but no when-to-use, prerequisites, or exclusions are given, leaving usage ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_python_replC

Create a new Python REPL environment.

Returns:
    str: ID of the new REPL

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior but only states it returns an ID. It omits side effects (e.g., process lifecycle), permissions, limits, or whether the REPL is persistent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded, but it sacrifices completeness. It's not verbose, but missing critical information reduces its efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no params and no output schema, the description should explain what a REPL environment is, how to use it after creation, and any implicit behaviors. It only provides the return type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the schema is complete. The description adds no parameter details, but none are needed. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a Python REPL environment, using a specific verb and resource. It distinguishes from siblings like run_python_in_repl and delete_repl, though more detail could further clarify scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like spawn_shell or run_python_in_venv. There are no usage restrictions or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_replA

Delete a REPL instance.

Args:
    repl_id: ID of the REPL to delete

Returns:
    str: Confirmation message

ParametersJSON Schema

Name	Required	Description	Default
`repl_id`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states the action without disclosing behavioral traits such as irreversibility, permissions required, or impact on associated processes. This is insufficient for a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with three lines for the main purpose, followed by Args and Returns. Every sentence is necessary and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considering the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but lacks details on return value format or error handling. Could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the schema by stating 'ID of the REPL to delete' for the repl_id parameter. Given 0% schema description coverage, this compensation is adequate but minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a REPL instance,' providing a specific verb and resource. It distinguishes from sibling tools like 'kill_shell' or 'spawn_shell' by focusing on REPL deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a REPL needs to be removed, but it offers no explicit guidance on when to use this tool over alternatives like 'kill_shell' or prerequisites. No exclusions or alternative tool mentions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_venvA

Locate a virtual environment in the REPL's current directory.

    Checks, in order: .venv/, venv/, env/. Returns the path to the
    python binary if found, so it can be fed directly to
    run_python_in_venv.

    Args:
        repl_id: REPL whose cwd to search under.

ParametersJSON Schema

Name	Required	Description	Default
`repl_id`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description clearly discloses the search order and return value. It does not mention side effects, but since the tool is read-only and non-destructive, the description is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with no wasted words. It uses three sentences to convey purpose, behavior, and parameter semantics efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and no nested objects. The description covers the return value and how it relates to run_python_in_venv, making it sufficiently complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that repl_id is the REPL whose cwd to search under, adding meaning beyond the schema's 'Repl Id' label. However, it does not provide additional details like expected format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool locates a virtual environment, specifies the search order (.venv/, venv/, env/), and explains it returns the python binary path. It also mentions the output can be fed to run_python_in_venv, distinguishing it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating the search order and linking to run_python_in_venv, providing clear context for when to use it. However, it does not explicitly exclude alternative tools like run_python_in_repl or mention when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

forget_commandB

Delete a command log row. Use when a logged command captured a secret (token in argv, etc.) that shouldn't persist on disk.

ParametersJSON Schema

Name	Required	Description	Default
`command_id`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It only states it deletes, but lacks details on side effects, permissions, or reversibility. Minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose. Every word earns its place, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete tool with one parameter and no output schema, the description covers the essential. But lacks completeness on irreversible actions or permission requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and description does not elaborate on the 'command_id' parameter. No added meaning beyond the schema's type information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deletes a command log row, using the verb 'Delete' and specifying the resource. It also provides a specific use case (secrets), making it distinct from siblings like query_command_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (captured secret), but does not discuss when not to use or alternatives. For a security-focused tool, the guidance is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_repl_cwdB

Return the REPL's current working directory.

ParametersJSON Schema

Name	Required	Description	Default
`repl_id`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description is minimal and does not disclose behavioral traits like side effects, permissions, or return format. The tool is likely read-only, but this is not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy, efficiently conveys the core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks details on what the return value contains, error conditions, prerequisites (e.g., that the REPL must exist and be running). Incomplete for a tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%; the description does not explain the 'repl_id' parameter beyond its title in the schema. The parameter's purpose is somewhat obvious but not explicitly clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Describes a specific action: returning the REPL's current working directory. Clearly distinguishes from sibling 'set_repl_cwd'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No description of when to use this tool versus alternatives or when not to use it. The context is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_repl_infoC

Get information about a specific REPL instance.

Args:
    repl_id: ID of the REPL to get info for

Returns:
    str: Information about the REPL

ParametersJSON Schema

Name	Required	Description	Default
`repl_id`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states 'get information' without describing side effects, authentication needs, or what the returned string contains. The return type 'str' is minimally informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is short and uses a clear Args/Returns structure, making it easy to parse. It is efficient but could be slightly more concise by removing the docstring format if not needed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and many sibling tools, the description is too vague. It does not explain what 'information' entails (e.g., status, metadata, configuration), leaving the agent guessing about the tool's output and suitability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It only restates the parameter name ('ID of the REPL to get info for') without adding format, constraints, or examples. This adds little value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets information about a specific REPL instance, using a specific verb and resource. It distinguishes from siblings like list_active_repls or get_repl_cwd by targeting a single repl_id, but does not specify what 'information' includes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. Siblings include get_repl_cwd and list_active_repls, but the description does not clarify when get_repl_info is appropriate or what tradeoffs exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

initialize_modular_empowermentC

Initialize the Modular Empowerment Framework in a specific REPL.

Args:
    repl_id: ID of the REPL to initialize in

Returns:
    str: Result of the initialization

ParametersJSON Schema

Name	Required	Description	Default
`repl_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavior. It mentions 'Initialize' but does not disclose potential side effects (e.g., whether it modifies existing state or is safe to call multiple times), auth requirements, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded with the main purpose. However, the Args/Returns struct is unnecessary for a single-parameter tool and adds marginal value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic functionality but lacks details on the return value (only says 'Result of the initialization') and does not explain what initialization entails. With no output schema, more context would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds meaning for the lone parameter 'repl_id' by stating it is the 'ID of the REPL to initialize in'. This clarifies the parameter's purpose but does not provide format or validation details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Initialize' and the resource 'Modular Empowerment Framework in a specific REPL'. It distinguishes from sibling tools which are mostly REPL management and shell operations, though 'Modular Empowerment Framework' is somewhat vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., other initialization or setup tools). No when-not or prerequisite conditions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kill_shellB

Send a signal to a spawned process.

    Args:
        signal_name: 'SIGTERM' (graceful, default), 'SIGKILL' (force),
            or 'SIGINT' (Ctrl-C equivalent).
        remove_from_registry: Drop from _PROCESSES after signalling.

ParametersJSON Schema

Name	Required	Default
`proc_id`	Yes
`signal_name`	No	SIGTERM
`remove_from_registry`	No

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only mentions args but does not disclose side effects (e.g., process termination implications, safety). Missing behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, no redundant sentences. Purpose is front-loaded. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description fails to mention return values, async behavior, or process post-state. Incomplete for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. Description explains signal_name and remove_from_registry but omits required proc_id, only partially compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Send a signal to a spawned process', which is a specific verb+resource. Distinguishes from sibling tools like spawn_shell, run_shell, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not explain signal selection context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_active_replsA

List all active REPL instances and their IDs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It states the tool lists active repls and IDs, but does not disclose any behavioral traits like whether it requires authentication or what 'active' means. Adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single well-structured sentence that is front-loaded with the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description provides the essential information (listing active repls and IDs). However, it could clarify the meaning of 'active' or the output format. Still, it is mostly complete for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the input schema is empty. The description does not need to add parameter info beyond the schema, so baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' and identifies the resource as 'active REPL instances and their IDs', which is clear and distinguishes from sibling tools like create or delete repls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as get_repl_info or list_shells. The description does not mention any context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_shellsA

Return info on all spawned processes (live and recently-exited).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description discloses the scope (all spawned processes, live and recently-exited) but lacks details on permissions, side effects, or response format. No annotations provided; description carries full burden and is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no unnecessary words. Front-loaded with the core function. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description is adequate but could specify the type of info returned (e.g., PIDs, command names). Missing details about output structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; schema coverage is 100%. With zero parameters, the baseline is 4. Description adds no param info because none needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it returns info on all spawned processes, including live and recently-exited. This distinguishes it from sibling list_active_repls which likely shows only active ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_active_repls or get_repl_info. The description does not help an agent choose correctly among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_command_historyA

Search the command execution log.

    Args:
        pattern: SQL LIKE pattern against the command text (case-insensitive).
            Use % as wildcard, e.g. '%ripgrep%' or 'git commit%'.
        repl_id: Filter to commands run in a specific REPL.
        only_failures: Return only non-zero exit codes.
        only_timeouts: Return only commands that hit the timeout.
        since: ISO timestamp, or relative like '1h', '30m', '2d'.
        limit: Max rows to return (capped at 200).

    Returns:
        List of CommandLogEntry dicts, newest first.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`since`	No
`pattern`	No
`repl_id`	No
`only_failures`	No
`only_timeouts`	No

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description covers key behaviors: returns newest first, limit capped at 200, SQL LIKE pattern case-insensitive. It does not disclose side effects or authorization needs, but for a read query this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet-point parameter descriptions and a return section. Every sentence is informative, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters, explains return type (list of CommandLogEntry, newest first), and mentions the limit cap. It does not detail the CommandLogEntry fields, but this is likely documented elsewhere. Adequate for tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides detailed explanations for all 6 parameters, including pattern syntax, default values, and the limit cap, adding significant value beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches the command execution log, with specific parameters listed. It is distinct from siblings like command_stats and forget_command.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description does not mention any context for choosing it over other sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reap_exitedA

Remove exited processes from the registry. Call occasionally to keep list_shells tidy, especially after running many short spawns.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility. It indicates a destructive mutation but does not detail side effects, reversibility, or safety. Adequate for a simple cleanup tool but lacks behavioral depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences front-load the purpose and usage guidelines without extraneous words. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core purpose and usage context. Lacks explanation of 'registry' or potential side effects, but sufficient for a zero-parameter cleanup tool in a familiar domain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (empty schema), so baseline 4 applies. Description correctly omits parameter details as none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Remove exited processes from the registry') and the resource, distinguishing it from sibling tools like list_shells (listing) and spawn_shell (creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to call ('occasionally', 'after running many short spawns') and why ('keep list_shells tidy'). Does not specify when not to use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_python_in_replB

Execute Python code in a REPL. (Create new or use an existing REPL)

Args:
    code: Python code to execute
    repl_id: ID of the REPL to use

Returns:
    str: Result of the execution including stdout, stderr, and the return value

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes
`repl_id`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes execution and return format (stdout, stderr, return value) but no annotations to lean on. Missing side effects, state changes, error handling, or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise docstring format with purpose front-loaded. No filler, but additional parameter details could be added without verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers execution and result structure, but without output schema or annotations, it omits error scenarios, REPL lifecycle, and state implications. Adequate for a simple tool but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; description adds one-line explanations for code and repl_id. Adds basic meaning but lacks examples, constraints, or details on where to obtain repl_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb ('Execute') and resource ('Python code in a REPL'). Distinguishes from siblings like run_python_in_venv and run_shell by specifying REPL context and ability to create new or reuse existing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to create new REPL vs use existing, or when to prefer this over run_python_in_venv or send_to_shell. Lacks explicit use cases or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_python_in_venvA

Run Python code inside a project's virtual environment.

    Spawns a fresh subprocess running `<venv>/bin/python -c CODE`.
    No namespace carries over between calls — each invocation is a
    new interpreter. Use this when the project has dependencies that
    aren't installed in the MCP server's Python environment.

    Args:
        code: Python source to execute.
        venv_path: Path to the venv directory (e.g., "/proj/.venv")
            OR direct path to the python binary. `~` is expanded.
        repl_id: Optional REPL to inherit cwd from. Falls back to
            cwd argument, then to server's cwd.
        cwd: Explicit working directory override.
        timeout_seconds: Kill after N seconds (capped at 600).
        env_extra: Additional env vars merged onto os.environ.
            PYTHONPATH is NOT auto-set — pass it via env_extra if
            the project uses src-layout and needs it.

    Returns:
        VenvResult dict with ok/python_path/cwd/stdout/stderr/
        exit_code/duration_ms/timed_out/truncation flags/error.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`code`	Yes
`repl_id`	No
`env_extra`	No
`venv_path`	Yes
`timeout_seconds`	No

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that each call spawns a new subprocess with no namespace carryover. Mentions timeout cap (600s) and that PYTHONPATH must be manually passed. Without annotations, this is strong, though it could note whether stderr is silently captured.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a one-line summary, followed by organized blocks for behavioral notes, parameter docs, and return type. Every sentence adds value; no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all 6 parameters, explicates the return structure (VenvResult), and includes edge cases like timeout truncation and env_extra PYTHONPATH guidance. Fully compensates for missing annotations and output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description explains every parameter in detail. It clarifies venv_path can be a directory or binary path, repl_id inherits cwd, and env_extra merges onto os.environ. Adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Run Python code inside a project's virtual environment' using a specific verb and resource. Distinguishes from sibling tools like run_python_in_repl by emphasizing isolation and dependency separation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises use when project dependencies are missing from the MCP server's environment. Gives important caveats like PYTHONPATH not being auto-set, but could be improved by naming an alternative sibling (e.g., run_python_in_repl) for contrast.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_shellA

Run a shell command inside a REPL context with structured output.

    Returns a dict so the caller can branch on exit_code and parse
    stdout without string-scraping. Every call is logged to evolution.db
    for later recall via `query_command_history`.

    Args:
        command: The shell command to execute.
        repl_id: REPL whose cwd the command runs in.
        timeout_seconds: Kill the process if it exceeds this (capped at 600).
        cwd: Override the REPL's cwd for this one call.
        use_shell: If True, pass to /bin/sh (enables pipes, redirects,
            glob expansion). Default False = tokenized exec, safer.
        env_extra: Additional env vars merged onto os.environ.
        stdin_input: Optional string piped to the command's stdin.
            Enables first-class stdin piping so CLI tools that read
            from stdin (jq, wc, grep, etc.) work without shell pipe
            syntax.  When None the child's stdin is /dev/null.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`command`	Yes
`repl_id`	Yes
`env_extra`	No
`use_shell`	No
`stdin_input`	No
`timeout_seconds`	No

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers key behaviors: structured dict return, logging to evolution.db, timeout cap (600), use_shell tokenization vs. /bin/sh, env_extra merging, stdin piping. However, no mention of error handling or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear docstring format and front-loaded purpose. Slightly verbose but each sentence adds value; could tighten the parameter descriptions minimally.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and no annotations, the description is remarkably thorough: covers return format, logging, parameter behavior, and shell vs. execve trade-offs. Leaves no major gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 7 parameters are individually explained with context (e.g., stdin_input enables first-class piping). Schema coverage is 0%, so the description fully compensates by adding meaning beyond property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Run a shell command inside a REPL context with structured output,' specifying verb and resource. It distinguishes from siblings like run_python_in_repl by focusing on shell commands in a REPL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for executing shell commands with structured output and logging, but lacks explicit when-to-use vs. siblings (e.g., send_to_shell). No exclusions or alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_to_shellB

Write to a spawned process's stdin. Useful for interactive REPLs.

ParametersJSON Schema

Name	Required	Description	Default
`proc_id`	Yes
`input_text`	Yes
`append_newline`	No

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavior. It states the action but omits details like whether it blocks, what happens if the process is dead, or the effect of the `append_newline` parameter. This is insufficient for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no filler. Front-loaded with the essential action, then a use case. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no annotations, and no output schema, the description should provide more context about prerequisites (e.g., process must be spawned), return value, or data format. It only covers the basic action and a minimal use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, meaning no parameter descriptions. The description does not explain what `proc_id`, `input_text`, or `append_newline` mean. The agent must infer from names, which is risky.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Write' and resource 'stdin of a spawned process', distinguishing it from siblings like 'run_shell' or 'spawn_shell'. Mention of 'interactive REPLs' adds specific context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Useful for interactive REPLs' provides clear context for when to use the tool. It does not explicitly state when not to use or mention alternatives, but the sibling list makes differentiation plausible.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_repl_cwdC

Change a REPL's tracked working directory for future shell calls.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`repl_id`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects (e.g., effect on existing shells, persistence, error handling, or authorization requirements). This is minimal transparency for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the purpose, but it is too terse given the missing parameter and behavioral details. Every sentence should earn its place; here it omits essential context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0% schema coverage, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, error conditions, or parameter constraints, leaving the agent without critical information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must add parameter meaning but does not. It fails to explain what 'path' should be (absolute/relative) or 'repl_id' format. The schema titles alone are insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool changes a REPL's tracked working directory, specifying the verb 'Change' and the resource 'REPL's tracked working directory'. It distinguishes from sibling get_repl_cwd, which likely retrieves the current directory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when the agent needs to update the working directory for future shell calls, but lacks explicit guidance on when not to use it or alternatives. No exclusions or context relative to siblings are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

spawn_shellA

Spawn a long-running process. Returns a proc_id for follow-up calls.

    Use this for watchers (watchexec, tail -f), servers, REPLs, or any
    command you want to poll output from over time. For one-shot
    commands use run_shell instead — it's simpler and auto-logs.

    Returns proc_id which is passed to tail_shell_output, send_to_shell,
    kill_shell, and wait_shell.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`command`	Yes
`repl_id`	Yes
`env_extra`	No
`use_shell`	No

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes the tool as spawning a long-running process, returning a proc_id for polling, and lists related tools. Implies non-blocking behavior but could explicitly state that it does not wait for completion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 sentences), front-loaded with the core purpose, and uses clear bullet-like formatting for examples. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description covers return value and lifecycle with other tools. Missing details on failure modes or resource usage, but adequate for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description provides no explanation of any parameters (command, cwd, repl_id, env_extra, use_shell). Without parameter semantics, agents cannot determine correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it spawns a long-running process and returns a proc_id. It distinguishes from run_shell by specifying it's for watchers, servers, REPLs, and commands to poll over time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (watchers, servers, REPLs) and when not to (one-shot commands, use run_shell instead). Also mentions that proc_id is used by other tools, providing clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tag_commandC

Attach tags to a logged command for later recall.

Useful for marking commands as e.g. 'flaky', 'slow', 'solved', 'security-review'. Replaces any existing tags on that row.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	Yes
`command_id`	Yes

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool replaces any existing tags on the row, which is a key behavioral trait. However, it does not mention error handling, authorization requirements, or what happens if the command_id does not exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The first sentence states the purpose, and the second adds examples and behavior. It is front-loaded and efficient, though it could be slightly more structured with bullet points.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 required parameters, no output schema, no annotations), the description covers the basic purpose and the overwriting behavior. However, it lacks details on error conditions or prerequisites, which would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should add meaning to parameters. It does not explain what 'command_id' or 'tags' represent beyond their names, nor does it provide constraints, format, or examples. The schema already shows required fields, but the description adds no value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool attaches tags to a logged command for later recall, with specific examples like 'flaky', 'slow', etc. It uses a specific verb and resource, but it does not explicitly distinguish itself from sibling tools like 'forget_command' or 'query_command_history', which would merit a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides examples of when to use the tool (marking commands as flaky, slow, etc.) but offers no guidance on when not to use it or what alternatives exist among sibling tools. There is no explicit statement of context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tail_shell_outputA

Return the most recent lines from a spawned process's output.

    Args:
        proc_id: From spawn_shell.
        n_lines: How many recent lines to return (capped at 500).
        stream: 'stdout', 'stderr', or 'both'.
        drain: If True, remove returned lines from the buffer so the
            next call sees only NEW output. Useful for polling loops.

ParametersJSON Schema

Name	Required	Default
`drain`	No
`stream`	No	both
`n_lines`	No
`proc_id`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without any annotations, the description carries full burden. It explains critical behavioral details: the 'n_lines' cap at 500, and the 'drain' mode that removes returned lines from the buffer so subsequent calls see new output. It does not cover error handling (e.g., invalid proc_id) or detailed return format, but the provided traits are substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a single-line summary followed by bullet-point style parameter documentation. Every sentence adds value, with no redundancy or fluff. The summary is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite good parameter descriptions, the tool lacks output schema and annotations, and the description does not specify the return format (e.g., string, list) or error behavior (e.g., invalid process ID). This leaves gaps for an agent to fully understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the parameter explanations in the description are essential. Each parameter is clearly described: 'proc_id' is from spawn_shell, 'n_lines' is capped at 500 (default 50), 'stream' options are 'stdout', 'stderr', or 'both', and 'drain' behavior removes lines from buffer. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the most recent lines from a spawned process's output. It uses a specific verb ('Return') and resource ('shell output'), and implicitly distinguishes itself from sibling tools like spawn_shell and kill_shell by focusing on reading output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It mentions the 'drain' parameter is 'useful for polling loops', which hints at a use case, but there are no comparisons or exclusions relative to the many sibling shell tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vacuum_memoryA

Keep only the most recent N rows and reclaim disk space. Call occasionally to prevent unbounded growth.

ParametersJSON Schema

Name	Required	Description	Default
`keep_last_n`	No

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Description mentions reclaiming disk space and preventing unbounded growth but omits critical behavioral details such as whether the operation is destructive, reversible, blocking, or requires special permissions. This leaves significant ambiguity for a data-modifying tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the main action ('Keep only the most recent N rows'). Every word serves a purpose; no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple maintenance tool with one parameter and no output schema, the description is minimally adequate. However, it lacks context about side effects, blocking behavior, or what 'rows' refers to. Given the sibling tool complexity, a bit more detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single parameter 'keep_last_n'. The description does not mention the parameter at all. The parameter name is self-explanatory, but the tool description should at least reference it to clarify its role in the operation, especially with no output schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Keep only the most recent N rows' and the resource 'memory', with specific outcome 'reclaim disk space'. It distinguishes from sibling tools which focus on command execution, REPLs, and shells, making this the only memory management tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description includes 'Call occasionally to prevent unbounded growth', providing clear when-to-use guidance. While it does not explicitly list when not to use, the sibling tools offer no memory management alternatives, so the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wait_shellC

Block until a spawned process exits (or timeout). Returns exit info.

ParametersJSON Schema

Name	Required	Description	Default
`proc_id`	Yes
`timeout_seconds`	No

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses blocking behavior and timeout, but does not mention side effects, error handling on timeout, or whether the tool is destructive. Basic transparency but lacks detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no redundancies. Every word is necessary and the sentence is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no parameter descriptions, the description is incomplete. It does not specify what 'exit info' includes, how to obtain 'proc_id', or behavior on timeout. Context from sibling tools is not leveraged.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It does not describe 'proc_id' or 'timeout_seconds', leaving the agent to infer meaning from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it blocks until a spawned process exits or times out, returning exit info. The verb 'block' and resource 'spawned process' are specific, but it does not differentiate from sibling tools like 'reap_exited' that also handle exits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like 'spawn_shell' or 'reap_exited'. Usage is only implied from the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

23 tool updatesv0.1.0Jul 12, 2026
- First observedcommand_stats
- First observedcreate_python_repl
- First observeddelete_repl
- First observedfind_venv
- First observedforget_command
- First observedget_repl_cwd
- First observedget_repl_info
- First observedinitialize_modular_empowerment
- First observedkill_shell
- First observedlist_active_repls
- First observedlist_shells
- First observedquery_command_history
- First observedreap_exited
- First observedrun_python_in_repl
- First observedrun_python_in_venv
- First observedrun_shell
- First observedsend_to_shell
- First observedset_repl_cwd
- First observedspawn_shell
- First observedtag_command
- First observedtail_shell_output
- First observedvacuum_memory
- First observedwait_shell

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-12 07:15 across 23 tools

Disambiguation5/5

Each tool targets a distinct operation: REPL lifecycle, shell process management, command history logging, and virtual environment usage. No two tools have overlapping purposes; descriptions clearly differentiate between one-shot shell commands, long-running processes, and Python execution contexts.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_python_repl, run_shell, query_command_history). The naming is predictable and intuitive, making it easy for an agent to infer functionality.

Tool Count4/5

With 23 tools, the server covers a broad but coherent set of functionalities for local REPL and shell management. While slightly above the typical sweet spot, each tool serves a specific purpose and justifies its presence without feeling redundant.

Completeness5/5

The tool surface comprehensively covers the domain: REPL creation/deletion/inspection, Python execution (both in-REPL and in-venv), shell command execution (one-shot and long-running), process management, command logging, and history queries. No obvious gaps for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
27
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3

Related MCP Servers

Optimized Memory MCP Server V2
Knowledge & Memory Databases Developer Tools
AgentWong
A
license
Not graded
quality
F
maintenance
A Python-based server that implements the Model Context Protocol to interface with Claude Desktop as an MCP client, supporting interaction through efficient memory management.
Updated 2 years ago (2025-01-05 18:38 UTC)
1
MIT
MCP Python Toolbox
Code Execution Developer Tools
gianlucamazza
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that enables AI assistants like Claude to perform Python development tasks through file operations, code analysis, project management, and safe code execution.
Updated 2 months ago (2026-07-14 06:19 UTC)
9
MIT
MCP Tools
Shell Access File Systems
ZbigniewTomanek
A
license
Not graded
quality
D
maintenance
A custom Model Context Protocol server that gives Claude Desktop and other LLMs access to file system operations and command execution capabilities through standardized tool interfaces.
Updated a year ago (2025-04-16 09:10 UTC)
23
Apache 2.0
Desktop Commander MCP
Shell Access File Systems Developer Tools
MrGNSS
A
license
A
quality
D
maintenance
A server that lets Claude desktop app execute terminal commands on your computer and edit files through Model Context Protocol, featuring command execution, process management, and advanced file operations.
Updated a year ago (2025-03-23 20:47 UTC)
19
156,453 npm
6
MIT

LocalREPL MCP Server

local-repl-cli skill

Features

1. System Discovery Workflow

2. Advanced Workflow Orchestration

3. Strategic Capability Enhancement

**4. Agent Communication and Performance Monitoring

5. Other Advantages

Potential Use Cases for LocalREPL

1. Interactive Learning Environment

2. Data Analysis Workflow

3. Secure Code Experimentation

4. Incremental Development

5. Local AI Integration Testing

6. Automated Documentation Generation

7. Private API Testing

8. Local System Automation

9. Continuous Computational Context

10. Educational Demonstrations

Installation

Prerequisites

Setup

Quickstart:

You can just copy this into your mcp config json edit the path to your own, and should be good to go:

Usage

Some of these packages will take some time to install, I suggest you do this if they take too long to install:

Optional: Install additional packages you want to use in your REPL:

Once the server is installed in Claude Desktop, you can use the following tools,

This info and much more is also available to Claude via the prompts folder and attachable by the + in the Desktop UI or /LocalREPL in others:

Shell, Streaming, and Operational Memory (v0.2)

Shell bridge (shell_bridge.py)

Streaming (streaming.py)

Operational memory (evolution_memory.py)

Virtual Environment Execution (venv_exec.py)

Verify the install

Recommended CLI Toolchain

Tier A — apt (one sudo command)

Tier B — user-space (no sudo)

watchexec — prebuilt .deb (skip cargo)

Verify the toolchain

Why these specific tools

Known gotchas

Example Workflow

Development

Try this stuff if you need to, untested:

No idea if this works:

Troubleshooting

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`local-repl-cli` skill

Shell bridge (`shell_bridge.py`)

Streaming (`streaming.py`)

Operational memory (`evolution_memory.py`)

Virtual Environment Execution (`venv_exec.py`)

watchexec — prebuilt `.deb` (skip cargo)