← Back to blog

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 60

Add 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:

ToolWhat your agent does with it
vm_bashRun shell commands — tests, builds, git, anything
vm_readRead source code and log files
vm_writeCreate or modify files
vm_lsExplore directory structure
vm_grepSearch across the codebase

A real workflow

You tell your agent: "Fix the failing test in src/auth.test.ts."

Here's what happens:

  1. Agent calls vm_grep({ pattern: "describe.*auth", path: "src/" }) to find the test
  2. Agent calls vm_read({ path: "src/auth.test.ts" }) to read it
  3. Agent calls vm_read({ path: "src/auth.ts" }) to understand the implementation
  4. Agent figures out the bug, calls vm_write({ path: "src/auth.ts", content: "..." }) with the fix
  5. Agent calls vm_bash({ command: "cd /root/project && pnpm test src/auth.test.ts" }) to verify
  6. Test fails — agent reads the output, adjusts, writes again
  7. 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" --json

Both work. MCP is better when the agent needs to read and write files frequently:

  • No shell escaping. vm_write takes a content string — no heredocs, no quoting nightmares
  • Typed inputs. Each tool has a schema. The agent knows exactly what parameters to pass
  • Structured output. vm_bash returns { 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-it

The server is disposable. The peace of mind is free.