Plori

Official

Overview Schema Source Related Servers Discussions Admin

Create workflow

create_workflow

Create a new empty workflow with manual, cron, or webhook trigger options. Get the workflow ID and webhook URL to enable automated runs.

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.8/5.0

Behavior5/5

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

Adds substantial non-obvious behavior beyond the annotations: trigger_kind is not derived from the description field, the owning agent's build step can override trigger_kind and cron_expr, and the created workflow cannot run until steps are built. These are exactly the hidden behavioral traits an agent needs.

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

Conciseness5/5

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

Every sentence carries distinct value: purpose, return values, trigger behavior, the description-field gotcha, build mutability, and run-readiness. The most essential scoping statement ('empty workflow') is front-loaded, and there is no redundant filler.

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?

The description fully covers creation semantics, trigger variants, ownership/build constraints, and return values. Since an output schema is present, the response shape does not need to be spelled out here, and no critical operational gap remains.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds meaningful cross-parameter semantics: manual is the default trigger, cron makes cron_expr required, webhook generates a public URL, description is purely prose, and the build can later mutate trigger_kind and cron_expr. This goes well beyond the individual parameter descriptions.

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 clarifies what it returns (new workflow id, hook URL for webhook triggers). It also distinguishes itself from built/runnable workflows by noting a new workflow has no steps and cannot run until built.

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 clear context on when to use it: run_workflow is referenced for manual execution, cron requires cron_expr, webhook mints a public hook URL, and a description-only schedule does not set trigger_kind. It does not explicitly name edit_workflow as the alternative for modifying workflows, so it stops short of full when/when-not guidance.

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