MCP Server

Wardn exposes a Model Context Protocol endpoint so agents and MCP-aware clients can inspect and act on your deployments — within the limits of the API key they hold.

Endpoint

POST {API_URL}/mcp

JSON-RPC 2.0 over HTTP. Authenticate every request with an API key:

x-api-key: wrd_…

The key's scope and ceiling decide which tools appear in tools/list and what each call may touch — a read key on deployment:prod/default never sees restart_deployment outside that namespace.

Connect the CLI

The fastest path is the device flow — it mints a scoped key and stores it in ~/.config/wardn/credentials.json:

wardn mcp login

Your browser opens the device approval page; confirm the code and the CLI finishes sign-in on its own.

Non-interactive environments can store an existing key instead:

wardn mcp login --api-key wrd_…

Login flags:

Mint keys manually under Settings → API Tokens in the platform UI.

wardn mcp status verifies the stored credential; wardn mcp logout removes it.

Connect an MCP client

Stdio clients (Claude Desktop, Cursor, and friends) don't speak HTTP — point them at the CLI's proxy, which forwards stdio JSON-RPC to the endpoint with your stored credentials:

{
  "mcpServers": {
    "wardn": {
      "command": "wardn",
      "args": ["mcp"]
    }
  }
}

Requires wardn on PATH and a completed mcp login. Bare wardn mcp is the proxy — wardn mcp proxy (aliases serve, stdio) is the explicit form.

Calls are rate-limited per credential — MCP_RATE_LIMIT_RPM on the server (default 120 req/min).

Human-in-the-loop actions

Agents can propose privileged actions with propose_remediation. The proposal lands in the Agents → Remediations queue where a human approves or rejects it — approval executes the action under the approver's identity and is audited. API keys can never approve their own proposals.