local-mcp-with-docker
# Local(stdio) MCP Server with Docker
This project is a minimal local MCP server that exposes a `run_command` tool over stdio.
## Setup
```bash
cd ~path-to-directory/local-mcp-with-docker
uv sync
```
Start the script using:
```bash
uv run main.py
```
Note: 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:
```bash
npx -y @modelcontextprotocol/inspector
```
Then in the inspector UI:
- Transport: `stdio`
- Command: `uv`
- Args: `run`, `python`, `main.py`
- Working directory: `~path-to-directory/local-mcp-with-docker`
The inspector should show the registered tool `run_command` and allow you to call it directly.
## Build the Docker image
```bash
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:
```json
{
"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
TDQS
Scored across 1 tool
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.