AI Agents + Gibil MCP: Development on Real Infrastructure
How AI agents use MCP tools to read, write, and run code on a remote server — without touching your machine.
Your AI agent is good at writing code. But it runs on your machine — your files, your configs, your running services. One bad rm -rf and your afternoon is gone.
What if your agent worked on a disposable server instead?
The setup
Two steps. Forge a server, point your agent at it.
gibil create --name my-task --repo github.com/you/project --ttl 60Add to your agent's MCP config (e.g. .claude/settings.json for Claude Code, or the equivalent for your agent):
{
"mcpServers": {
"gibil": {
"command": "gibil",
"args": ["mcp", "my-task"]
}
}
}Your agent now has five tools:
| Tool | What your agent does with it |
|---|---|
vm_bash | Run shell commands — tests, builds, git, anything |
vm_read | Read source code and log files |
vm_write | Create or modify files |
vm_ls | Explore directory structure |
vm_grep | Search across the codebase |
A real workflow
You tell your agent: "Fix the failing test in src/auth.test.ts."
Here's what happens:
- Agent calls
vm_grep({ pattern: "describe.*auth", path: "src/" })to find the test - Agent calls
vm_read({ path: "src/auth.test.ts" })to read it - Agent calls
vm_read({ path: "src/auth.ts" })to understand the implementation - Agent figures out the bug, calls
vm_write({ path: "src/auth.ts", content: "..." })with the fix - Agent calls
vm_bash({ command: "cd /root/project && pnpm test src/auth.test.ts" })to verify - Test fails — agent reads the output, adjusts, writes again
- Test passes — agent calls
vm_bash({ command: "git add -A && git commit -m 'fix: auth token validation'" })
Every step happens on the remote server. Your machine is untouched.
Why MCP over CLI mode
Your agent can also use gibil through plain bash:
gibil run my-task "cat src/auth.ts"
gibil run my-task "pnpm test" --jsonBoth work. MCP is better when the agent needs to read and write files frequently:
- No shell escaping.
vm_writetakes acontentstring — no heredocs, no quoting nightmares - Typed inputs. Each tool has a schema. The agent knows exactly what parameters to pass
- Structured output.
vm_bashreturns{ stdout, stderr, exit_code }— not a raw terminal dump
The difference is small for one command. It's large when the agent is doing 20 read-write-test cycles.
The safety model
Your local files are never at risk. The agent operates entirely on the remote server:
- Bad command? The server absorbs it
- Corrupt the project?
gibil destroy && gibil create— fresh in 90 seconds - Forget to clean up? TTL burns the server automatically
The agent literally cannot rm -rf your local machine through an MCP tool that SSHs into a remote server. It's not a policy — it's architecture.
When to use this
Good fit:
- Bug fixing and iteration (read, fix, test, repeat)
- Writing and running tests on a clean environment
- Exploring unfamiliar codebases
- Any task where you want your agent to have root access safely
Not the right fit:
- Quick one-off questions about your local code (let the agent read locally)
- Tasks that need to modify your local git working tree directly
Try it
npm install -g gibil
gibil auth setup # your Hetzner token
gibil create --name try-it --repo github.com/you/project --ttl 30
# Add MCP config, ask your agent to run the tests
gibil destroy try-itThe server is disposable. The peace of mind is free.