MCP Servers & AI Agents

NullBore is a natural fit for exposing local MCP (Model Context Protocol) servers to cloud-hosted AI agents.

The problem

You have an MCP server running locally — maybe a file system tool, a database query tool, or a custom integration. Your AI agent runs in the cloud. It needs to reach your local MCP server, but your machine is behind NAT.

The solution

# Start your MCP server locally
my-mcp-server --port 4000

# Expose it with NullBore
nullbore open --port 4000 --ttl 2h --idle --name my-tools
# ✓ https://my-tools.tunnel.nullbore.com → localhost:4000

Now point your cloud agent at https://my-tools.tunnel.nullbore.com. When your session ends, the tunnel closes.

Why NullBore for MCP

• Temporary by design: MCP servers shouldn't be permanently exposed. NullBore tunnels auto-close.
• Idle TTL: Tunnel stays alive while the agent is working, closes after inactivity.
• HTTPS out of the box: Cloud agents typically require HTTPS endpoints.
• API-driven: Agents can open and close tunnels programmatically.

With OpenClaw

OpenClaw agents can manage NullBore tunnels directly via the REST API:

# Agent opens a tunnel to your local MCP server
curl -X POST https://tunnel.nullbore.com/v1/tunnels \
  -H "Authorization: Bearer nbk_your_key" \
  -d '{"local_port": 4000, "name": "agent-tools", "ttl": "1h", "idle_ttl": true}'

# Agent uses the tunnel
# ... work happens ...

# Agent closes the tunnel when done
curl -X DELETE https://tunnel.nullbore.com/v1/tunnels/{id} \
  -H "Authorization: Bearer nbk_your_key"

Security considerations

• Use short TTLs or idle TTL mode — don't leave MCP servers exposed longer than necessary
• Each tunnel gets its own HTTPS certificate
• API key auth prevents unauthorized tunnel creation
• The tunnel relay never inspects payload content