code-execution-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@code-execution-mcprun 'ls -la' and show output"
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.
Code Execution MCP Server
A Model Context Protocol (MCP) server that exposes Agent Zero's battle-tested code execution capabilities.
This MCP server allows any AI agent (Claude, Cursor, Windsurf, etc.) to execute terminal commands and Python code on the host system using Agent Zero's proven implementation.
Features
Execute Terminal Commands: Run shell commands with full session persistence
Execute Python Code: Run Python code via IPython with session management
Multiple Sessions: Maintain separate execution contexts
Smart Output Handling: Automatic prompt detection, timeout management, and dialog detection
Cross-Platform: Works on Linux, macOS, and Windows (experimental)
Related MCP server: Terminally MCP
MCP Client Configuration (no installation needed)
Add to your application MCP config:
simple case using uvx
{
"mcpServers": {
"code-execution": {
"command": "uvx",
"args": ["code-execution-mcp"]
}
}
}or pipx if uvx is not installed
{
"mcpServers": {
"code-execution": {
"command": "pipx",
"args": ["run", "code-execution-mcp"]
}
}
}Additional configuration
The MCP server can be configured via environment variables:
# Shell executable (default: /bin/bash on Unix, powershell.exe on Windows)
export CODE_EXEC_EXECUTABLE=/bin/bash
# Init commands (semicolon-separated, run when creating new sessions, empty by default)
export CODE_EXEC_INIT_COMMANDS="source /path/to/venv/bin/activate;export PATH=\$PATH:/custom/bin"
# Timeout configuration (in seconds)
export CODE_EXEC_FIRST_OUTPUT_TIMEOUT=30 # Wait for first output
export CODE_EXEC_BETWEEN_OUTPUT_TIMEOUT=15 # Wait between output chunks
export CODE_EXEC_DIALOG_TIMEOUT=5 # Detect dialog prompts
export CODE_EXEC_MAX_EXEC_TIMEOUT=180 # Maximum execution time
# Log directory (default empty = logging disabled)
export CODE_EXEC_LOG_DIR=/path/to/logsAdditional examples
start sessions with custom shell and python environment + logging
{
"mcpServers": {
"code-execution-mcp": {
"command": "uvx",
"args": ["code-execution-mcp"],
"env": {
"CODE_EXEC_EXECUTABLE": "/bin/zsh",
"CODE_EXEC_INIT_COMMANDS": "source /Users/lazy/Projects/code-execution-mcp/.venv/bin/activate",
"CODE_EXEC_LOG_DIR": "/Users/lazy/Projects/code-execution-mcp/logs"
}
}
}
}override timeouts
{
"mcpServers": {
"code-execution-mcp": {
"command": "uvx",
"args": ["code-execution-mcp"],
"env": {
"CODE_EXEC_FIRST_OUTPUT_TIMEOUT": "60",
"CODE_EXEC_MAX_EXEC_TIMEOUT": "300"
}
}
}
}Manual installation
# Clone or download this package, then navigate to the directory
git clone https://github.com/agent0ai/code-execution-mcp.git
cd </path/to>/code-execution-mcp
# Install dependencies
pip install -e .and run with config:
{
"mcpServers": {
"code-execution-mcp": {
"command": "python",
"args": ["</path/to/code-execution-mcp>/main.py"]
}
}
}Available Tools
execute_terminal
Execute a terminal command in the specified session.
Parameters:
command(string, required): The shell command to executesession(integer, optional): Session (terminal window) number (default: 0)
Output:
(string) The accumulated terminal output from the session
execute_python
Execute Python code via IPython in the specified session.
Parameters:
code(string, required): The Python code to executesession(integer, optional): Session (terminal window) number (default: 0)
Output:
(string) The accumulated IPython output from the session
get_output
Get accumulated output from a terminal session.
Parameters:
session(integer, optional): Session (terminal window) number (default: 0)
Output:
(string) The accumulated terminal output from the session
reset_terminal
Reset a terminal session, closing and reopening it.
Parameters:
session(integer, optional): Session (terminal window) number (default: 0)reason(string, optional): Reason for the reset
Output:
(string) Text confirmation for the agent
Session Management
Sessions (terminal instances) allow maintaining separate execution contexts for multitasking, persistence or context isolation
Each session can be used and reset individually
Sessions persist until reset
Session 0 is default
Any session number can be used
Virtual Environment Considerations
Important: When the MCP server is launched from a virtual environment, shell sessions may NOT automatically inherit the venv activation.
Solution: Use init commands to explicitly activate your virtual environment:
{
"env": {
"CODE_EXEC_INIT_COMMANDS": "source /path/to/venv/bin/activate"
}
}Platform Support
Linux: Fully tested and supported
macOS: Fully tested and supported
Windows: Experimental support via pywinpty
Some features may behave differently
Architecture
This MCP server is a minimal wrapper around Agent Zero's code execution tool:
Preserves Agent Zero's battle-tested logic
No rewrites or reimplementations
Uses Agent Zero's helper modules unchanged:
tty_session.py- TTY session managementshell_local.py- Local shell interfaceprint_style.py- Output styling and loggingstrings.py- String manipulation utilities
Security
WARNING: This MCP server allows full code execution on the host system. Security is the responsibility of the MCP client.
Only use with trusted AI agents and in controlled environments.
License
MIT License
This project wraps and reuses code from Agent Zero (Copyright (c) 2025 Agent Zero, s.r.o), which is licensed under the MIT License.
See the LICENSE file for full license text and attribution details.
Credits
Built on Agent Zero's proven code execution implementation.
This MCP server preserves and reuses Agent Zero's battle-tested code:
Core execution logic from
code_execution_tool.pyHelper modules:
tty_session.py,shell_local.py,print_style.py,strings.pyAll system message prompts
All credit for the robust code execution implementation goes to the Agent Zero team.
Uses FastMCP for MCP protocol handling.
Available Tools
4 toolsexecute_pythonD
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| session | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_terminalD
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| session | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_outputD
| Name | Required | Description | Default |
|---|---|---|---|
| session | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reset_terminalD
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| session | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no 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. Dates show when Glama detected each change.
4 tool updates
v0.1.3- First observed
execute_python - First observed
execute_terminal - First observed
get_output - First observed
reset_terminal
TDQS
The two execution tools (execute_terminal and execute_python) are distinct by target environment, but without descriptions an agent might initially confuse them. get_output and reset_terminal are clearly distinct.
All tool names follow a consistent verb_noun snake_case pattern: execute_terminal, execute_python, get_output, reset_terminal. This is uniform and predictable.
Four tools is well-scoped for a code execution server: two execution methods, output retrieval, and terminal reset. Each tool earns its place.
The core lifecycle of execute, retrieve output, and reset is covered. Minor gaps exist around managing multiple concurrent sessions or explicit error/status checks, but agents can work within this surface.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseBqualityFmaintenanceAn MCP server that allows AI models to execute system commands on local machines or remote hosts via SSH, supporting persistent sessions and environment variables.13628MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI assistants the ability to create, manage, and control terminal sessions through a safe, isolated tmux environment.1-
- FlicenseAqualityDmaintenanceA lightweight MCP server that provides AI assistants with access to a system's terminal through a secure terminal tool. It enables users to execute shell commands and receive stdout, stderr, and exit codes directly within an MCP-compatible client.1-
- AlicenseBqualityAmaintenanceA secure MCP server for shell operations, terminal management, and process control, enabling AI assistants to safely execute commands and manage interactive sessions.132046MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ai-integr8tor/agent0ai-code-execution-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server