How do I use Agent Workspace 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., "@Agent Workspace MCP Server Create a new Python project with uv and run a hello world script." 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.

Agent Workspace MCP Server

by HrRodan

Overview Schema Related Servers Score Discussions

Python

Local

🛡️ Agent Workspace MCP Server

License: MIT Python 3.14+

A unified Model Context Protocol (MCP) server providing a highly secure, containerized workspace for Large Language Models (LLMs). It acts as an isolated "agentic playground" where agents can autonomously code, test, and debug without risking the host machine.

✨ Features

🏗️ Full Project Lifecycle: Bootstrap projects with uv init, manage dependencies with uv add, and execute via uv run.
🐚 Secure Bash Access: Execute shell commands with mandatory timeouts and merged output streams.
🚀 Token-Optimized Output: Integrates RTK (Rust Token Killer) to automatically filter and compress run_bash outputs (like ls, git, and test runners), saving 60-90% of LLM context tokens.
📂 Robust Filesystem: Path-traversal protected operations for reading, writing, and searching the workspace.
🛡️ Multi-Layer Security: Non-root execution, dropped capabilities, resource limits, and a read-only root filesystem.
⚡ Precision Editing: Advanced search_and_replace with fuzzy whitespace matching, indentation preservation, dry-run support, and syntax validation for Python, JSON, JSONL, TOML, and YAML.
📊 Real-time Observability: Direct logging to MCP client UI and persistent rotating audit logs.

Related MCP server: Debugging MCP Server

🏗️ Architecture

flowchart TD
    Client["MCP Client (Claude / Cursor)"] -- "stdio (JSON-RPC)" --> FastMCP["FastMCP Server"]

    subgraph Sandbox ["Docker Sandbox Container (mcpuser)"]
        direction TB
        
        FastMCP -. "Intercepts accidental prints" .-> StdioGuard["StdoutRedirector"]
        FastMCP -. "Application Logs" .-> Logger["Dual Logger (stderr & .mcp/server.log)"]
        
        FastMCP -- "Tool Calls" --> SecurityGuard["Security & Path Validator"]
        
        subgraph Toolset ["Tool Modules"]
            direction TB
            SecurityGuard --> FSTools["Filesystem (read, write, list, search)"]
            SecurityGuard --> EditTools["Editing (search_and_replace)"]
            SecurityGuard --> ExecTools["Execution (run_bash)"]
        end

        EditTools -- "AST Verification" --> Validator["Syntax Validations (Python, JSON, JSONL, TOML, YAML)"]
        ExecTools -- "Process Group (Timeout=60s)" --> Shell["/bin/sh Subprocess"]
        Shell -- "Package Mgt & Checks" --> UV["uv Environment / Ruff"]
        
        FSTools -- "Secure I/O" --> Workspace["/workspace Directory"]
        EditTools -- "Atomic Writes" --> Workspace
        Shell -- "Executes within" --> Workspace
    end

    Workspace <--"Volume Mount"--> HostFS["User Host Filesystem"]

📦 Quick Start

1. Pull or Build the Docker Image

# Pull from GHCR
docker pull ghcr.io/hrrodan/agent-workspace-mcp:latest

# OR: Build locally with your host's UID/GID for optimal permissions
docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) -t agent-workspace-mcp .

2. Programmatic Usage (OpenAI Agents SDK)

Here is a quick boilerplate showing how to use the containerized workspace programmatically using the standard openai-agents SDK:

import asyncio
from agents import Agent, Runner
from agents.mcp import MCPServerStdio

async def main():
    # 1. Configure the MCP Server to run via Docker
    server = MCPServerStdio(
        name="Sandboxed Workspace",
        params={
            "command": "docker",
            "args": [
                "run", "-i", "--rm", "--init",
                # "--network", "none", # Network Isolation (optional) - see below
                "--memory=2g", "--cpus=2.0",
                "--pids-limit=256",
                "--cap-drop=ALL", "--security-opt=no-new-privileges:true",
                "--read-only",
                "--tmpfs", "/tmp:size=64m",
                "--tmpfs", "/home/mcpuser/.cache:size=512m",
                "--user", "1000:1000", # Replace with your host UID:GID
                "-v", "/path/to/your/projects:/workspace",
                "ghcr.io/hrrodan/agent-workspace-mcp:latest",
            ],
        },
        client_session_timeout_seconds=60.0,
    )

    # 2. Attach server to the Agent and load the skill instructions (optional)
    with open("skills/agent-workspace-mcp/SKILL.md", "r") as f:
        skill_instructions = f.read()

    agent = Agent(
        name="WorkspaceAgent",
        instructions=f"You are a coding agent with access to a secure workspace.\n\n{skill_instructions}",
        mcp_servers=[server],
    )

    # 3. Execute a workflow
    async with server:
        result = await Runner.run(
            agent, 
            "Create a python script in the workspace to print the first 10 Fibonacci numbers, then run it."
        )
        print(f"Agent's Final Output:\n{result.final_output}")

if __name__ == "__main__":
    asyncio.run(main())

3. Use with MCP Clients (Claude / Cursor)

Add the following configuration to your claude_desktop_config.json or Cursor settings.

{
  "mcpServers": {
    "agent-workspace-mcp": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm", "--init",
        // "--network", "none", // Network Isolation (optional) - see below
        "--memory=2g", "--cpus=2.0",
        "--pids-limit=256",
        "--cap-drop=ALL", "--security-opt=no-new-privileges:true",
        "--read-only",
        "--tmpfs", "/tmp:size=64m",
        "--tmpfs", "/home/mcpuser/.cache:size=512m",
        "--user", "1000:1000",
        "-v", "/path/to/your/projects:/workspace",
        "ghcr.io/hrrodan/agent-workspace-mcp:latest"
      ]
    }
  }
}

IMPORTANT

Linux Users: Replace 1000:1000 with your actual UID:GID (run id -u and id -g). Claude Desktop does not expand environment variables. Signal Handling: The --init flag is essential for proper signal forwarding and zombie process reaping.

🛠️ Tool Reference

Tool	Description
`read_file`	Read text files with optional `offset` and `limit` (default: 100 lines).
`write_file`	Create files with syntax validation and a 5MB size guard. Refuses to overwrite existing files by default (`create_only=True`).
`list_directory`	List contents with `[F]`ile and `[D]`irectory prefixes.
`search_workspace`	Find files by glob pattern with support for `exclude_patterns`.
`run_bash`	Execute shell commands in `/workspace` with a 60s timeout. Automatically optimized via RTK to reduce token usage.
`search_and_replace`	Multi-edit tool with fuzzy whitespace matching, indentation preservation, dry-run mode, and syntax validation (Python, JSON, JSONL, TOML, YAML).

⚙️ Configuration

The server supports the following environment variables (passed via Docker --env):

Variable	Default	Description
`COMMAND_TIMEOUT`	`60`	Default seconds before `run_bash` kills a process.
`MAX_SEARCH_RESULTS`	`50`	Maximum results returned by `search_workspace`.
`MAX_READ_SIZE_BYTES`	`1048576`	Maximum file size for `read_file` (1MB).
`MAX_WRITE_SIZE_BYTES`	`5242880`	Maximum file size for `write_file` (5MB).
`LOG_LEVEL`	`INFO`	Python logging level (DEBUG, INFO, etc.).

🛡️ Security & Architecture Model

This server employs a defense-in-depth strategy, explicitly separating strict security boundaries from developer experience and operational reliability features.

🔒 Core Security Features

These features are designed to protect the host system and enforce strict isolation boundaries.

Kernel Hardening: All Linux capabilities are dropped (--cap-drop=ALL), neutralizing privilege escalation vectors.
Immutable Server Code: The /app directory containing the server source and its virtual environment is owned by root and read-only for the mcpuser. This prevents the server from modifying itself or being tampered with via run_bash.
Privilege Lockdown: Enforces no-new-privileges:true to prevent any process from gaining elevated rights.
Immutable System Core: The container's root filesystem is mounted entirely read-only, providing a second layer of defense against OS-level tampering.
Resource Quotas: Hard limitations on CPU, Memory, and PIDs mitigate denial-of-service (DoS) attempts like fork-bombs and host exhaustion.
Strict Boundary Enforcement: A robust path validator comprehensively blocks all path traversal attacks outside the designated /workspace.
Process & Resource Control: Mandatory command timeouts (default 60s) and strict process group isolation ensure runaway or malicious processes are killed.
Memory-Overload Protection: Hard limits on file reads (1MB) and command outputs (50KB) prevent memory exhaustion.
Information Leakage Prevention: Internal stack traces and system paths are suppressed and sanitized from tool outputs.

🛠️ Developer Experience & Convenience

Features focused on seamless integration, usability, and reducing friction during agentic workflows.

Host-Aligned Non-Root Identity: Runs as mcpuser with UID/GID customizable at build time, eliminating tedious file permission conflicts on host volume mounts.
Automatic Token Optimization: Shell commands executed via run_bash are transparently rewritten through RTK to provide ultra-compact, LLM-friendly output without altering underlying command behavior.
Intelligent Search Exclusions: High-noise or sensitive directories (.git, .venv) are automatically ignored to keep context windows lean and relevant.
Ephemeral Workspaces: Containers are strictly ephemeral (--rm), guaranteeing a clean, predictable slate for every new session without state leaking across connections.
Standardized Discovery: Complies with the OCI Image Specification for standardized container ecosystem integration and transparent auditing.

⚙️ Reliability & Safety Mechanisms

Features ensuring the structural integrity of the workspace and providing observability.

Pre-Write Syntax Validation: Both write_file and search_and_replace perform in-memory syntax validation for Python, JSON, JSONL, TOML, and YAML before persisting changes, preventing broken code states.
Fail-Safe Writing: write_file blocks accidental overwrites of existing files by default and enforces a 5MB size guard to prevent workspace flooding.
Atomic File Operations: Edits utilize temp-and-move logic to guarantee file integrity and prevent corruption, even during unexpected interruptions or crashes.
Transparent Observability: All tool invocations and state changes are streamed in real-time to the MCP client UI for immediate operator oversight.

🌐 Network Isolation (Optional)

By default, the container has full network access via Docker's bridge network. For maximum isolation, you can completely disable the network stack using --network none:

docker run -i --rm --init \
  --network none \
  --memory=2g --cpus=2.0 --pids-limit=256 \
  --cap-drop=ALL --security-opt=no-new-privileges:true \
  --read-only \
  --tmpfs /tmp:size=64m \
  --tmpfs /home/mcpuser/.cache:size=512m \
  --user 1000:1000 \
  -v /path/to/your/projects:/workspace \
  ghcr.io/hrrodan/agent-workspace-mcp:latest

This creates a fully air-gapped sandbox — only the loopback interface exists inside the container. All outbound connections (curl, DNS, uv add, etc.) will fail immediately, eliminating data exfiltration and lateral movement risks entirely.

NOTE

With--network none, the agent cannot install packages at runtime. All dependencies must be pre-installed in a custom image or pre-populated in the mounted workspace volume.

🤝 Contributing

Install Dev Dependencies: uv sync
Run Linting: uv run ruff check .
Run Unit Tests: uv run pytest tests/ --ignore=tests/integration/
Run Integration Tests: Set OPENROUTER_API_KEY and run uv run pytest tests/integration/

Available Tools

6 tools

list_directoryList DirectoryA

Read-only

List directory contents. Returns [F]/[D] prefixed entries. Excludes .git, .venv, pycache.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Directory path relative to /workspace.	.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: output format ([F]/[D] prefixes) and filtered exclusions (.git, .venv, __pycache__). No contradiction.

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?

Two concise sentences deliver key information efficiently with minimal 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 read-only tool with output schema and readOnlyHint, the description sufficiently covers purpose and exclusions; however, it could mention recursion behavior or sorting order.

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%, and the description adds no additional meaning beyond what the schema provides for the 'path' parameter, meeting the 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 clearly states 'List directory contents' and adds specific details about prefix notation ([F]/[D]) and exclusions, making it distinct from sibling tools like read_file or run_bash.

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 for listing directories but provides no explicit guidance on when to choose this tool over alternatives like read_file or search_workspace.

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

read_fileRead FileA

Read-only

Read a text file. Text only, max 1MB, returns first 100 lines. Use offset/limit for segments or run_bash('grep/head/tail') for large files.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max lines to return.
`offset`	No	Start line (0-based).
`filepath`	Yes	File path relative to /workspace.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true. Description adds specific constraints: text only, max 1MB, returns first 100 lines. No contradictions. Could mention auth but not needed.

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 purpose, no filler. Every word adds value.

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 output schema exists (not shown), description covers key constraints, usage guidance, and alternatives. Complete for a 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?

Schema coverage is 100%, so baseline 3. Description mentions offset/limit for segments but adds no new meaning beyond schema defaults and descriptions.

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?

States 'Read a text file' with clear constraints (text only, 1MB max, first 100 lines). Distinct from siblings like write_file (write) and run_bash (commands).

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 tells when to use this tool (text files) and when to use alternatives: 'Use offset/limit for segments or run_bash('grep/head/tail') for large files.'

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

run_bashRun Shell CommandA

Destructive

Run a shell command in /workspace. Returns [Exit code: N] + merged stdout/stderr, truncated at 50KB.

Tools: curl, git, jq, patch, tree, fd, rg, zip, tar and standard coreutils. Supports pipes, redirects, &&, ||.

Python/packages (uv only — no python/pip): uv run script.py Run scripts (auto-installs deps from imports) uv add/remove Manage project dependencies uv init Scaffold new project with pyproject.toml uvx Run CLI tools without install (e.g. uvx ruff check .)

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	Shell command to execute.
`timeout`	No	Max seconds before kill. Increase for long builds.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds value by detailing output format (exit code, merged streams, 50KB truncation) and listing available tools, as well as Python handling via uv. This goes beyond the annotations.

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: it opens with the core purpose, then describes output, lists tools, and covers Python specifics. Every sentence adds value without 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?

The description covers key aspects: execution environment, output limits, available tools, and Python constraints. It does not elaborate on security or resource limits, but given the tool's complexity, it is sufficiently complete.

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?

Schema coverage is 100%, so parameters are documented. The description adds context about the working directory (/workspace) and provides guidance on the timeout parameter ('Increase for long builds'), which enhances understanding beyond the 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 'Run a shell command in /workspace,' specifying the verb, resource, and location. It distinguishes from sibling tools (file operations, search) by targeting shell execution.

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 when to use (shell commands in /workspace) but does not explicitly state when not to use or offer alternatives. It implies differentiation from siblings through the nature of operations.

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

search_and_replaceSearch and ReplaceA

DestructiveIdempotent

Primary file editing tool — prefer over patch. Replaces substrings with fuzzy whitespace fallback. Returns unified diff. Validates .py/.json/.toml/.yaml syntax.

ParametersJSON Schema

Name	Required	Description
`edits`	Yes	[{"old": "exact_text", "new": "replacement"}]
`dry_run`	No	Preview diff without applying.
`filepath`	Yes	File path relative to /workspace.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true. Description adds that it returns unified diff and validates syntax, providing useful behavioral context beyond annotations. No contradictions.

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 primary purpose, no unnecessary words. Efficient and clear.

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?

With 3 parameters, output schema exists, and annotations present, the description covers purpose, alternatives, behavior, and validation. Could mention failure mode for syntax validation, but overall sufficient.

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 schema already documents all parameters. Description adds example for edits format and clarifies filepath relative to /workspace, but adds minimal new meaning beyond 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 uses specific verb 'replaces substrings' and resource 'file editing tool', distinguishes from sibling 'prefer over patch'. Clearly states primary purpose.

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 'prefer over patch', providing clear alternative. Implies when to use this tool (editing with substring replacement) and when not (when patch is more appropriate).

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

search_workspaceSearch WorkspaceA

Read-only

Find files by glob pattern. Returns up to 50 paths. For content search use run_bash with grep.

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes	Glob pattern (e.g. 'src/*/.py').
`exclude_patterns`	No	Glob patterns to exclude.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Adds return limit context beyond annotations' readOnlyHint. No contradiction. Could mention pagination or error handling.

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, 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?

Covers purpose, limit, alternative. Output schema exists. Lacks mention of error states or filesystem scope, but sufficient for a read-only search 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 coverage 100%, description doesn't add much to param definitions. Baseline 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?

Clearly states action ('Find files'), method ('glob pattern'), and constraint ('up to 50 paths'). Distinguishes from sibling tools like 'list_directory' and 'read_file'.

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 tells when not to use ('For content search use run_bash with grep') and provides an alternative.

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

write_fileWrite FileA

DestructiveIdempotent

Create or overwrite a file. Creates parent dirs. For partial edits use search_and_replace. Validates .py/.json/.toml/.yaml syntax before writing.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Complete file content.
`filepath`	Yes	File path relative to /workspace.
`create_only`	No	If true, fail when file exists.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=true; the description adds that parent directories are created and syntax validation occurs for .py/.json/.toml/.yaml files, providing behavioral context beyond annotations.

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: first states main action, second provides additional behaviors and an alternative. Highly concise and front-loaded with 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?

Covers key functionality (creation, overwrite, parent dirs, validation) but does not detail error behavior on validation failure or behavior of 'create_only' parameter beyond schema description.

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?

Schema coverage is 100% with descriptions for each parameter; the description adds value by implying 'content' is full file content and mentioning parent directory creation (related to 'filepath') and syntax validation (related to 'content').

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 verb 'Create or overwrite' and the resource 'a file', and distinguishes itself from sibling tool 'search_and_replace' for partial edits.

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 explicit guidance to use 'search_and_replace' for partial edits, but does not comprehensively cover when to use vs. other siblings like 'read_file'.

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.

6 tool updatesv1.4.0Jul 28, 2026
- First observedlist_directory
- First observedread_file
- First observedrun_bash
- First observedsearch_and_replace
- First observedsearch_workspace
- First observedwrite_file

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: read_file for reading, write_file for overwriting, list_directory for listing, search_workspace for locating files by pattern, run_bash for arbitrary shell commands, and search_and_replace for partial edits. No ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., read_file, write_file, list_directory). The only exception is search_and_replace, which combines two verbs, but it still aligns with the overall style.

Tool Count5/5

With 6 tools, the set is well-scoped for an agent workspace. It covers essential operations (file read/write, directory listing, file search, shell execution, and text editing) without unnecessary clutter.

Completeness4/5

The tool set covers most common operations, but lacks dedicated tools for file deletion, renaming, or appending. However, these gaps can be addressed via run_bash, so only minor incompleteness is present.

Maintenance

ActivityNo data

ResponsivenessUnresponsive

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
reachpad-mcp A
io.github.Reachpad
Coding agents build full-stack apps in persistent workspaces and share them by link.
Code Execution Developer Tools Cloud Platforms
2413
Fractera A
io.github.Fractera
Zero-Ops deploy of a private AI workspace to your own VPS — from your AI chat. Free and open-source.
Cloud Platforms Virtualization Autonomous Agents
62
gjallaOAuth
io.gjalla
Production-readiness for your AI coding agents.
Coding Agents Agent Orchestration
22

Related MCP Servers

MCP Docker Sandbox Interpreter
Code Execution Shell Access Virtualization
svngoku
F
license
Not graded
quality
D
maintenance
A secure Docker-based environment that allows AI assistants to safely execute code without direct access to the host system by running all code within isolated containers.
Updated a year ago (2025-04-22 08:33 UTC)
4
-
Debugging MCP Server
Developer Tools Testing & QA Tools
luischang07
F
license
A
quality
D
maintenance
Enables LLMs to automatically diagnose coding errors through codebase search, test execution, and live debugger integration (DAP/V8 CDP). Provides a secure, policy-gated environment for investigating failures while preventing destructive operations.
Updated 5 months ago (2026-04-05 00:45 UTC)
9
-
Docker MCP Server
Code Execution Virtualization
cevatkerim
A
license
Not graded
quality
D
maintenance
Enables LLMs to safely execute code in isolated Docker containers with resource limits and security controls, supporting session management and automatic dependency installation.
Updated a year ago (2025-08-08 21:18 UTC)
MIT
mcp-secure-sandbox
Code Execution Code Analysis
syed-muslim2603
F
license
Not graded
quality
C
maintenance
Provides a secure, containerized Python sandbox for executing LLM-generated code with multi-layer isolation, along with JSON/CSV validation and workspace state snapshots.
Updated 2 months ago (2026-06-30 16:18 UTC)
-

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/HrRodan/agent-workspace-mcp'

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