Skip to main content
Glama
ampware-io

GHL Workflow MCP

by ampware-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

update_workflow

Destructive

Update an existing GoHighLevel workflow with partial changes to actions, triggers, and settings. Pass only fields to change; preserve existing elements by keeping their IDs.

Instructions

Update an existing workflow with partial changes. Action and trigger types must come from the enums in this schema. Use the then/else scaffold for if_else; verbose three-sibling form also accepted. Pass only fields you want to change. Salvage decisions surface in skippedActions[] and warnings[]. When any HARD drop occurs, status is forced to draft. For field meanings, allowed values and worked examples for every step type, use the GHL Workflow Docs MCP.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew workflow name
statusNoNew workflow status
actionsNoComplete replacement action list. Include existing action IDs to keep them, omit ID for new actions.
timezoneNoWorkflow timezone — use "account" for the location default, or an IANA zone (e.g. "America/Los_Angeles"). Preserved on partial updates.
triggersNoComplete replacement trigger list. Include existing trigger IDs to keep/update them, omit ID for new triggers. Triggers in the workflow whose IDs are not in this array will be DELETED. Pass [] to delete ALL triggers. Omit entirely to leave triggers untouched.
workflowIdYesThe workflow ID to update (from list_workflows)
allowMultipleNoWhen true, the same contact can be enrolled in this workflow multiple times concurrently. Preserved on partial updates.
autoMarkAsReadNoWhen true, conversation messages received during the workflow are auto-marked as read. Preserved on partial updates.
stopOnResponseNoWhen true, pauses workflow execution if a contact responds. Preserved on partial updates.
allowMultipleOpportunityNoWhen true, allows multiple opportunities per contact in this workflow. Preserved on partial updates.
removeContactFromLastStepNoWhen true, contacts are removed from the workflow after completing the final step. Preserved on partial updates.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Goes well beyond the destructiveHint annotation by disclosing salvage behavior (skippedActions[], warnings[]) and a consequential side effect: any HARD drop forces status to draft. The schema also makes clear that omitted trigger IDs are DELETED. It does not mention auth requirements or reversibility, keeping it short of a 5.

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?

Front-loaded with the core action and constraint, then supporting behavior and a docs pointer. Six tight sentences with little waste, though the enum/scaffold sentence is dense and slightly harder to parse.

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 an 11-parameter mutation tool with no output schema, the description helpfully explains where salvage/warning information surfaces and the forced-draft consequence. It also points to external docs for step-type specifics, covering the main gap, though it leaves auth/reversibility unstated.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: enum-sourcing requirement for types, the then/else scaffold for if_else, and the replace-not-merge semantics of the actions/triggers arrays. Minor caveat: it says action types 'must come from the enums in this schema,' yet no enum exists for action type in the schema.

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

Purpose4/5

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

States a specific verb and resource ('Update an existing workflow') and adds the key modifier 'with partial changes,' which tells the agent it is a merge-style operation. It does not, however, contrast itself with the sibling patch_workflow, which an agent could reasonably confuse with partial updates.

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

Usage Guidelines3/5

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

Gives operational guidance ('Pass only fields you want to change') and routes the agent to the GHL Workflow Docs MCP for field-level detail. It never says when to prefer this over patch_workflow or create_workflow, so alternative selection is left to inference.

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