How do I use Dynamic Code Executor MCP Server?

1. Click on "Install 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., "@Dynamic Code Executor MCP Server run this Python code to calculate compound interest" 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.

Dynamic Code Executor MCP Server

by rafalswiderski

Overview Schema Related Servers Score Discussions

TypeScript

Local

🚀 Dynamic Code Executor MCP Server

License: MIT Node.js Version TypeScript MCP

A powerful Model Context Protocol (MCP) server that enables AI assistants to execute code dynamically in isolated sandboxes with intelligent caching and semantic search.

Perfect for GitHub Copilot, Claude Desktop, Cline, and any MCP-compatible AI assistant that needs to run, test, and validate code in real-time.

🎯 Why This Project?

Modern AI assistants can write code, but they can't verify it works. Dynamic Code Executor bridges that gap by providing:

🔬 Real-time Validation - AI can test code immediately and fix errors
🧠 Semantic Cache - Find and reuse similar solutions without rewriting
⚡ Lightning Fast - Cached results return instantly
🔒 Enterprise Security - Sandboxed execution with package whitelisting
📊 35+ Scripts Cached - Proven track record in production use

Related MCP server: Code Executor MCP Server

🎬 How It Works - Visual Guide

📺 See full animated workflow →

Execution Flow

flowchart TD
    A[🤖 AI Assistant sends code] --> B{📦 Check Cache}
    B -->|Cache Hit| C[⚡ Return Cached Result]
    B -->|Cache Miss| D[✅ Validate Packages]
    D --> E[📁 Create Sandbox]
    E --> F[📦 Install Packages]
    F --> G[▶️ Execute Code]
    G --> H{✓ Success?}
    H -->|Yes| I[💾 Save to Cache]
    H -->|No| J[❌ Return Error]
    I --> K[🧹 Cleanup Temp Files]
    J --> K
    K --> L[📊 Return Results]
    C --> L
    
    style C fill:#90EE90
    style I fill:#87CEEB
    style J fill:#FFB6C1
    style L fill:#DDA0DD

Interaction Sequence

sequenceDiagram
    participant AI as 🤖 AI Assistant
    participant MCP as 🔧 MCP Server
    participant Cache as 💾 Cache
    participant Sandbox as 📦 Sandbox
    participant Python as 🐍 Python/JS/TS
    
    AI->>MCP: execute_code(language, code, packages)
    MCP->>Cache: Check if code exists
    
    alt Code in cache
        Cache-->>MCP: Return cached result ⚡
        MCP-->>AI: Instant response (0ms)
    else Code not cached
        MCP->>MCP: Validate packages against whitelist
        MCP->>Sandbox: Create isolated workspace
        MCP->>Sandbox: Install packages (pip/npm)
        MCP->>Python: Execute code with timeout
        Python-->>MCP: Output + Exit Code
        MCP->>Cache: Save successful execution 💾
        MCP->>Sandbox: Cleanup temporary files 🧹
        MCP-->>AI: Return results
    end
    
    Note over AI,Python: Semantic search enables reuse of similar scripts

Caching Strategy Visualization

graph LR
    A[Code Execution] --> B{Exact Match?}
    B -->|Yes| C[⚡ Instant Cache Hit]
    B -->|No| D[Execute & Cache]
    D --> E[💾 Persistent Cache]
    E --> F[🔍 Semantic Search Index]
    F --> G[Find Similar Scripts]
    
    style C fill:#90EE90
    style E fill:#87CEEB
    style F fill:#FFD700
    style G fill:#DDA0DD

✨ Features

🐍 Python support with pip package installation
🟨 JavaScript/Node.js support with npm packages
🔷 TypeScript support with automatic transpilation
🔒 Process isolation for security
⏱️ Timeout protection against infinite loops
📦 Whitelisted package installation - only safe, approved packages
💾 Persistent caching - successful scripts cached and reusable
🔍 Semantic search - find similar scripts by task description
⚡ Session-based caching - fast package installation within session
📁 Full workspace access - scripts can read/write files in their sandbox
🧹 Automatic cleanup after execution
❌ Detailed error reporting with line numbers
🔍 Script repository - browse and reuse previously successful scripts

🔄 How It Works - Step by Step

stateDiagram-v2
    [*] --> ReceiveCode: 🤖 AI sends code
    ReceiveCode --> CheckCache: 📦 Check cache
    CheckCache --> ReturnCached: ⚡ Cache hit!
    CheckCache --> ValidatePackages: Cache miss
    ValidatePackages --> CreateSandbox: ✅ All packages allowed
    CreateSandbox --> InstallPackages: 📁 Isolated workspace
    InstallPackages --> ExecuteCode: 📦 pip/npm install
    ExecuteCode --> Success: ▶️ Run with timeout
    ExecuteCode --> Failed: ❌ Error
    Success --> SaveCache: 💾 Save to persistent cache
    SaveCache --> Cleanup: 🧹 Remove temp files
    Failed --> Cleanup
    Cleanup --> ReturnResults: 📊 Send output
    ReturnCached --> [*]
    ReturnResults --> [*]

Detailed Steps:

🤖 Model sends code via execute_code tool
📦 Cache check - instant return if identical code was run before
✅ Package validation - verify all packages are in whitelist
📁 Sandbox creation - isolated temporary directory with full file access
⚡ Session cache - reuse pip/npm cache within session for speed
📦 Package installation - install whitelisted packages
▶️ Code execution - run with timeout protection (max 5 min)
💾 Result caching - successful executions saved to persistent cache
🧹 Cleanup - remove temporary files, keep persistent cache
🔍 Semantic search - model can browse and reuse cached scripts

🛠️ Available Tools

`execute_code`

Execute code in an isolated sandbox.

Parameters:

language: python, javascript, js, typescript, or ts
code: The code to execute
packages: Optional array of packages to install (e.g., ["requests", "numpy"])
timeout: Execution timeout in ms (default: 30000ms, max: 300000ms)
allowNetworking: Allow network access (default: true)

Returns:

{
  "success": true,
  "output": "execution output",
  "executionTime": 1234,
  "language": "python",
  "cached": false
}

`validate_code`

Validate code syntax without executing.

Parameters:

language: Programming language
code: Code to validate

Returns: Syntax validation result with error details if invalid.

`list_supported_languages`

List all supported programming languages.

Returns: Array of supported languages and their capabilities.

`list_allowed_packages`

List all whitelisted packages that can be installed.

Parameters:

language: Language to list packages for (or "all")

Returns: List of allowed packages for the specified language.

`search_cached_scripts`

Search for similar scripts using semantic matching.

Parameters:

query: Description of what you want to do (e.g., "fetch GitHub API", "parse CSV")
language: Filter by language (optional)
limit: Max results (default: 10)

Returns: Ranked results with similarity scores.

Example:

{
  "query": "fetch data from REST API",
  "results": 2,
  "matches": [
    {
      "hash": "a1b2c3...",
      "score": 0.85,
      "description": "fetch GitHub API data",
      "language": "python"
    }
  ]
}

`list_cached_scripts`

List recently executed successful scripts (chronological).

Parameters:

language: Filter by language (optional)
limit: Maximum number to return (default: 20)

Returns: List of cached scripts with hashes and previews.

`get_cached_script`

Get full details of a cached script by hash.

Parameters:

hash: Cache hash from list_cached_scripts

Returns: Complete script with code, results, and execution stats.

`get_cache_stats`

Get statistics about the persistent cache.

Returns: Total scripts, size, breakdown by language.

`get_execution_limits`

Get information about execution limits and constraints.

Returns: Timeout limits, resource constraints, security settings.

📦 Installation

# Clone the repository
git clone https://github.com/yourusername/dynamic-code-executor-mcp.git
cd dynamic-code-executor-mcp

# Install dependencies
npm install

# Build the project
npm run build

⚙️ Configuration

For Claude Desktop

Add to your config (%APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "code-executor": {
      "command": "node",
      "args": ["C:\\path\\to\\MCPSELFCODE\\dist\\index.js"]
    }
  }
}

For GitHub Copilot (VS Code)

See VS Code Setup Guide for detailed instructions.

For Cline + OLLAMA

See Setup Guide for detailed instructions.

📚 Documentation

Setup Guide - Integrate with Cline + OLLAMA
VS Code Setup - GitHub Copilot integration
LICENSE - MIT License

💡 Usage Examples

Example 1: Python with Packages

import requests
response = requests.get('https://api.github.com')
print(f"Status: {response.status_code}")
print(f"Rate Limit: {response.headers.get('X-RateLimit-Remaining')}")

Example 2: JavaScript with Packages

const axios = require('axios');
const response = await axios.get('https://api.github.com');
console.log(`Status: ${response.status}`);
console.log(`Headers:`, response.headers);

Example 3: TypeScript

interface User {
  name: string;
  age: number;
  email?: string;
}

const users: User[] = [
  { name: "Alice", age: 30, email: "alice@example.com" },
  { name: "Bob", age: 25 }
];

users.forEach(user => {
  console.log(`${user.name} (${user.age}): ${user.email || 'No email'}`);
});

Example 4: Data Processing with NumPy

import numpy as np

# Create array and perform calculations
data = np.array([1, 2, 3, 4, 5])
print(f"Mean: {np.mean(data)}")
print(f"Std Dev: {np.std(data)}")
print(f"Sum: {np.sum(data)}")

Example 5: Web Scraping

from bs4 import BeautifulSoup
import requests

response = requests.get('https://example.com')
soup = BeautifulSoup(response.text, 'html.parser')
title = soup.find('title').text
print(f"Page title: {title}")

Example 6: File Operations in Sandbox

# Write data to file in sandbox
with open('results.txt', 'w') as f:
    f.write('Processing complete!\n')
    f.write('Total: 42\n')

# Read it back
with open('results.txt', 'r') as f:
    print(f.read())

🔒 Security

Process Isolation

Each execution runs in a separate isolated process
Timeout protection prevents infinite loops
Automatic cleanup of all temporary files

Sandboxed Workspaces

Each run gets an isolated temporary directory with full access
Package whitelist: Only pre-approved safe packages can be installed
Package isolation: Python uses venv, Node uses local node_modules
No cross-session contamination: Each execution is independent

💾 Caching Strategy

Session Cache (Temporary)

Created per execution
Speeds up package installation within same session
Automatically cleaned up after execution
Stored in: %TEMP%/mcp-cache-{sessionId}/

Persistent Cache (Permanent)

Stores successful script executions with hash + description
Exact match: Identical code = instant cached result
Semantic match: Similar task description = suggested cached solution
Survives restarts
Model can search and reuse scripts by description
Stored in: %USERPROFILE%/.mcp-code-executor/

How semantic caching works:

Provide description when executing code (e.g., "fetch GitHub API")
Next time you need similar functionality: search_cached_scripts("get data from GitHub")
Get ranked results even if exact code differs
Reuse proven solutions without rewriting

📁 Workspace Access

Code has full read/write access to its sandbox directory:

Python example:

with open('data.txt', 'w') as f:
    f.write('Hello from sandbox!')

with open('data.txt', 'r') as f:
    print(f.read())

JavaScript example:

const fs = require('fs');
fs.writeFileSync('output.json', JSON.stringify({status: 'ok'}));
console.log(fs.readFileSync('output.json', 'utf-8'));

The workspace path is returned in results as workspaceDir (automatically cleaned after execution).

📋 Requirements

Node.js 18+
Python 3.7+ (for Python execution)
npm (for JavaScript/TypeScript execution)

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Built with Model Context Protocol SDK
Inspired by the need for AI assistants to validate their code in real-time
Thanks to all contributors and users!

Made with ❤️ for the AI coding community

Star ⭐ this repo if you find it useful!

Available Tools

9 tools

execute_codeA

Execute code in a secure isolated sandbox. Supports Python, JavaScript, and TypeScript.

The code will be executed in a temporary environment that is cleaned up after execution. You can optionally install packages before execution.

Use this when you need to:

Run code to get results or test functionality
Process data dynamically
Validate code behavior
Install and use external packages

Returns execution results including output, errors, and execution time.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	The code to execute. Code has full read/write access to its workspace directory.
`timeout`	No	Execution timeout in milliseconds (default: 30000ms, max: 300000ms)
`language`	Yes	Programming language to execute
`packages`	No	Optional packages to install before execution (must be whitelisted - use list_allowed_packages)
`useCache`	No	Use persistent cache for identical code (default: true). Cached results are instant.
`description`	No	Brief description of what the code does (e.g., "fetch GitHub API data"). Used for semantic caching - similar tasks may return cached results even if code differs.
`allowNetworking`	No	Allow network access (default: true)

TDQS

A3.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 full behavioral disclosure. It mentions the sandbox, cleanup, and return values, but omits the default caching behavior (useCache=true) and semantic caching, which can significantly affect execution results.

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 well-structured with a clear lead sentence, a details paragraph, and a bulleted list of use cases. It is slightly verbose but each section earns its place.

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 core usage, environment cleanup, and return values, which is adequate for an execution tool. The rich schema compensates for parameter details, but missing caching behavior leaves a minor completeness gap.

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 coverage is 100%, so a baseline score of 3 applies. The description adds little beyond the schema, only mentioning optional package installation, which is already documented in the packages parameter.

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 executes code in a secure isolated sandbox, supports multiple languages, and lists concrete use cases. This distinguishes it from siblings like validate_code or list_supported_languages.

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 explicitly provides 'Use this when you need to' scenarios, giving clear context for when to use the tool. However, it does not mention when not to use it or alternatives for validation-only tasks, so it lacks exclusions.

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

get_cached_scriptA

Get a specific cached script by its hash.

Returns the full script details including code, result, packages used, and execution stats.

ParametersJSON Schema

Name	Required	Description	Default
`hash`	Yes	Cache hash of the script

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description discloses the return payload (code, result, packages, stats), providing transparency about what the caller receives. It doesn't describe side effects, but as a read-only 'Get' operation this is less critical; the return format is clearly 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?

Two sentences, front-loaded with action and resource, and every word contributes value. There is no filler or repetition of schema details.

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?

For a simple single-parameter lookup tool, the description covers purpose, input, and output comprehensively. It doesn't mention error handling or when to use alternatives, but these aren't essential for this simple 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?

The input schema already fully describes the hash parameter with a description. The description adds no new parameter semantics beyond identifying the hash as the lookup key, so it doesn't exceed the schema baseline.

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 a specific verb 'Get' with a targeted resource 'specific cached script by its hash', clearly distinguishing it from listing or searching siblings. It states exactly what the tool does without ambiguity.

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?

While it doesn't explicitly name alternatives, the phrase 'specific cached script by its hash' implies a direct lookup use case, which is distinct from list/search siblings. Clear context but no exclusions or when-not guidance.

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

get_cache_statsA

Get statistics about the persistent script cache

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries all responsibility for behavioral disclosure. 'Get' implies a read-only operation, but there is no explicit statement of safety, side effects, or what the statistics represent. This minimal disclosure is insufficient for full transparency.

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 a single, concise sentence that front-loads the action and resource. Every word is meaningful, with no redundancy.

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 the tool's simplicity (no parameters, no output schema), the description adequately conveys its purpose. However, it does not elaborate on what specific statistics are returned, which could be useful context but is not critical for a tool of this scope.

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 zero parameters, so the schema requires no explanation. The description adds no parameter detail, but none is needed. Baseline 4 is appropriate for a no-parameter tool.

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 (Get) and the resource (statistics about the persistent script cache). It distinguishes itself from siblings like list_cached_scripts and get_cached_script by focusing on aggregate stats rather than individual scripts.

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 about when to use this tool versus alternatives. The description only states what it does without any context or exclusions, leaving the agent to infer usage.

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

get_execution_limitsB

Get information about execution limits and constraints

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

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

There are no annotations, so the description carries the full burden. It implies a read-only operation ('Get information'), but does not disclose what specific data will be returned, whether it requires authentication, or any side effects. The description lacks depth about the tool's behavior.

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 a single sentence with no superfluous words, front-loading the key verb and resource. It is concise, though it is also under-specified, which slightly detracts from its utility. Still, it 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 that there is no output schema and no annotations, the description should provide more context about what 'execution limits and constraints' means. It does not specify whether this returns quotas, timeouts, or memory limits, nor what the response format looks like. This is incomplete for an agent deciding if this tool addresses a query.

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 zero parameters, so the description does not need to explain parameter syntax or semantics. Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description correctly indicates no parameters are needed.

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 uses a clear verb ('Get') and identifies the resource ('execution limits and constraints'). It distinguishes the tool from siblings by its focus on limits rather than code validation, language support, or caching. However, it could be more specific about what types of limits are covered (e.g., time, memory, output size).

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. It does not mention prerequisites, typical use cases, or that it should be consulted before calling execute_code. This leaves the agent to infer its purpose.

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

list_allowed_packagesA

List all packages allowed to be installed for each language.

Only whitelisted packages can be installed for security reasons. Use this tool to check which packages are available before writing code that requires external dependencies.

Returns a list of allowed packages for Python, JavaScript, and TypeScript.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Language to list packages for, or "all" for all languages

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and addresses key behavioral aspects. It discloses that only whitelisted packages are installable for security reasons, implying a read-only, safe operation. It doesn't add details about output formatting, but that's not required for a straightforward listing 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 concise: three sentences that front-load the purpose, then add usage guidance and return information. Every sentence earns its place, with no fluff or repetition.

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?

For a simple tool with one parameter and no output schema, the description fully covers what an agent needs: the action, the security context, when to use it, and the result. It is complete for its complexity level.

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 coverage is 100% with a clear enum and description for the language parameter. The description adds minimal new meaning beyond confirming the languages covered (Python, JavaScript, TypeScript), but doesn't elevate the parameter understanding beyond what the schema already offers. Baseline of 3 is appropriate.

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 states a specific action ('List all packages allowed to be installed') and a clear resource ('for each language'). It distinguishes itself from siblings like list_supported_languages and execute_code by focusing on package availability, making the purpose unmistakable.

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 provides clear context for use: 'Use this tool to check which packages are available before writing code that requires external dependencies.' It doesn't explicitly name alternatives or exclusion cases, but the guidance is sufficient for a simple list tool.

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

list_cached_scriptsA

List recently cached scripts (chronological order).

Shows the most recent successful executions. Use search_cached_scripts for finding scripts by task description.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of scripts to return (default: 20)
`language`	No	Filter by language (optional)

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It discloses that results are in chronological order and based on successful executions, which are useful behavioral traits. It does not explicitly mention that the operation is read-only or describe any side effects, but the verb 'List' implies a non-mutating read. Slightly more detail on return behavior would improve it, but it 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 only two sentences, front-loaded with the core action and a clear alternative. Every sentence earns its place with no fluff.

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?

For a simple list tool with two optional parameters and no output schema, the description covers purpose, ordering, and usage boundaries. It could be more complete by describing the return format or fields, but it is sufficient for the tool's simplicity.

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 100% for both parameters (limit and language), so the schema already explains them. The description adds no additional parameter-specific meaning beyond what the schema provides, meeting the baseline for full coverage.

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 lists recently cached scripts in chronological order, with a specific verb and resource. It also distinguishes itself from the sibling tool search_cached_scripts by noting the difference in use case.

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?

The description explicitly directs the user to search_cached_scripts for finding scripts by task description, thereby setting clear boundaries on when to use this tool vs. an alternative. This provides both positive and negative guidance.

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

list_supported_languagesA

List all supported programming languages with their capabilities and package managers

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description must carry the full behavioral burden. It clearly implies a read-only, side-effect-free operation by saying 'List all', which is sufficient for a simple list tool. It doesn't disclose rate limits or response format, but given the simplicity, 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 a single, concise sentence that immediately states the verb, resource, and scope. Every word earns its place with no filler or redundancy.

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?

For a simple list tool with no parameters and no output schema, the description sufficiently covers what the agent needs to know. It could potentially mention the output format, but that's not critical for such a straightforward operation.

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 zero parameters, and the schema coverage is 100%. The description adds no parameter-specific information, but none is needed. Baseline for zero params is 4, which is appropriate here.

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 a specific verb 'List' with a clear resource ('supported programming languages') and adds 'with their capabilities and package managers' to specify scope. This clearly distinguishes it from sibling tools like list_allowed_packages, which focus on packages rather than languages.

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 makes the tool's purpose clear enough that an agent would know when to use it—when needing the list of supported programming languages. It doesn't explicitly state alternatives or exclusions, but the context of sibling tools suggests it complements list_allowed_packages rather than overlapping.

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

search_cached_scriptsA

Search for similar cached scripts using semantic search.

Finds previously executed scripts that solve similar problems, even if the exact code differs. Use this when you need to solve a task - there might already be a working solution cached.

Example queries:

"fetch data from REST API"
"parse JSON and extract fields"
"read CSV file and calculate sum"
"scrape webpage content"

Returns ranked results by similarity with scores.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results (default: 10)
`query`	Yes	Description of what you want to do
`language`	No	Filter by language (optional)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that results are ranked by similarity with scores, and that it performs semantic search over cached scripts. This goes beyond the schema and provides meaningful behavioral context, though it does not mention potential limitations like scope of the cache.

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 well-structured with a concise opening, a usage note, and relevant example queries. Every sentence contributes value, and the bulleted examples improve clarity without bloating the text.

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 there is no output schema, the description adequately covers the return format ('ranked results by similarity with scores') and the tool's purpose. It is complete enough for a search tool, though it could mention how limit and language affect behavior, but the schema already covers those.

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 100%, so the baseline is 3. The description adds example queries to illustrate the 'query' parameter but does not enrich the meaning of 'limit' or 'language' beyond their schema definitions.

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 'search' and clearly identifies the resource ('cached scripts') and method ('semantic search'). It states it finds previously executed scripts solving similar problems, distinguishing it from siblings like list_cached_scripts (which likely lists all) and get_cached_script (which retrieves a specific one).

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?

It gives explicit usage context: 'Use this when you need to solve a task - there might already be a working solution cached.' This tells the agent when to invoke the tool, though it doesn't provide when-not conditions or explicitly name alternative tools.

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

validate_codeA

Validate code syntax without executing it. Performs static analysis to check for syntax errors.

Use this to check code validity before execution or to help debug syntax issues.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	The code to validate
`language`	Yes	Programming language to validate

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it performs static analysis and does not execute code. This goes beyond a simple 'validates code' by clarifying the non-execution aspect, which is important for safety. However, it does not specify what happens on failure (e.g., return format or error details), leaving some room for improvement.

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, with two short sentences. The first sentence states the core purpose and behavior, and the second provides usage guidance. There is no redundant or filler content.

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?

For a simple tool with two parameters and no output schema, the description covers the essential purpose and usage context. It distinctly separates itself from execute_code and list_supported_languages. However, since there is no output schema, it could have mentioned the return type or response structure, so it is not fully complete.

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 100%, so the baseline is 3. The description does not add extra meaning to the parameters beyond what the schema already states. It refers to 'code syntax' and 'code validity' but does not elaborate on parameter format or constraints beyond the schema's enum and type definitions.

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 validates code syntax via static analysis without executing it. The verb 'validate' is specific, and the phrase 'without executing it' distinguishes it from sibling tools like execute_code.

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 provides clear usage context: 'Use this to check code validity before execution or to help debug syntax issues.' It implies when to use it (before running code) but does not explicitly name alternatives or exclusion scenarios, so it falls short of a 5.

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. Dates show when Glama detected each change.

9 tool updatesv1.0.0Aug 11, 2026
- First observedexecute_code
- First observedget_cache_stats
- First observedget_cached_script
- First observedget_execution_limits
- First observedlist_allowed_packages
- First observedlist_cached_scripts
- First observedlist_supported_languages
- First observedsearch_cached_scripts
- First observedvalidate_code

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct action: validation, execution, listing languages, listing packages, limits, cache search, cache list, cache retrieval, and cache stats. No two tools overlap in purpose, and descriptions clearly differentiate between similar-sounding operations like search_cached_scripts vs list_cached_scripts.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., validate_code, list_supported_languages, get_execution_limits, search_cached_scripts). There is no mixing of conventions or inconsistent verb styles.

Tool Count5/5

9 tools is well-scoped for a code execution service. It covers validation, execution, environment discovery (languages, packages, limits), and a complete cache querying subsystem without redundancy or bloat.

Completeness4/5

The core domain is well-covered: validate and execute code, discover supported languages/allowed packages/limits, and search/list/retrieve cached scripts. Minor gaps like cache deletion or clearing are absent, but they are not essential for primary use cases.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
ai.cdbx
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Code Execution Developer Tools
1
gjallaOAuth
io.gjalla
Production-readiness for your AI coding agents.
Coding Agents Agent Orchestration
22
searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
62
STUzhy-py_execute_mcp BOAuth
ai.smithery
Run Python code in a secure sandbox without local setup. Declare inline dependencies and execute s…
Code Execution Developer Tools
2

Related MCP Servers

HOPX MCP Serverofficial
Code Execution Developer Tools Agent Orchestration
hopx-ai
F
license
Not graded
quality
C
maintenance
Enables AI assistants to execute Python, JavaScript, Bash, and Go code in blazing-fast (~0.1ms startup), isolated cloud containers with secure, ephemeral environments that auto-destroy after use.
Updated 9 months ago (2025-12-03 19:10 UTC)
155
-
Code Executor MCP Server
Code Execution Developer Tools Autonomous Agents
CSOAI-ORG
A
license
Not graded
quality
A
maintenance
Provides sandboxed code execution for AI agents with support for Python, JavaScript, and shell commands. Includes comprehensive safety features like destructive pattern blocking, timeout protection, and restricted file access for secure production use.
Updated 2 days ago (2026-09-04 12:36 UTC)
22
MIT
mcp-run-isolated-python
Code Execution Developer Tools
Kigstn
A
license
Not graded
quality
C
maintenance
Enables LLMs to execute Python code securely in a sandboxed environment. Supports configurable restrictions like no network access and returns results including files.
Updated 2 months ago (2026-07-09 13:38 UTC)
MIT
E2B MCP Server
Code Execution AI & Machine Learning
parth012001
F
license
A
quality
D
maintenance
Enables AI assistants to securely execute Python and JavaScript code in sandboxed environments, with file management and package installation.
Updated a year ago (2025-08-14 20:49 UTC)
7
88
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rafalswiderski/mcp-code-executor'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🚀 Dynamic Code Executor MCP Server

🎯 Why This Project?

🎬 How It Works - Visual Guide

Execution Flow

Interaction Sequence

Caching Strategy Visualization

✨ Features

🔄 How It Works - Step by Step

Detailed Steps:

🛠️ Available Tools

execute_code

validate_code

list_supported_languages

list_allowed_packages

search_cached_scripts

list_cached_scripts

get_cached_script

get_cache_stats

get_execution_limits

📦 Installation

⚙️ Configuration

For Claude Desktop

For GitHub Copilot (VS Code)

For Cline + OLLAMA

📚 Documentation

💡 Usage Examples

Example 1: Python with Packages

Example 2: JavaScript with Packages

Example 3: TypeScript

Example 4: Data Processing with NumPy

Example 5: Web Scraping

Example 6: File Operations in Sandbox

🔒 Security

Process Isolation

Sandboxed Workspaces

💾 Caching Strategy

Session Cache (Temporary)

Persistent Cache (Permanent)

📁 Workspace Access

📋 Requirements

🤝 Contributing

📄 License

🙏 Acknowledgments

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

HOPX MCP Serverofficial

Latest Blog Posts

MCP directory API

`execute_code`

`validate_code`

`list_supported_languages`

`list_allowed_packages`

`search_cached_scripts`

`list_cached_scripts`

`get_cached_script`

`get_cache_stats`

`get_execution_limits`