Pilot Mcp Bridge
ReviewAudited by ClawScan on May 10, 2026.
Overview
The bridge matches its stated purpose, but it would let an agent run broad Pilot network and gateway commands without documented limits or approvals.
Install only if you trust the Pilot daemon, pilotctl binary, and any MCP server wrapper you provide. Before enabling autonomous use, restrict peers, topics, hosts, ports, and gateway mappings; require confirmation for network and gateway actions; and avoid sending secrets unless the Pilot configuration and peer identities are verified.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent using this skill could send messages, listen for traffic, publish to topics, or alter Pilot gateway mappings in ways the user did not specifically review.
The skill gives the agent Bash access to run Pilot commands with user- or peer-controlled parameters and includes gateway mutation commands, but does not define approval, validation, host/port/topic limits, or rollback behavior.
allowed-tools: - Bash ... - `pilot_connect`: Run `pilotctl --json connect <target> <port> --message "<msg>"` ... - `pilot_gateway_start`: Run `pilotctl --json gateway start` - `pilot_gateway_map`: Run `pilotctl --json gateway map <hostname> <local-ip>`
Require explicit user confirmation for send, publish, listen, subscribe, gateway start, and gateway map actions; restrict allowed hosts, ports, topics, and local IPs; and avoid passing untrusted text directly into shell commands.
Sensitive prompts or data could be sent to Pilot peers, and inbound Pilot messages could be mistaken for trustworthy context if the user or agent does not set boundaries.
The core capability is agent-to-agent or peer communication, but the artifact does not document peer identity checks, message trust handling, permitted data classes, topic scoping, or how incoming messages are isolated from agent instructions.
You're building an AI agent that needs to communicate over Pilot ... - `pilot_send_message`: Run `pilotctl --json send-message <target> --data "<msg>"` - `pilot_recv`: Run `pilotctl --json recv <port>` - `pilot_publish`: Run `pilotctl --json publish <target> <topic> --data "<msg>"` - `pilot_subscribe`: Run `pilotctl --json subscribe <target> <topic>`
Use only trusted Pilot peers and topics, do not send secrets through this bridge unless the Pilot configuration is verified, and treat all received messages as untrusted data rather than instructions.
The actual safety of the bridge depends on the pilotctl binary, the referenced server wrapper, and Python MCP library that are obtained outside this reviewed skill.
The reviewed package is instruction-only and references external runtime code and dependencies whose versions and provenance are not included in the artifacts.
python mcp_pilot_server.py ... Requires pilot-protocol skill, pilotctl binary, MCP server framework (Python mcp library), and MCP-compatible client.
Install pilotctl and any MCP server wrapper only from trusted sources, pin dependency versions where possible, and review the server implementation before enabling it.
Network services may continue running after the immediate task if the user does not stop them.
The workflow starts long-running daemon and MCP server processes; this is expected for an MCP bridge, but the artifact does not include stop or cleanup guidance.
# Start Pilot daemon pilotctl --json daemon start --registry 34.71.57.205:9000 --beacon 34.71.57.205:9001 # Start MCP server wrapper python mcp_pilot_server.py
Start the daemon, gateway, and MCP server only when needed, monitor active processes and ports, and document stop commands for cleanup.