MCP server

Boardwalk exposes a Model Context Protocol server, a peer to the REST API over the same auth and the same org scoping. Point any MCP-aware agent at it and the agent can deploy, manage, and trigger your workflows directly, no shell required. (If you just want your coding agent to drive the CLI, the plugins are the simpler path.)

Connect

The server is a streamable-HTTP MCP endpoint at https://api.boardwalk.sh/mcp/v1, authenticated with a bearer API key. Configure it in your client the same way you add any remote MCP server:

{
  "mcpServers": {
    "boardwalk": {
      "url": "https://api.boardwalk.sh/mcp/v1",
      "headers": { "Authorization": "Bearer bwk_your_key_here" }
    }
  }
}

It shares the REST chain's guardrails: the same per-identity rate limit, and the same org-wide two-factor policy if your org requires it.

Choosing the org

An API key already belongs to one org, so it needs nothing more. A Clerk session token can belong to several, so name the one you mean with an X-Boardwalk-Org header:

"headers": {
  "Authorization": "Bearer <session-token>",
  "X-Boardwalk-Org": "acme"
}

Tools

The server registers these tools, grouped by what they touch:

Tool	What it does
`list_workflows` / `get_workflow`	List the org's workflows, or fetch one with its bundled files.
`create_workflow` / `update_workflow`	Deploy a single-file `source` or a multi-file `files` program (update bumps the version).
`delete_workflow`	Soft-delete a workflow.
`disable_workflow` / `enable_workflow`	Pause every trigger reversibly, then resume.
`trigger_now`	Fire a one-off run, with optional `args` as the trigger input and optional `environment` (name) to pick which environment it runs in.
`create_schedule` / `list_schedules` / `delete_schedule`	Schedule a run later (`at`) or on a recurrence (`cron` / `rate`), optionally against an `environment`; list and cancel schedules.
`list_runs` / `get_run`	List recent runs (filter by status) or read one run's status, error, and owning workflow.
`get_run_output` / `get_run_input`	Read a run's event log (agent text, tool calls, logs, output), or the input it was triggered with.
`cancel_run`	Cancel a run that's still in progress.
`list_artifacts` / `get_artifact_download_url`	List a run's artifacts and mint a signed download URL.
`list_secret_names` / `list_inference_providers`	List secret names and configured providers (never values or keys).
`list_environments` / `list_variables`	List named environments and their non-secret variables (values included; injected into a run's `process.env`). A run/schedule targets an environment by name.
`create_environment` / `delete_environment` / `create_variable` / `delete_variable`	Manage environments and non-secret variables. (Secrets stay write-only via the web UI.)
`list_tools` / `get_balance` / `get_usage`	The built-in tools available to `agent()`; the org's credit balance; and run, token, and compute usage over a window.
`list_audit` / `revoke_api_key`	Read the audit log; revoke a key (the one mutating credential op allowed).

Each tool takes the same arguments as its REST cousin: create_schedule wants exactly one of cron / rate / at; get_artifact_download_url takes an optional ttlSeconds. The MCP client surfaces each tool's full input schema.

What it won't do

Credential-creating operations, writing a secret, minting an API key, wiring an inference provider, are intentionally not available over MCP (or any API key). They are present as explicitly-blocked stubs that point you at the dashboard, because they require a logged-in session, so a token can never escalate its own reach. See Authentication for the same boundary on REST.