MCP server

List the use cases you can access — your own plus ones shared with your organization. Each entry has the latest published workflow version as publishedWorkflowId (what runs) and — when an in-progress draft exists — its draftWorkflowId. Edit the draft to change work-in-progress. Also returns name and whether the current version has a UI entry point you can run.

Create a new use case owned by you and start building its workflow from a plain-English description — the architect interprets the description and builds the first version. Returns the new useCaseId plus its workflowId; poll get_architect_status to watch it build. NB: a brand-new workflow stays hidden in listings until the architect's first edit promotes it from 'blank' to 'draft'.

Return a condensed view of a workflow that mirrors the UI's stage cards: workflow header, collectedData keys, and each stage with its components (id, subtype, title, description) plus next-stage links. Sub-workflows are nested the same way.

Create an editable draft of a live (published) workflow so the architect can change it without touching the version users run, and move the architect onto that draft. The architect can answer questions about a live version directly, but an edit fails until you're on a draft — call this, then respond to any pending approval (or instruct_architect with the returned draftWorkflowId). Idempotent: if a draft already exists for the workflow, returns that one instead of creating another. Publish the draft from the UI when you're ready to make it live.

Send a natural-language instruction to the architect agent to inspect or edit a workflow (add/change stages, components, etc.). You can instruct against any version, but edits to a live (published) version fail asking you to create_draft first and instruct on the draft. Returns immediately with a useCaseId — the architect works asynchronously, so you MUST poll get_architect_status with that useCaseId to read its reply and any pendingInteraction (an approval or question you answer with respond_to_architect).

Poll a use case's architect by its useCaseId. Returns the architect's status (running/idle/waiting/error), recentActions (the latest turn's text + tool calls so you can see what the architect did), and any pendingInteraction awaiting your response. An approval with requiresDraft=true would edit a live version — call create_draft before responding, or the edit fails.

Answer whatever the architect is waiting on for a use case (addressed by useCaseId). For an approval, pass approvalId and approved (with optional reason). For an interface tool / question, pass toolCallId (and toolName) plus output (an object holding the answer). Returns immediately — the architect resumes asynchronously, so poll get_architect_status for its next reply or pendingInteraction.

Start an execution of a workflow via its first-stage UI entry point. Returns an executionId immediately; poll get_execution_status for the result. Optionally pass an input message and/or collectedData for the entry point.

Poll a workflow execution by id. Returns its status, the user-visible screens (the same view the user sees in the UI — entry point + interactive forms/questions/confirmations + progress), currentScreenIndex (the screen the user is being asked to fill out, or null if everything is answered), collected data, and a URL to open the execution in the UI to respond.

Read a `malleable://` handle you can access: `fu:<id>` file uploads (chat attachments, workflow files), `to:<id>` stored tool outputs, `ex:<id>/webhook` webhook payloads, and `lm`/`lm:<id>` saved LLM messages. Modes: `raw` returns text contents (images come back inline; other binary files can't be attached over MCP — use `query`); `query` answers a natural-language question about the contents server-side; `grep` searches without returning the whole file; `expression` evaluates a CEL expression over a JSON value (bound to `value`); `tabular-overview`/`tabular-read-range` page through xlsx/CSV sheets.