Dynamic Code Executor MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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:
Returns execution results including output, errors, and execution time. |
| 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. |
| list_supported_languagesA | List all supported programming languages with their capabilities and package managers |
| get_execution_limitsB | Get information about execution limits and constraints |
| 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. |
| 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:
Returns ranked results by similarity with scores. |
| 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. |
| get_cached_scriptA | Get a specific cached script by its hash. Returns the full script details including code, result, packages used, and execution stats. |
| get_cache_statsA | Get statistics about the persistent script cache |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
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.
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.
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.
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.