create_workflow
Create a new reusable, multi-step workflow template for the team, optionally scheduled — but any schedule is CREATED DISABLED and will not fire until someone switches it on in the app. Workflows start as drafts and require an explicit list of allowed tools; activate them with update_workflow once confirmed.
Input Schema
{
"type": "object",
"required": [
"name",
"steps",
"allowed_tools"
],
"properties": {
"name": {
"type": "string",
"description": "Display name for the workflow, shown in the workflow list and passed to the agent that runs it. Required and must be non-empty — a missing or blank value is rejected. `list_workflows` searches on this name, so make it distinctive and confirm the wording with the user first."
},
"tags": {
"description": "Free-form labels for organizing workflows. Must be an array of strings; any other value is ignored and a single blank tag is stored instead. Purely descriptive — listing and search do not filter on tags."
},
"steps": {
"description": "Ordered list of the actions the workflow should perform, handed to the agent as JSON at run time. Required. Write each step so a fresh agent with no conversation history can carry it out without asking follow-up questions."
},
"inputs": {
"description": "Object declaring the values this workflow expects at run time (for example a topic or a date range). It is stored and returned as documentation for callers and for the app UI; the agent itself receives the actual per-run values via `input_values`, not this declaration. Optional — defaults to an empty object."
},
"description": {
"type": "string",
"description": "One or two sentences on what the workflow accomplishes. It is inserted verbatim into the prompt given to the agent that runs the workflow, so write it as orienting context, not marketing copy. Optional — stored as an empty string when omitted."
},
"allowed_tools": {
"description": "REQUIRED, non-empty. Tools the workflow runner may use; an empty list is rejected."
},
"schedule_config": {
"description": "Include only when the user explicitly asks for the workflow to run on a schedule; a non-empty object also creates the schedule, which is left switched OFF until the user enables it in the app. Recognized keys are `frequency` (\"hourly\", \"daily\" or \"weekly\" — anything that is not hourly or weekly is treated as daily) and `interval_hours` (hours between runs, used for hourly frequency and to advance each following run). A `timezone` key is accepted but not used by the scheduler."
}
}
}Output Schema
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"id",
"name",
"status",
"team_id",
"created_at",
"link_url"
],
"properties": {
"id": {
"type": "string",
"format": "uuid",
"description": "Workflow UUID. Use as workflow_id in other workflow tools."
},
"name": {
"type": "string"
},
"tags": {
"type": "array"
},
"steps": {
"type": "array"
},
"inputs": {
"type": "object"
},
"status": {
"enum": [
"draft",
"active",
"archived"
],
"type": "string"
},
"team_id": {
"type": "integer"
},
"link_url": {
"type": "string",
"format": "uri",
"description": "Direct URL to view this workflow in Marcora."
},
"created_at": {
"type": "integer"
},
"updated_at": {
"type": "integer"
},
"description": {
"type": "string"
},
"allowed_tools": {
"type": "array"
},
"created_by_user_id": {
"type": "integer"
}
}
}Instructions
Create a new workflow template for your active team. Workflows start as draft — activate them with update_workflow once the user confirms. Check list_workflows with a search filter for duplicate names first.
Scheduling — the schedule is CREATED DISABLED. Include schedule_config ONLY if the user explicitly wants the workflow scheduled; otherwise omit it and the workflow runs on demand via run_workflow. When you do include it, the accompanying schedule is created switched OFF — it will not fire until someone enables it in the app. Do not tell the user their workflow is now running on a schedule.
Scheduled runs need TWO separate switches, and NEITHER happens here:
- Activate the workflow itself with update_workflow (
status: "active"). - Enable the schedule in the Marcora app.
No MCP tool can enable a schedule. Do NOT try it via update_workflow: it does not error, it SILENTLY IGNORES schedule_config and returns a normal success response, so a schedule you "enabled" that way is still off. Tell the user to turn it on in the app, and say the schedule is off until they do.
Parameters:
- name (string, required): Display name for the workflow, shown in the workflow list and passed to the agent that runs it. Must be non-empty — a missing or blank value is rejected. list_workflows searches on this name, so make it distinctive and confirm the wording with the user first
- description (string, optional): One or two sentences on what the workflow accomplishes. It is inserted verbatim into the prompt given to the agent that runs the workflow, so write it as orienting context, not marketing copy. Stored as an empty string when omitted
- steps (array, required): Ordered list of the actions the workflow should perform, handed to the agent as JSON at run time. Write each step so a fresh agent with no conversation history can carry it out without asking follow-up questions
- allowed_tools (array, required): REQUIRED, non-empty. The exact set of tools the workflow runner is permitted to use. A workflow cannot be created without an explicit allowlist — an empty list would let the runner inherit the full tool set, and is rejected. Prefer tight allowlists, especially for scheduled runs
- inputs (object, optional): Object declaring the values this workflow expects at run time (for example a topic or a date range). It is stored and returned as documentation for callers and for the app UI; the agent itself receives the actual per-run values via input_values, not this declaration. Defaults to an empty object
- tags (string[], optional): Free-form labels for organizing workflows. Must be an array of strings; any other value is ignored. Purely descriptive — listing and search do not filter on tags
- schedule_config (object, optional): Include only when the user explicitly asks for the workflow to run on a schedule. A non-empty object also creates the schedule, which is left switched OFF until the user enables it in the app. Recognized keys are
frequency("hourly", "daily" or "weekly" — anything that is not hourly or weekly is treated as daily) andinterval_hours(hours between runs, used for hourly frequency and to advance each following run). Atimezonekey is accepted but not used by the scheduler
Output: The created workflow object — id, team_id, created_by_user_id, name, description, status (draft), inputs, steps, allowed_tools, tags, created_at, updated_at, link_url. Use id as workflow_id in the other workflow tools.
