API and MCP
Debug a failed run from your editor.
Ask why last night's job failed. The assistant reads that run itself, under your own token, and tells you which node broke. The same routes feed the dashboard your team already watches.
The problem
A failure you find out about tomorrow.
It's the same for the team. Run status sits in dagweave, and the alerting everyone already watches never hears about it.
In your editor
The assistant reads the run itself
Ask what happened, and the assistant pulls the run, the node that failed and the error.
- The assistant runs under your own token. It sees what you can see, and no more.
- Eight of the fourteen only read. The other six start runs or change stored workflows, and only if the token carries the scope for it.
- One POST endpoint and the token you already have. Nothing to stand up, nothing to keep alive.
one JSON-RPC request per POSTtext
dagweave_list_runs the runs, newest first
dagweave_get_run node detail and artifacts
dagweave_get_node_logs what one node printed
dagweave_list_workflows q, label, namespace, folder
dagweave_get_workflow one workflow, as stored
dagweave_list_node_types what a step can be
dagweave_list_audit_events action, actor, outcome, from/to
dagweave_validate_workflow check a draft before it runs
dagweave_create_workflow saves a new one, needs workflows:write
dagweave_update_workflow saves over one, needs workflows:write
dagweave_set_workflow_labels replaces its labels, needs workflows:write
dagweave_delete_workflow removes one, needs workflows:delete
dagweave_run_workflow starts a real run, needs runs:write
dagweave_rerun_run runs a past one again, needs runs:write
handshake and tool list does not touch the rate limit
a tool call the same budget as its HTTP routeYour dashboard
Feed the dashboard your team already watches
Pull run status over HTTP and it lands in the dashboard and the alerting you already run.
- A failed run carries the node that broke and its error on the list row. One call fills in the alert.
- A poller knows when to back off.
bearer token, every v1 routetext
GET /api/v1/runs runs:read
GET /api/v1/runs/{id} runs:read
GET /api/v1/runs/{id}/nodes/{nodeId}/logs runs:logs
POST /api/v1/workflows/{id}/run runs:write
POST /api/v1/runs/{id}/rerun runs:write
GET /api/v1/workflows workflows:read
GET /api/v1/workflows/{id} workflows:read
POST /api/v1/workflows/validate workflows:read
GET /api/v1/node-types workflows:read
POST /api/v1/workflows workflows:write
PUT /api/v1/workflows/{id} workflows:write
PUT /api/v1/workflows/{id}/labels workflows:write
DELETE /api/v1/workflows/{id} workflows:delete
GET /api/v1/audit audit:read
POST /api/v1/mcp a live token, then each tool's own scope
once a request authenticates:
X-RateLimit-Limit / Remaining / Reset, and Retry-After on a 429
a 401, or a 403 across teams, carries none of themBlast radius
A token reads what its owner can read
You want to know the worst case before you hand a token to a dashboard or an assistant. The worst case is a read of what that person could already open in the app.
- Scopes: read runs, read step logs, start runs, read workflows, save workflows, delete workflows, read the audit log. A token gets the ones you tick and nothing else.
- Issued per person. Revoke one and one integration stops, not the team.
- Scoped. A status dashboard gets run status and nothing else.
- A route can't be more permissive than the same button in the app.
tokentext
dwk_... a fixed prefix a scanner can catch
shown once, stored only as a sha256 hash
scopes runs:read, runs:logs, runs:write, workflows:read,
workflows:write, workflows:delete, audit:read
expiry 1 to 730 days, or open until you revoke
revoked dead on the next request, checked live not cached
minting only from a real session, never from a token
offboard the holder leaves the team, the token stopsWire it into your own tools.
dagweave is in early access. Leave an email and we will bring you on as we open it up.