Onplana

create_workflow

Create a workflow (PRO and above): a trigger event, an optional trigger condition, and a graph of steps, scoped to one project or, with no projectId, org-wide. The workflow is created INACTIVE and this tool cannot activate it; a person turns it on in the app. Same rules as saving a new workflow in the web builder: automation.manage on the project (org MANAGER and above for org-wide), the plan for the trigger, and a graph that would run. Returns the new workflow id and a plain-language readback of what it does. design_workflow_draft can then redesign its steps with AI, and test_run_workflow runs it once against a sample.

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": {
      "name": "<name>",
      "trigger": "<trigger>",
      "graph": "<graph>"
    },
    "name": "create_workflow"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Workflow name, 1 to 160 characters.
`graph`	Yes	The steps: {"startStepId":"s1","steps":{"s1":{"kind":"ACTION","action":{"type":"ADD_COMMENT","value":"Thanks, picked up."},"next":null}}}. kind is ACTION, CONDITION, DELAY, APPROVAL or WEBHOOK; steps link through next (onTrue/onFalse on a CONDITION, onApproved/onRejected on an APPROVAL). Action types: SET_STATUS, SET_PRIORITY, SET_PROGRESS, ADD_COMMENT, APPEND_DESCRIPTION, SEND_NOTIFICATION, SEND_EMAIL, WEBHOOK_CALL, UPDATE_PROJECT_STATUS, SET_PROPOSAL_STAGE, NOTIFY_SPONSOR, NOTIFY_REVIEWERS, ASSIGN_TO, ADD_TAG, REMOVE_TAG, MOVE_TO_SPRINT, MOVE_TO_EPIC, SET_CUSTOM_FIELD, INCREMENT_FIELD.
`maxRuns`	No	Optional cap on the number of runs.
`trigger`	Yes	The event that starts the workflow, and optionally a condition on it.
`schedule`	No	Optional {"cron":"0 9 * * 1","timezone":"Europe/London"}; project workflows only.
`projectId`	No	The project the workflow runs in. Omit for an org-wide workflow.
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare the mutation safety profile (readOnly=false, destructive=false, idempotent=false), so the description carries the real burden and does: the workflow is created INACTIVE and this tool cannot activate it, a human must enable it in the app, and the response includes the new id plus a plain-language readback. That is exactly the kind of side effect and post-condition an agent needs before calling.

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?

Front-loaded with the definition, then the INACTIVE caveat, then the rules, then the return value, then the follow-on tools. Dense but every clause (plan tier, permission, inactive state, readback) carries information an agent would otherwise have to discover by failing a call.

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?

For a 7-parameter tool with a nested graph and no output schema, the description covers what the tool builds, who can call it, what state it leaves the resource in, and what it returns. Nothing material is missing for a correct first invocation.

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

Parameters3/5

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

Schema description coverage is 86% and the schema already spells out the graph shape, action type enum, and projectId omission semantics, so the baseline applies. The description reinforces scope (projectId omitted means org-wide) and the 'graph that would run' validity constraint, but adds no new detail on name limits, maxRuns, schedule cron/timezone, or the trigger condition shape beyond what the schema already provides.

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 a workflow) plus its three-part composition: trigger event, optional condition, and step graph. It also fixes the scope model (one project vs. org-wide when projectId is omitted), which no sibling shares, so the agent can distinguish it from design_workflow_draft or duplicate_workflow immediately.

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?

Explicitly names the prerequisites for use: PRO plan or above, automation.manage on the project, org MANAGER and above for org-wide, and a graph that would actually run. It also routes the agent forward to design_workflow_draft for AI step redesign and test_run_workflow for a single sample run, though it does not name an explicit 'do not use this when...' alternative for creation itself.

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

All Onplana tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.