@elitedcs/ghl-mcp 3.68.0 → 3.70.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +115 -0
- package/README.md +1 -1
- package/dist/index.js +19002 -17758
- package/package.json +11 -6
- package/skills/blueprint/SKILL.md +1 -0
- package/skills/blueprint/references/intake-question-set.md +1 -1
- package/templates/action-schemas.json +23 -2
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,120 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 3.70.0 — a clean validation now means something
|
|
4
|
+
|
|
5
|
+
A subscriber built an Instagram-comment-to-DM workflow, ran `validate_workflow`, got
|
|
6
|
+
back "0 issues, 0 warnings", published it, and watched the Create/Update Opportunity
|
|
7
|
+
step do nothing: no card in the pipeline, no card on the contact, and the workflow
|
|
8
|
+
carried on to the next step as if it had worked. They were right about why. The step
|
|
9
|
+
had only a pipeline and a stage. GoHighLevel's own documentation lists Opportunity
|
|
10
|
+
Name, Source and Status as mandatory for the combined Create/Update Opportunity step
|
|
11
|
+
to create anything; with only pipeline and stage it moves a card the contact already
|
|
12
|
+
has, and a brand-new lead has none. The
|
|
13
|
+
validator was checking that every id existed. It never asked whether the step could
|
|
14
|
+
do what its name says.
|
|
15
|
+
|
|
16
|
+
**`validate_workflow` and `audit_workflows` now check what a step can do.** A
|
|
17
|
+
Create/Update Opportunity step with only pipeline + stage and no opportunity in
|
|
18
|
+
context comes back as a warning that says exactly that and names the fix. "In
|
|
19
|
+
context" is worked out from the workflow itself: a create step earlier on the same
|
|
20
|
+
path, a Find Opportunity step whose "Opportunity Found" branch the step sits in, or a
|
|
21
|
+
trigger that fires on an opportunity. A step that carries an Opportunity Name and a
|
|
22
|
+
Status is taken as one that creates and is left alone; a Name with no Status is
|
|
23
|
+
reported as unverified with the thing to check. Before release the check ran against
|
|
24
|
+
every workflow in five of our own accounts (106 workflows) and flagged none; the run
|
|
25
|
+
is recorded in `docs/proofs/2026-08-26-validate-runtime-noop.md`. A path the validator
|
|
26
|
+
cannot trace, or a field this version does not know, is reported as unverified rather
|
|
27
|
+
than passed. `warnings_count` now includes these findings, the report says how many
|
|
28
|
+
steps were checked (`actions_checked`), and `audit_workflows` lists them under
|
|
29
|
+
`shape_warnings` with counts in its summary; `status` still flips only on an error,
|
|
30
|
+
never on a warning. A `task_notification` step spelled with the underscore, which
|
|
31
|
+
saves, validates and is skipped at runtime, is that kind of error now.
|
|
32
|
+
|
|
33
|
+
**Claude now builds the right node.** GoHighLevel has separated Create Opportunity
|
|
34
|
+
from Update Opportunity and is phasing the combined action out for new workflows. The
|
|
35
|
+
builder knows the newer Create Opportunity node (`internal_create_opportunity`),
|
|
36
|
+
validates it, normalizes it to the shape proven to create a card, and the reference
|
|
37
|
+
material Claude reads before building a workflow now says which node creates a card
|
|
38
|
+
and which one moves it, instead of pointing both jobs at the same node. (#57)
|
|
39
|
+
|
|
40
|
+
## 3.69.0 — the cockpit hardened, and the plan you approved is the plan that runs
|
|
41
|
+
|
|
42
|
+
Two items in this release exist because someone tried to break the cockpit
|
|
43
|
+
before a customer did.
|
|
44
|
+
|
|
45
|
+
**The cockpit refuses writes it did not ask for.** Command OS runs a small web
|
|
46
|
+
server on your own machine. It only ever listened on 127.0.0.1, which keeps the
|
|
47
|
+
internet out. It did not keep out a web page you happened to have open in another
|
|
48
|
+
tab, which can post to localhost without asking and without showing you anything.
|
|
49
|
+
Every route that changes something now checks three things before it acts: the
|
|
50
|
+
request came to a host we serve, from an origin we serve (or from no browser at
|
|
51
|
+
all), with a JSON body that a foreign page cannot send without a preflight we
|
|
52
|
+
refuse. Tested against the real exploit shapes, including a plain HTML form with
|
|
53
|
+
no JavaScript. (#17)
|
|
54
|
+
|
|
55
|
+
**An approval is a decision, and decisions do not sync inbound.** The shared board
|
|
56
|
+
mirrors a client's progress into their own sub-account so every seat sees the
|
|
57
|
+
same thing. Progress still merges, last write wins. The human approve gate never
|
|
58
|
+
moves because of anything read back from the client's CRM: their staff, a VA, or
|
|
59
|
+
an ordinary "set custom value" workflow step cannot tick your safety checkbox.
|
|
60
|
+
(#29)
|
|
61
|
+
|
|
62
|
+
**Headless installs stopped burning an install slot on every restart.** An
|
|
63
|
+
env-var install with no credentials file minted a fresh device id each boot and
|
|
64
|
+
locked itself out after three. It now keeps a stable id. Existing installs keep
|
|
65
|
+
their slot. (#33)
|
|
66
|
+
|
|
67
|
+
**The plan you approved is the plan that runs.** `apply_build_plan` saves the
|
|
68
|
+
approved plan on execute and a re-run reuses it with `useSavedPlan`; a new plan
|
|
69
|
+
needs `replaceSavedPlan` and operator approval. A differently named plan while
|
|
70
|
+
one is saved is refused, with the two valid moves named. Why: a re-run that
|
|
71
|
+
re-authored the plan created a second pipeline beside the first. The handoff
|
|
72
|
+
compares what was built against the saved plan. (#45, #51, #55)
|
|
73
|
+
|
|
74
|
+
**`verify_funnel` is a write and leaves the free tier.** It submits the funnel's
|
|
75
|
+
form with a test contact and can fire your automations, so it belongs with the
|
|
76
|
+
writes. Free read-only count 112 → 111; the total is still 242 tools across 51
|
|
77
|
+
modules. (#52)
|
|
78
|
+
|
|
79
|
+
**Command OS, from two timed client builds.**
|
|
80
|
+
- Spec sheets and an inspector for every module: promise, routes, writes,
|
|
81
|
+
verification, with an optional `note` on a step and `needs` on a verification.
|
|
82
|
+
The inspector fails a sheet that lies. (#35, #51)
|
|
83
|
+
- A hard tool boundary for headless stage runs: a stage reaches exactly the
|
|
84
|
+
tools it declares, enforced by a computed deny list. The build stage carries
|
|
85
|
+
the plan guide in its prompt and runs on a 25-minute / 40-turn budget. (#45)
|
|
86
|
+
- The review reads intake answers by contact id, tag, or form name, no more
|
|
87
|
+
search-index lag. (#45)
|
|
88
|
+
- An already-open page notices a running stage and a finished stage on its own;
|
|
89
|
+
no manual reload, and a second seat sees the same. The page never refreshes
|
|
90
|
+
while you are typing. (#37, #46)
|
|
91
|
+
- The handoff document is a designed web page with a print-to-PDF view: a client
|
|
92
|
+
copy and an operator copy, complete sentences, your agency's branding, a real
|
|
93
|
+
footer with page numbers, and unconfirmed items are never written as done.
|
|
94
|
+
(#36–#44, #47, #48)
|
|
95
|
+
- Intake: multi-choice questions are checkboxes and save as a list; the
|
|
96
|
+
prefilled form is keyed the way the form reads it (two answers were silently
|
|
97
|
+
dropped before); values a link cannot carry are listed for the operator to set
|
|
98
|
+
by hand. "Is your sending email / domain set up?" is now "Is your sending
|
|
99
|
+
domain set up?" because browser autofill kept filling it with saved addresses;
|
|
100
|
+
existing installs keep the old field. (#51)
|
|
101
|
+
- The verify stage may list funnels first and says plainly that the funnel check
|
|
102
|
+
submits one test contact. The intake stage may rename questions to the
|
|
103
|
+
agency's wording. (#51)
|
|
104
|
+
|
|
105
|
+
The second-build fixes are unit-tested and were live-probed on the sandbox form.
|
|
106
|
+
The third timed build, the proof that they hold together, has not run yet.
|
|
107
|
+
|
|
108
|
+
**Smaller.** `get_courses` called a route GHL does not have, and the workflow
|
|
109
|
+
builder is now actually watched by the health check (#34). The upgrade nudge no
|
|
110
|
+
longer points at an older version than the one you run (#16, #19). Dependencies:
|
|
111
|
+
zod 4, TypeScript 7, dotenv 17 and the Actions bumps, each built and tested
|
|
112
|
+
before merging (#21–#27). CI: the automated checks were made trustworthy (#18);
|
|
113
|
+
the GHL drift canary says plainly when it is not configured and carries the
|
|
114
|
+
server's own reason instead of a guess (#30), and no longer logs a cache-save
|
|
115
|
+
failure it cannot avoid (#32); each canary now has its own licence secrets after
|
|
116
|
+
the two collided (#54).
|
|
117
|
+
|
|
3
118
|
## 3.68.0 — the checkup
|
|
4
119
|
|
|
5
120
|
A subscriber asked the question this release is named after: "I'd love for you to
|
package/README.md
CHANGED
|
@@ -8,7 +8,7 @@ Works with **both the Claude Desktop App and Claude Code terminal** — your cho
|
|
|
8
8
|
|
|
9
9
|
**License required.** Get it at [ghlcommand.com](https://ghlcommand.com?utm_source=npm&utm_medium=readme) — $97/mo, covering UNLIMITED GoHighLevel sub-accounts on up to 3 machines (never billed per account). **30-day time-back guarantee**: save 5+ hours on one client build or your first month back.
|
|
10
10
|
|
|
11
|
-
**Try it FREE (read-only tier).** Grab an instant free key at [ghlcommand.com/free](https://ghlcommand.com/free?utm_source=npm&utm_medium=readme) —
|
|
11
|
+
**Try it FREE (read-only tier).** Grab an instant free key at [ghlcommand.com/free](https://ghlcommand.com/free?utm_source=npm&utm_medium=readme) — 111 read-only tools on your own GHL account once the two-step install is finished (the same install as the paid tier — upgrading later is just a license swap): the account-wide workflow audit (`audit_workflows` finds the silently broken references GHL never warns you about), account health, and every read across contacts, pipelines, funnels, and workflows. Write tools stay visible and answer with upgrade info. Buying later with the same email upgrades your key in place — 1 machine on free, 3 when you upgrade.
|
|
12
12
|
|
|
13
13
|
**How this differs from HighLevel's official MCP.** HighLevel ships an official Anthropic MCP that reads and writes your CRM (contacts, conversations, calendars, opportunities, payments, social) over the public API — it's free and it's good; use it for that. What it *cannot* do, because the public API doesn't expose it: **build or edit workflows, build funnels/landing pages, or build forms.** That's exactly what GHL Command does — the programmatic Workflow Builder, funnel/page builder, form builder, deep workflow cloning, the silent-failure `audit_workflows`, and Blueprint (build a whole client account from one intake — ships as a guided skill that **installs itself automatically** with this package; nothing to download), all on GHL's internal APIs. **Official MCP = read/write your CRM. GHL Command = build and fix it.** They stack fine together.
|
|
14
14
|
|