three.ws Autopilot

@three-ws/autopilot-mcp

An AI agent's own autonomous-execution control plane — set autopilot scopes, a daily SOL spend cap, and auto-execute, then run the propose → execute → undo loop, all from any MCP client.

A Model Context Protocol server that gives an AI agent its own execution control plane over stdio. The agent configures the boundaries it is allowed to act within — capability scopes, a daily SOL spend ceiling, auto-execute and confirmation policy — then drives the full propose → review → execute → undo loop. No human in the loop, but every boundary is enforced server-side: an out-of-scope or over-budget action is denied, never executed.

This is the keystone of the autonomous-agent story. Autopilot config and execution used to live only behind the three.ws UI/API; this server exposes them so an agent can manage its own guardrails and act within them.

⚠️ This server is authenticated and write-heavy. execute_proposal can move real SOL on Solana mainnet and is irreversible. It sends native SOL only — the agent never sells or sends $THREE (it only buys, holds, or burns it). Scopes, the daily SOL spend cap, and confirmation are all enforced on the three.ws backend — this server cannot bypass them.

Install

npm install @three-ws/autopilot-mcp

Or run with npx (no install):

npx @three-ws/autopilot-mcp

Quick start

Claude Code, one line (supply your three.ws credential):

THREE_WS_API_KEY=sk_live_… claude mcp add autopilot -- npx -y @three-ws/autopilot-mcp

Claude Desktop / Cursor (claude_desktop_config.json or mcp.json):

{

"mcpServers": { "autopilot": { "command": "npx", "args": ["-y", "@three-ws/autopilot-mcp"], "env": { "THREE_WS_API_KEY": "sk_live_…" } } } }

Inspect the surface with the MCP Inspector:

THREE_WS_API_KEY=sk_live_… npx -y @modelcontextprotocol/inspector npx @three-ws/autopilot-mcp

Authentication

Every autopilot endpoint is owner-only, so this server is authenticated. Set `THREE_WS_API_KEY` to the agent owner's three.ws credential — either a three.ws API key (sk_live_… / sk_test_…) or an OAuth access token. It is sent as Authorization: Bearer … on every request and identifies the owning user; the agent can only manage agents that user owns. The credential can authorize real SOL transfers via execute_proposal — store it like a password. THREE_WS_TOKEN and THREE_WS_BEARER are accepted as aliases.

Tools

The five read tools reflect live state (proposals, receipts, trust move between calls), so none are idempotent. set_autopilot_config and adjust_proposal are idempotent writes (re-applying the same values is a no-op). generate_proposals, execute_proposal, dismiss_proposal, and undo_action each take a real action.

Input parameters

Every tool takes `agentId` (the UUID of an agent you own) except list_autopilot_activity, where it is optional (omit to aggregate across all your agents).

• `get_autopilot_config` / `compute_trust` / `generate_proposals` — agentId.
• `set_autopilot_config`: agentId, plus any of: enabled (bool), scopes ({ create_alert?, briefing?, wallet_transfer?, trade? }), autoExecute ({ create_alert?, briefing? }), dailySpendSol (number, SOL; 0 disables spending), requireConfirm (bool).
• `list_proposals` — agentId, status (pending | executed | dismissed | undone | failed), limit (1–200).
• `dryrun_proposal` / `dismiss_proposal` / `undo_action` — agentId, proposalId.
• `adjust_proposal` — agentId, proposalId, params (full replacement params for the proposal's kind).
• `execute_proposal` — agentId, proposalId, confirm (bool — required for an irreversible SOL transfer).
• `list_autopilot_activity` — agentId (optional), limit (1–200), cursor (from a prior next_cursor).

The loop

// 1. Grant the agent a reversible capability

// set_autopilot_config

{ "agentId": "…", "enabled": true, "scopes": { "create_alert": true } }

{ "ok": true, "config": { "enabled": true, "scopes": { "create_alert": true, "briefing": false, "wallet_transfer": false, "trade": false }, "daily_spend_sol": 0, "require_confirm": true } }

// 2. Let the agent propose actions from its memory // generate_proposals

{ "agentId": "…" }

{ "ok": true, "createdCount": 1, "source": "memory", "created": [ { "id": "p_…", "kind": "create_alert", "title": "Alert when $THREE crosses $0.01", "rationale": "You noted interest in $THREE around $0.01 — I'll watch it.", "status": "pending" } ] }

// 3. Preview before acting // dryrun_proposal

{ "agentId": "…", "proposalId": "p_…" }

{ "ok": true, "preview": { "kind": "create_alert", "willDo": "Create a real alert rule… Reversible.", "checks": [ { "label": "Scope \"create_alert\" granted", "ok": true } ], "blocked": false } }

// 4. Execute for real (reversible kind — no confirm needed) // execute_proposal

{ "agentId": "…", "proposalId": "p_…" }

{ "ok": true, "receipt": "Created a price above alert.", "actionId": "1843", "proposal": { "status": "executed" } }

// 5. Changed your mind? Undo it. // undo_action

{ "agentId": "…", "proposalId": "p_…" }

{ "ok": true, "proposal": { "status": "undone" } }

Spending real SOL requires the owner to have granted scopes.wallet_transfer, set a positive dailySpendSol, and (unless pre-authorized) execute_proposal must be re-issued with confirm:true. All three are checked server-side. A trade proposal (a buy with SOL or a sell of a non-$THREE token) needs scopes.trade and runs the same wallet guards as the wallet hub. Buys count against dailySpendSol. The agent spends SOL only, it never sells or sends $THREE; a $THREE sell is refused at proposal validation.

Requirements

• Node.js >= 20.
• A three.ws credential (THREE_WS_API_KEY) for the agent owner.
• Network access to https://three.ws (or your own THREE_WS_BASE).

Environment variables

Links

• Homepage: https://three.ws
• Changelog: https://three.ws/changelog
• Issues: https://github.com/nirholas/three.ws/issues
• License: Apache-2.0, see LICENSE

Part of the three.ws SDK suite — 3D AI agents, on-chain identity, and agent payments.

Website · Changelog · GitHub