local-mcp-with-docker
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., "@local-mcp-with-dockerrun 'ls -la' in the workspace"
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.
Local(stdio) MCP Server with Docker
This project is a minimal local MCP server that exposes a run_command tool over stdio.
Setup
cd ~path-to-directory/local-mcp-with-docker
uv syncStart the script using:
uv run main.pyNote: from MCP 2.0 onward, there will be no output in the console after the server starts. The process stays alive and waits for stdio messages from an MCP client. You can inspect it using the debugger in a new terminal session.
Start the inspector:
npx -y @modelcontextprotocol/inspectorThen in the inspector UI:
Transport:
stdioCommand:
uvArgs:
run,python,main.pyWorking directory:
~path-to-directory/local-mcp-with-docker
The inspector should show the registered tool run_command and allow you to call it directly.
Related MCP server: mcp-stdio
Build the Docker image
docker build -t terminal_tool_docker .This creates the local Docker image used by the Claude Desktop MCP config.
Claude Desktop config
Add this to your Claude Desktop MCP config file:
{
"mcpServers": {
"local-mcp-with-docker": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--init",
"-e",
"DOCKER_CONTAINER=true",
"-e",
"WORKSPACE_DIR=/root/mcp/workspace",
"-v",
"path-to-directory/local-mcp-with-docker:/root/mcp/workspace",
"terminal_tool_docker"
]
}
}
}This mounts your workspace into the container and points the server at the correct working directory inside the container.
Claude screenshot

Available Tools
1 toolrun_commandA
Run a terminal command inside the workspace directory. If a terminal command can accomplish a task, tell the user you'll use this tool to accomplish it, even though you cannot directly do it
Args: command: The shell command to run.
Returns: The command output or an error message.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 transparently notes that the tool is a workaround for the AI's inability to run commands directly ('even though you cannot directly do it'). However, it fails to disclose potential risks like destructive side effects, sandboxing, or timeouts, which are critical for a command execution tool.
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?
The main description is three sentences long, with the core action stated first. The second sentence about user interaction could be integrated elsewhere but does not bloat the description. The Args section is sufficiently compact. No unnecessary filler.
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?
Given the absence of annotations and sibling tools, the description covers the basic purpose, location, return value, and a usage hint. However, it omits important details like synchronous execution, shell environment, restriction on interactive commands, or error behavior beyond a simple error message. The output schema is marked as existing but not shown, so the return description is a placeholder.
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?
The description adds minimal meaning beyond the input schema. The schema only provides a title 'Command', while the description says 'The shell command to run.' This clarifies it is a shell command but does not elaborate on syntax, quoting rules, or environment details. With 0% schema coverage, the description compensates only slightly.
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?
The first sentence clearly states the tool's primary action: 'Run a terminal command inside the workspace directory.' This is specific and unambiguous. The additional instruction about telling the user clarifies the tool's role but is more about usage than purpose.
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?
The description provides explicit guidance: 'If a terminal command can accomplish a task, tell the user you'll use this tool to accomplish it, even though you cannot directly do it.' This gives the agent a scripted interaction pattern. However, it lacks any mention of preconditions, security considerations, or alternative approaches.
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.
1 tool update
v0.1.0- First observed
run_command
TDQS
With only one tool, there is no possibility of confusion with other tools. The tool has a clear and singular purpose: running terminal commands.
With a single tool, consistency is not applicable, but a neutral score is given. The naming 'run_command' follows a simple verb_noun pattern which is acceptable.
A single tool for executing arbitrary commands is extremely thin for a server. It lacks any companion tools for file management, environment inspection, or other common development tasks, making it feel incomplete.
The server only provides command execution, missing obvious complementary capabilities like file reading/writing, directory listing, or process management that would be expected for a workspace-focused server. Agents are forced to rely on the single tool for all tasks, which is severely limited.
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
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA basic MCP server implementation for testing purposes. Communicates via stdio and is designed to work with MCP-compliant clients.-
- AlicenseNot gradedqualityCmaintenanceA minimal, zero-dependency MCP server that enables defining and running tools over stdio transport, without extra features like HTTP or resources.561MIT
- AlicenseAqualityCmaintenanceA minimal MCP server that provides a single 'hello' tool returning 'Hello, world!'.26MIT
- AlicenseAqualityFmaintenanceA minimal MCP server that exposes a single bash tool to execute commands inside a devcontainer, returning real output and exit codes.1MIT
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/praveen-radakirouchenane/local-mcp-with-docker'
If you have feedback or need assistance with the MCP directory API, please join our Discord server