@elitedcs/ghl-mcp 3.2.0 → 3.3.1

package/CHANGELOG.md

@@ -1,5 +1,69 @@
 # Changelog
 
+## 3.3.1 — validate_workflow + catalogue in npm package
+
+**174 tools across 37 modules. Bundle: 266.2 KB.**
+
+Two small wins:
+
+### `validate_workflow` tool (NEW)
+Pre-flight ID validation for a deployed workflow. Scans every trigger and action for references to pipelines, pipeline stages, custom fields, users, and other workflows. Verifies each ID exists in the current location. Returns a structured report with `references_scanned`, `issues_count`, and a `findings[]` list naming exactly which action / trigger / field path holds an invalid reference.
+
+This catches the silent-failure bug documented in CLAUDE.md: *"Invalid IDs silently kill all subsequent actions in a workflow."* GHL doesn't surface the error anywhere — actions just stop firing. Run `validate_workflow <workflowId>` after editing, or whenever a workflow stops behaving as expected.
+
+Coverage in this release:
+- Pipeline IDs (in `internal_update_opportunity` actions + trigger conditions)
+- Pipeline Stage IDs (cross-checked against their parent pipeline's stage list)
+- Custom Field IDs (in `update_contact_field` actions)
+- User IDs (in `internal_notification.selectedUser`, `task_notification.assignedTo`, trigger conditions)
+- Workflow IDs (in `remove_from_workflow` actions + trigger `add_to_workflow` actions)
+
+Forms, calendars, and surveys are referenced in trigger conditions for specific trigger types (form_submission, customer_appointment, survey_submission) — those checks are deferred to a later release.
+
+### `templates/trigger-schemas.json` now ships in the npm package
+The 1.1 MB trigger catalogue (57 native + 434 marketplace trigger entries) was previously left out of the published package — buyers running `npx -y @elitedcs/ghl-mcp@latest` didn't receive it. Added to `package.json` `files[]` so installs always include it.
+
+### Files changed
+- `src/tools/validators.ts` — NEW: registerValidatorTools + validate_workflow.
+- `src/tools/index.ts` — wired validators into the registry.
+- `package.json` — added trigger-schemas.json to `files[]`; bumped version; tool count 173 → 174; description updated.
+- README, CLAUDE.md, CHANGELOG — synced.
+
+## 3.3.0 — 100% native trigger coverage
+
+**173 tools across 36 modules. Bundle: 255.4 KB.**
+
+All **57 of 57** native GHL workflow trigger types now have their own typed Zod variant in `WorkflowTriggerSchema`. Claude can discriminate every trigger type by name and read documented field paths where the catalogue captured them.
+
+Field-documentation completeness (per trigger, marked in the schema's `.describe()` so the LLM knows):
+
+- **42 fully documented** — every filter field path captured (e.g., `contact_changed` with 12 fields, `opportunity_decay` with 9, `survey_submission`, `birthday_reminder`, etc.)
+- **4 partial** — some fields captured, others not: `custom_date_reminder`, `inbound_trigger`, `facebook_comment_on_post`, `ig_comment_on_post`. Reads still pass; LLM is told docs are partial.
+- **2 fieldless by design** — `inbound_webhook`, `payment_received` (fire on any event)
+- **9 uncaptured** — typed-but-no-docs: `affiliate_created`, `scheduler_trigger`, `user_log_in`, `order_submission`, `conv_ai_trigger`, `conv_ai_autonomous_trigger`, `custom_object_created`, `custom_object_changed`, `facebook_lead_gen`. Most rarely used. Type discrimination still works; field paths to be backfilled when buyers need them.
+
+### Backfills
+- The 4 originally-typed triggers (contact_tag, appointment, customer_reply, pipeline_stage_updated) had incomplete field lists in v3.2.0. Now enriched with all captured fields. `customer_reply` went from "no fields documented" to `workflow.id, message.type, message.body, contact.tags`.
+
+### Coverage delta
+| State | Typed | Reachable-but-untyped | Total |
+|---|---:|---:|---:|
+| Before v3.1.0 | 4 | 0 (reads crashed) | 57 |
+| v3.1.0 | 4 | 53 | 57 |
+| v3.2.0 | 13 | 44 | 57 |
+| **v3.3.0** | **57** | **0** | **57** |
+
+### Future-proof
+Even though every native trigger has a typed variant now, `UnknownTriggerSchema` is still in the union as the last fallback — if GHL ships a new trigger type, reads will pass through cleanly instead of throwing.
+
+### Verified
+- 57 / 57 typed variants matched their own type literal via runtime z.union parse test
+- A synthetic "future_trigger_ghl_invents" type still passes through via the fallback
+- Build: 255.4 KB (up from 248.4 KB; +7 KB for the 44 new variants)
+
+### Files changed
+- `src/trigger-schemas.ts` — all 57 typed variants + 4 doc-completeness statuses (`documented`, `partial`, `fieldless`, `uncaptured`) so the LLM's expectations match each trigger's reality.
+
 ## 3.2.0 — Deep trigger typing
 
 **173 tools across 36 modules. Bundle: 248.4 KB.**

package/README.md

@@ -1,6 +1,6 @@
 # GHL Command — GoHighLevel MCP Server
 
-**Full GoHighLevel API access for Claude.** 173 tools across 36 modules — manage contacts, conversations, pipelines, calendars, funnels, workflows, invoices, custom objects, webhooks, and more. **Includes full workflow builder, funnel/page editor, form builder, pipeline builder, bulk operations, account export, and workflow cloning** — capabilities no other GHL tool offers.
+**Full GoHighLevel API access for Claude.** 174 tools across 36 modules — manage contacts, conversations, pipelines, calendars, funnels, workflows, invoices, custom objects, webhooks, and more. **Includes full workflow builder, funnel/page editor, form builder, pipeline builder, bulk operations, account export, and workflow cloning** — capabilities no other GHL tool offers.
 
 **Distributed via npm as [`@elitedcs/ghl-mcp`](https://www.npmjs.com/package/@elitedcs/ghl-mcp).** Buyers install with one config block — no git, no Node.js setup, no terminal commands. Updates flow automatically (`npx @latest` re-resolves on every Claude restart).
 
@@ -138,7 +138,7 @@ https://app.gohighlevel.com/v2/location/YOUR_LOCATION_ID/dashboard
 
 ## Enable Workflow Builder (Optional)
 
-The 7 workflow builder tools use GHL'''s internal API and require Firebase credentials. Without them, the other 166 tools work fine — you just won'''t have workflow editing.
+The 8 workflow builder tools use GHL'''s internal API and require Firebase credentials. Without them, the other 166 tools work fine — you just won'''t have workflow editing.
 
 Grab the three values from your GHL browser session, then re-run `setup_ghl_mcp` with them:
 
@@ -167,7 +167,7 @@ Re-run setup_ghl_mcp with workflow builder:
 
 ---
 
-## Tools (173)
+## Tools (174)
 
 ### CRM & Contacts (15 tools)
 
@@ -332,7 +332,7 @@ Re-run setup_ghl_mcp with workflow builder:
 | `get_subscriptions` | List active subscriptions |
 | `get_transactions` | View transaction history |
 
-### Workflow Builder (7 tools) — Internal API
+### Workflow Builder (8 tools) — Internal API
 
 > **This is the flagship feature.** GHL's public API has **zero** workflow write endpoints. These tools use GHL's internal backend API — the same API their own UI calls — reverse-engineered to give Claude full workflow CRUD. No other GHL integration, Zapier connector, or third-party tool can create or edit workflows programmatically. Requires additional Firebase auth setup (see "Enable Workflow Builder" in Quick Start above).
 
@@ -345,12 +345,13 @@ Re-run setup_ghl_mcp with workflow builder:
 | `delete_workflow_full` | Permanently delete a workflow |
 | `publish_workflow` | Publish a draft workflow to make it active |
 | `get_trigger_registry` | Discover GHL's marketplace trigger apps (Zoom, WooCommerce, Shopify, etc.) and their available trigger templates |
+| `validate_workflow` | Pre-flight validation: scans every action and trigger for references to pipelines, stages, custom fields, users, and other workflows; verifies each ID exists. Catches the silent-failure bug where invalid IDs make GHL skip subsequent actions |
 
 **What you can build:** Complete automation sequences — lead nurture drip campaigns, appointment reminder sequences, onboarding flows, re-engagement workflows, internal notification chains. Tell Claude what you want and it builds the workflow action by action.
 
 **Supported action types:** `sms`, `email`, `add_contact_tag`, `remove_contact_tag`, `update_contact_field`, `wait`, `if_else`, `webhook`, `create_opportunity`, `custom_code`, `add_notes`, `internal_notification`, `task-notification`, `remove_from_workflow`, and more.
 
-**Supported trigger types:** All 57 native GHL trigger types read cleanly. **13 are deeply typed** with documented field paths (contact_tag, customer_reply, appointment, pipeline_stage_updated, form_submission, opportunity_created, opportunity_changed, opportunity_status_changed, payment_received, inbound_webhook, mailgun_email_event, note_add, task_added). The other 44 pass through a permissive schema so workflows never fail to read regardless of trigger type. Plus 434 marketplace trigger entries across 85 third-party apps — query them via `get_trigger_registry`.
+**Supported trigger types:** **All 57 native GHL trigger types are deeply typed** with their own Zod variant. 42 have full field-path documentation (`opportunity_*`, `form_submission`, `contact_changed`, `survey_submission`, `birthday_reminder`, `mailgun_email_event`, and 36 others). 4 have partial docs, 2 are fieldless by design, 9 have type-only discrimination pending field-path capture. A permissive fallback handles any future trigger types GHL ships, so reads never crash. Plus 434 marketplace trigger entries across 85 third-party apps — query them via `get_trigger_registry`.
 
 ### Pipeline Builder (5 tools) — Internal API