Plori

Official

Overview Schema Source Related Servers Discussions Admin

Create workflow

create_workflow

Create an empty workflow with a manual, cron, or webhook trigger. Returns its ID and, for webhooks, a public hook URL; add steps later.

Instructions

Create an empty workflow. Returns the new workflow, including its id and — for a webhook trigger — its hook URL. trigger_kind defaults to "manual" (run it on demand with run_workflow); "cron" needs a cron_expr; "webhook" mints a public hook URL. trigger_kind is not read from description: a schedule stated only there leaves the workflow manual. The build can still change it — when the owning agent gives the workflow a schedule or webhook trigger step, trigger_kind and cron_expr follow that step. A new workflow has no steps and cannot run until its owning agent builds them.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	A short name for the workflow.
`agent_id`	No	Optional UUID of one of your agents to own the workflow. That agent is then the one that can build, edit, and run it from a chat; leave it out and the workflow stays unassigned until you set an owner.
`cron_expr`	No	Cron schedule (required when trigger_kind is "cron"), e.g. "0 9 * * *". A 5-field cron or an @daily/@hourly descriptor, evaluated in UTC.
`description`	No	Optional description of what the workflow does. It is prose for the reader; no field is derived from it.
`trigger_kind`	No	Optional trigger: "manual" (default), "cron", or "webhook". The build can change it later: a schedule or webhook trigger step sets it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`engine`	Yes
`status`	Yes
`user_id`	Yes
`agent_id`	Yes
`hook_key`	Yes
`cron_expr`	Yes
`created_at`	Yes
`updated_at`	Yes
`description`	Yes
`notify_pref`	Yes
`next_fire_at`	Yes
`trigger_kind`	Yes
`paused_reason`	No
`template_slug`	No
`active_version`	Yes
`current_version`	Yes
`spend_cap_month`	Yes
`agent_deleted_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.16.0Sep 19, 2026

changedInput schema / properties / cron_expr / description

Previous value: -"Cron schedule (required when trigger_kind is \"cron\"), e.g. \"0 9 * * *\"."New value: +"Cron schedule (required when trigger_kind is \"cron\"), e.g. \"0 9 * * *\". A 5-field cron or an @daily/@hourly descriptor, evaluated in UTC."

changedInput schema / properties / description / description

Previous value: -"Optional description of what the workflow does."New value: +"Optional description of what the workflow does. It is prose for the reader; no field is derived from it."

changedInput schema / properties / trigger_kind / description

Previous value: -"Optional trigger: \"manual\" (default), \"cron\", or \"webhook\"."New value: +"Optional trigger: \"manual\" (default), \"cron\", or \"webhook\". The build can change it later: a schedule or webhook trigger step sets it."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "active_version": {
+      "maximum": 2147483647,
+      "minimum": -2147483648,
+      "type": [
+        "null",
+        "integer"
+      ]
+    },
+    "agent_deleted_at": {
+      "type": [
+        "null",
+        "string"
+      ]
+    },
+    "agent_id": {
+      "type": [
+        "null",
+        "string"
+      ]
+    },
+    "created_at": {
+      "type": "string"
+    },
+    "cron_expr": {
+      "type": "string"
+    },
+    "current_version": {
+      "maximum": 2147483647,
+      "minimum": -2147483648,
+      "type": "integer"
+    },
+    "description": {
+      "type": "string"
+    },
+    "engine": {
+      "type": "string"
+    },
+    "hook_key": {
+      "type": [
+        "null",
+        "string"
+      ]
+    },
+    "id": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "next_fire_at": {
+      "type": [
+        "null",
+        "string"
+      ]
+    },
+    "notify_pref": {
+      "type": "string"
+    },
+    "paused_reason": {
+      "type": "string"
+    },
+    "spend_cap_month": {
+      "type": "integer"
+    },
+    "status": {
+      "type": "string"
+    },
+    "template_slug": {
+      "type": "string"
+    },
+    "trigger_kind": {
+      "type": "string"
+    },
+    "updated_at": {
+      "type": "string"
+    },
+    "user_id": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "user_id",
+    "agent_id",
+    "name",
+    "description",
+    "engine",
+    "status",
+    "current_version",
+    "active_version",
+    "trigger_kind",
+    "cron_expr",
+    "next_fire_at",
+    "hook_key",
+    "spend_cap_month",
+    "notify_pref",
+    "created_at",
+    "updated_at"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.7.0Aug 9, 2026

changedInput schema / properties / agent_id / description

Previous value: -"Optional UUID of one of your agents to record as the workflow's creator."New value: +"Optional UUID of one of your agents to own the workflow. That agent is then the one that can build, edit, and run it from a chat; leave it out and the workflow stays unassigned until you set an owner."

Addedv0.1.1Jul 16, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the write/non-idempotent/non-destructive profile. The description adds real behavioral context: the workflow starts with no steps and cannot run until its owning agent builds them, the trigger_kind/cron_expr can be overridden later by a schedule or webhook step, and a webhook trigger exposes a public hook URL.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and return value are front-loaded, then trigger semantics, then the lifecycle caveat. Every sentence carries a distinct constraint, though the trigger_kind behavior is restated enough that a slight trim would help.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the full picture an agent needs: what is created, the trigger options and their prerequisites, the ownership model, and the fact that a freshly created workflow is inert until built. With an output schema present, return detail is not required, making this complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description goes beyond it by stating the default ('manual'), the cron_expr dependency on trigger_kind='cron', and the non-obvious fact that a schedule written only in the description field is ignored.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create an empty workflow') and immediately qualifies scope with 'empty', plus what it returns. An agent can distinguish it from create_agent or edit_workflow without inspecting either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives conditional guidance for each trigger_kind (manual -> run on demand with run_workflow; cron -> needs cron_expr; webhook -> mints a public hook URL) and warns that trigger_kind is not read from description. It does not explicitly contrast with edit_workflow or set_workflow_agent, so it stops just short of explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.