Skip to main content
Glama
ignytehq

plunk-mcp

Official
by ignytehq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add workflow step

plunk_add_workflow_step

Add a workflow step to send email, wait, branch, call a webhook, or update contacts. Create the step before wiring transitions.

Instructions

Purpose: Add a step to a workflow — send an email, wait, branch on a condition, call a webhook, or update the contact.

Not for: Slotting a step between two that are already connected — plunk_insert_workflow_step does that in one call and rewires both sides. A step added here is orphaned until plunk_add_workflow_transition wires it in.

Returns: The created step including its id, needed for transitions.

Use when: Building out what an automation does, one step at a time.

Note: DELAY is capped at 365 days. WEBHOOK url, headers and body interpolate template variables on v0.12+. UPDATE_CONTACT accepts subscriptionAction to change subscription state as part of the step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesWorkflow UUID
nameYes
typeYesStep type. TRIGGER = entry point (auto-created with workflow). SEND_EMAIL = send a templated email. DELAY = wait X time. WAIT_FOR_EVENT = wait for a specific event with timeout. CONDITION = if/else branching. EXIT = early exit. WEBHOOK = call an external URL. UPDATE_CONTACT = update contact fields.
configYesStep-type-specific config. SEND_EMAIL: { templateId, recipient: { type: 'CONTACT' | 'CUSTOM', customEmail? } }. DELAY: { amount, unit: 'minutes'|'hours'|'days' } (max 365 days). WAIT_FOR_EVENT: { eventName, timeout? }. CONDITION: { field, operator, value? } or multi-branch shape. WEBHOOK: { url, method, headers?, body? } — url/headers/body support template variable interpolation (e.g. {{contact.email}}) on v0.12+. UPDATE_CONTACT: { updates?: {...}, subscriptionAction?: 'none'|'subscribe'|'unsubscribe' } — subscriptionAction lets a workflow change subscription state; at least one of updates or subscriptionAction is required.
positionYesUI position (e.g. {x, y})
templateIdNoEmail template UUID, for SEND_EMAIL steps.
autoConnectNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare the safety profile (not read-only, not idempotent, open-world, non-destructive), so the description needn't repeat that. It adds genuinely useful behavior: a step added here is orphaned until plunk_add_workflow_transition wires it in, DELAY is capped at 365 days, and WEBHOOK templating requires v0.12+.

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?

Bold-labeled sections (Purpose, Not for, Returns, Use when, Note) front-load the highest-value routing information with no filler. It is on the longer side, but each section carries distinct content.

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

Completeness4/5

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

For a mutation tool with no output schema, it states the return value ('the created step including its id, needed for transitions'), which is exactly what the next call requires, and flags the orphan-until-transition caveat. Nested-object config depth is largely delegated to the schema, which covers it adequately.

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 71% and the enum/config shapes are well documented in the schema, but the description adds constraints not in the schema, notably the 365-day DELAY cap, the v0.12+ interpolation requirement, and that UPDATE_CONTACT accepts subscriptionAction. It does not cover the autoConnect or position semantics.

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?

The description opens with a specific verb+resource ('Add a step to a workflow') and enumerates the step kinds (email, wait, branch, webhook, update contact). It also explicitly distinguishes itself from plunk_insert_workflow_step, so an agent can separate the two siblings without opening schemas.

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

Usage Guidelines5/5

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

It names a 'Not for' alternative with the exact condition that selects it (inserting between already-connected steps) and states 'Use when' for building out an automation incrementally. Exclusions and alternatives are both explicit.

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

Deploy Server

Other Tools