update_workflow
Partial update of a workflow template: only the keys you send change; everything else is preserved. Call get_workflow first to see the current state, then send the minimal diff.
Fields: workflow_id (UUID, required); name / description / steps / inputs / allowed_tools / tags as partial overrides; status: "active" | "inactive" | "archived" ("archived" is a soft delete).
Only set status: "active" when the user has actually asked for it. A workflow the user has not approved stays Inactive.
This tool cannot edit a schedule, and it fails silently: a schedule or schedule_config field is ignored, no error is raised and you get a normal success response. Editing a schedule, and turning it On or Paused, happen only in the Marcora app; direct the user there.
Two switches, two vocabularies, never mixed. The workflow's status is Active or Inactive. Its schedule, if any, is On or Paused. Never call a schedule "active"/"inactive" or a workflow "paused"/"on". Active does not mean running; it means the workflow is allowed to run. It runs on its own only when it is Active AND its schedule is On. Setting status: "active" does not turn a Paused schedule On; that takes Resume schedule in the app. Setting it Inactive keeps the schedule as it was: a schedule that was On fires again once the workflow is Active.
When this call changes the status, the response carries a next_step stating what will and won't run afterwards, computed from the saved schedule. Follow it and describe the state that exists after this call. After you set it Active, never tell the user it is Inactive or that they still need to activate it.
Present link_url exactly as returned.
What actually runs needs BOTH switches; describe the pair that exists when you finish:
Inactive → nothing runs, by any route (manual runs are refused too).
Active, no schedule → runs only when started manually; never starts by itself.
Active, schedule Paused → manual runs work; it won't run on its schedule until the user turns the schedule on with Resume schedule in the app.
Active, schedule On → runs on its schedule.
Inactive, schedule On → nothing runs until the workflow is set Active.
Usage patterns:
To set Active: {workflow_id: "", status: "active"}.
To set Inactive: {workflow_id: "", status: "inactive"}.
To soft-delete: {workflow_id: "", status: "archived"}.
To rename: call get_workflow first, then send just {workflow_id, name}.
Links: copy link_url character for character. Never retype, shorten, or rebuild a link or the IDs inside it.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"workflow_id": "<workflow_id>"
},
"name": "update_workflow"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New display name for the workflow. Omit it to leave the name as it is — only the keys you send are written. | |
| tags | No | Replacement array of label strings; it overwrites the existing tags. Must be an array — any other value leaves the tags untouched. | |
| steps | No | Replacement ordered list of actions. It overwrites the existing steps outright rather than merging, so start from the list `get_workflow` returned and send the whole intended sequence. Omit it — or send an empty object, which counts as "not provided" — to leave the steps unchanged. | |
| inputs | No | Replacement declaration of the values the workflow expects at run time. It overwrites the previous declaration outright. Omit it to leave it unchanged; note an empty object `{}` is also treated as "not provided" and changes nothing. | |
| status | No | Lifecycle state of the workflow: "active" (allowed to run — required before `run_workflow` will start it or its schedule will fire), "inactive" (nothing runs, by any route; its schedule, if any, is kept exactly as it is) or "archived" (the soft-delete convention; the record is kept but taken out of normal use). Set "active" only once the user has confirmed the steps. Any other value is rejected and nothing is saved — there is no "paused" status: pausing is something a schedule does, and the user does it in the app. | |
| description | No | Replacement description. It is inserted into the prompt given to the agent that runs the workflow, so refresh it whenever the steps change meaningfully. Omit to leave it unchanged. | |
| workflow_id | Yes | UUID of the workflow to update, as returned by `list_workflows`, `create_workflow` or `get_workflow`. Required, and the workflow must belong to the user's current team. Call `get_workflow` first so you can send a minimal change set and know what the current values are. | |
| allowed_tools | No | Replacement list of the tools the workflow's agent is told it may call (an instruction in its prompt, not a separate permission check). It overwrites the existing allowlist, so send the full intended set rather than just additions, and keep it tight for scheduled workflows. Omit it (or send an empty object) to leave the allowlist unchanged. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| name | No | ||
| tags | No | ||
| steps | No | ||
| inputs | No | ||
| status | No | ||
| link_url | No | Direct URL to view this workflow in Marcora. | |
| schedule | No | Present whenever the workflow has a schedule, on every update. Inert context, read back from the saved trigger. | |
| next_step | No | Present ONLY when this call set status to "active" or "inactive". What will and won't run afterwards, across both switches — the workflow's status and its schedule — with the words to use. Follow it in substance. A call that changes anything else (a rename, say) returns no next_step, so nothing asserts a change that did not happen or pushes the user toward a schedule they did not ask about. | |
| updated_at | No | ||
| allowed_tools | No |