@pipeworx/mcp-leadconnector 0.1.0 → 0.1.2

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/LICENSE CHANGED
@@ -1,6 +1,6 @@
1
1
  MIT License
2
2
 
3
- Copyright (c) 2026 Pipeworx
3
+ Copyright (c) 2026 Mojibake Inc.
4
4
 
5
5
  Permission is hereby granted, free of charge, to any person obtaining a copy
6
6
  of this software and associated documentation files (the "Software"), to deal
package/README.md CHANGED
@@ -2,12 +2,17 @@
2
2
 
3
3
  LeadConnector / GoHighLevel MCP Pack — wraps the GoHighLevel CRM for AI agents.
4
4
 
5
- Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 250+ live data sources.
5
+ Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 1683+ live data sources.
6
6
 
7
7
  ## Tools
8
8
 
9
9
  | Tool | Description |
10
10
  |------|-------------|
11
+ | `leadconnector_list_contacts` | Search or list CRM contacts in a GoHighLevel/LeadConnector account. Free-text query matches name, email, or phone. Returns a {contacts:[...], meta} envelope with contact IDs, names, emails, phones, tags, and custom fields. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token). |
12
+ | `leadconnector_get_contact` | Fetch a single CRM contact by its contact ID. Returns full detail: name, email, phone, tags, source, custom fields, and timestamps. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token). |
13
+ | `leadconnector_list_pipelines` | List all sales pipelines and their stages in the account. Returns a {pipelines:[...]} envelope with pipeline IDs, names, and ordered stages. Use the returned pipeline ID with leadconnector_list_opportunities. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token). |
14
+ | `leadconnector_list_opportunities` | List opportunities (pipeline deals) for a given pipeline. Requires a pipelineId (get one from leadconnector_list_pipelines). Returns deals with monetary value, stage, status, and the associated contact. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token). |
15
+ | `leadconnector_list_campaigns` | List marketing/automation campaigns in the account. Returns a {campaigns:[...]} envelope with campaign IDs, names, and status. Useful for finding a campaign to attribute or enroll contacts. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token). |
11
16
 
12
17
  ## Quick Start
13
18
 
@@ -23,7 +28,25 @@ Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):
23
28
  }
24
29
  ```
25
30
 
26
- Or connect to the full Pipeworx gateway for access to all 250+ data sources:
31
+ ### What this endpoint actually serves
32
+
33
+ `tools/list` at `https://gateway.pipeworx.io/leadconnector/mcp` returns the tools in the table
34
+ above **plus the shared Pipeworx meta-tools** — `ask_pipeworx`,
35
+ `discover_tools`, `search_within`, `remember`/`recall` and the rest of the
36
+ gateway-wide set. So the tool count you see is larger than this table: a
37
+ single-pack endpoint currently lists roughly 30 shared tools alongside the
38
+ pack's own. The connection's `initialize` response states its exact scope, and
39
+ is the authoritative answer for a given day.
40
+
41
+ This is deliberate, not multiplexing by accident. The meta-tools are what let a
42
+ scoped connection answer a question this pack does not cover — via
43
+ `ask_pipeworx`, which routes across the whole catalog — without you adding a
44
+ second MCP server. There is currently no way to mount a pack endpoint without
45
+ them; if the extra schemas cost you more context than the routing is worth,
46
+ connect to the full gateway once rather than to several pack endpoints.
47
+
48
+ Or connect to the full Pipeworx gateway to get every pack's tools listed
49
+ directly, instead of just this one's:
27
50
 
28
51
  ```json
29
52
  {
@@ -35,9 +58,44 @@ Or connect to the full Pipeworx gateway for access to all 250+ data sources:
35
58
  }
36
59
  ```
37
60
 
61
+ Both URLs reach the same gateway and the same 1683+ data sources. The
62
+ only difference is which pack's tools are listed **directly**; `ask_pipeworx`
63
+ reaches all of them from either one.
64
+
65
+ ## No MCP client? Call it over HTTP
66
+
67
+ This pack takes your own API key (`_apiKey`) — we don't front one for it, so there's no curl here that would run without it. Inspect any tool: `GET https://gateway.pipeworx.io/v1/tools/leadconnector_list_contacts`. Find one: `POST https://gateway.pipeworx.io/v1/tools/search_packs` with `{"query":"..."}`.
68
+
69
+ ## Standalone (no gateway account)
70
+
71
+ This package also runs as a local stdio MCP server — no Pipeworx account, no
72
+ gateway round-trip:
73
+
74
+ ```json
75
+ {
76
+ "mcpServers": {
77
+ "leadconnector": {
78
+ "command": "npx",
79
+ "args": ["-y", "@pipeworx/mcp-leadconnector"]
80
+ }
81
+ }
82
+ }
83
+ ```
84
+
85
+ Or run it directly to confirm it starts:
86
+
87
+ ```bash
88
+ npx -y @pipeworx/mcp-leadconnector
89
+ ```
90
+
91
+ It speaks MCP over stdin/stdout and answers `initialize`/`tools/list`/`tools/call`
92
+ for **only** this pack's tools — none of the shared meta-tools the gateway
93
+ connection above adds. Same source, same tools, no ask_pipeworx routing.
94
+
38
95
  ## Using with ask_pipeworx
39
96
 
40
- Instead of calling tools directly, you can ask questions in plain English:
97
+ Instead of calling tools directly, you can ask questions in plain English —
98
+ this works on the pack endpoint above as well as on the full gateway:
41
99
 
42
100
  ```
43
101
  ask_pipeworx({ question: "your question about Leadconnector data" })
@@ -47,7 +105,7 @@ The gateway picks the right tool and fills the arguments automatically.
47
105
 
48
106
  ## More
49
107
 
50
- - [All tools and guides](https://github.com/pipeworx-io/examples)
108
+ - [Docs and guides](https://pipeworx.io/docs)
51
109
  - [pipeworx.io](https://pipeworx.io)
52
110
 
53
111
  ## License
package/bin/cli.js ADDED
@@ -0,0 +1,17 @@
1
+ #!/usr/bin/env node
2
+ //
3
+ // Entry point for `npx @pipeworx/mcp-<slug>`.
4
+ //
5
+ // Packs ship as raw TypeScript (no build step — see publish-pack.sh for why:
6
+ // tsx sidesteps every extensionless-import / bare-JSON-import edge case a
7
+ // per-pack tsc build would have to solve one pack at a time). This file
8
+ // registers tsx's ESM loader programmatically, then hands off to src/server.ts,
9
+ // which wraps the pack's {tools, callTool} export in a stdio MCP server.
10
+ //
11
+ // Copied verbatim into every published pack repo by scripts/publish-pack.sh —
12
+ // edit this file, not a per-pack copy.
13
+ import { register } from 'tsx/esm/api';
14
+
15
+ register();
16
+
17
+ await import('../src/server.ts');
package/package.json CHANGED
@@ -1,20 +1,32 @@
1
1
  {
2
2
  "name": "@pipeworx/mcp-leadconnector",
3
- "version": "0.1.0",
3
+ "version": "0.1.2",
4
4
  "description": "LeadConnector / GoHighLevel MCP Pack — wraps the GoHighLevel CRM for AI agents.",
5
5
  "type": "module",
6
6
  "main": "src/index.ts",
7
7
  "types": "src/index.ts",
8
+ "bin": {
9
+ "mcp-leadconnector": "bin/cli.js"
10
+ },
8
11
  "keywords": ["mcp", "mcp-server", "model-context-protocol", "pipeworx", "leadconnector"],
9
12
  "license": "MIT",
10
13
  "repository": {
11
14
  "type": "git",
12
- "url": "https://github.com/pipeworx-io/mcp-leadconnector"
15
+ "url": "git+https://github.com/pipeworx-io/mcp-leadconnector.git"
13
16
  },
14
17
  "scripts": {
15
18
  "typecheck": "tsc --noEmit"
16
19
  },
20
+ "dependencies": {
21
+ "@modelcontextprotocol/sdk": "^1.30.0",
22
+ "tsx": "^4.19.0"
23
+ },
17
24
  "devDependencies": {
18
- "typescript": "^5.7.0"
25
+ "typescript": "^5.9.3",
26
+ "@cloudflare/workers-types": "^4.20260405.1"
27
+ },
28
+ "pipeworx": {
29
+ "sourceHash": "v1-4c469db68ded0b08475a65067c35b6b71e482057b977a280d7d39d6edb483149",
30
+ "sourceCommit": "1064560fd9dcd0d6fc2606298c2ba244b3a1fbeb"
19
31
  }
20
32
  }
package/server.json CHANGED
@@ -3,7 +3,7 @@
3
3
  "name": "io.github.pipeworx-io/leadconnector",
4
4
  "title": "Leadconnector",
5
5
  "description": "LeadConnector / GoHighLevel MCP Pack — wraps the GoHighLevel CRM for AI agents.",
6
- "version": "0.1.0",
6
+ "version": "0.1.2",
7
7
  "websiteUrl": "https://pipeworx.io/packs/leadconnector",
8
8
  "repository": {
9
9
  "url": "https://github.com/pipeworx-io/mcp-leadconnector",
package/src/index.ts CHANGED
@@ -1,11 +1,19 @@
1
1
  interface McpToolDefinition {
2
2
  name: string;
3
3
  description: string;
4
+ /** Human-facing one-liner (fleet #1967). Optional; consumers fall back to
5
+ * description. Kept in step with shared/src/types.ts — scripts/lib/
6
+ * check-inlined-types.mjs reports drift at publish time. */
7
+ summary?: string;
4
8
  inputSchema: {
5
9
  type: 'object';
6
10
  properties: Record<string, unknown>;
7
11
  required?: string[];
12
+ anyOf?: Array<{ required: string[] }>;
13
+ oneOf?: Array<{ required: string[] }>;
14
+ allOf?: Array<{ required: string[] }>;
8
15
  };
16
+ outputSchema?: Record<string, unknown>;
9
17
  }
10
18
 
11
19
  interface McpToolExport {
@@ -16,15 +24,666 @@ interface McpToolExport {
16
24
  provider?: string;
17
25
  }
18
26
 
27
+ /**
28
+ * Was this failure OUR OWN web service? — the other half of `internal-db-class.ts`.
29
+ *
30
+ * fleet #1089 pulled failures from our own Postgres out of `upstream_down` by
31
+ * keying on the SQLSTATE inside PostgREST's four-key error envelope. That
32
+ * covered the majority and structurally could not cover the rest: the rest
33
+ * never reach Postgres, so they carry no SQLSTATE. What was left, measured over
34
+ * the 24h to 2026-09-02T15:00Z (fleet #1096):
35
+ *
36
+ * 5 pipeworx-catalog get_pack_tools Pipeworx catalog error: 522 — error code: 522
37
+ * 3 fleet fleet_list_open … upstream_down: Fleet task queue did not respond within 25s
38
+ *
39
+ * 521/522/523/526 are Cloudflare saying its edge could not reach an ORIGIN, and
40
+ * in both of those rows the origin is ours — `gateway.pipeworx.io` for the
41
+ * catalog pack (it self-fetches when the gateway hasn't injected a manifest),
42
+ * our own Supabase for fleet. There is no third party anywhere in either call.
43
+ * Same defect as #1089: our own outage filed under `upstream_down`, the one
44
+ * class that means "the source is unreachable and there is nothing for us to
45
+ * fix", which is why the problem-tools triage skips it.
46
+ *
47
+ * WHY NOT A WORDING RULE. The obvious fix is to match `fleet db error:` and
48
+ * `Pipeworx catalog error:` in classifyToolError. Each is emitted from exactly
49
+ * one site today, so it would work today. It would also rot the first time
50
+ * somebody rewords a label — silently, and in the direction of hiding our own
51
+ * outage, which is worse than the bug being fixed. Every prose rule in
52
+ * error-class.ts has needed widening as packs invented new wording (#409/#450/
53
+ * #584); that history is most of that file's comment budget.
54
+ *
55
+ * WHAT THIS KEYS ON INSTEAD: **the host the call actually reached.** A URL's
56
+ * hostname is a fact about the call, not a guess about its prose. Two
57
+ * consequences that a pack-level flag could not give us, and the reason the
58
+ * flag was rejected:
59
+ *
60
+ * - It describes the CALL, not the pack. `govcon-intel` fans out to our own
61
+ * Supabase AND to genuine third parties; `court-listener` holds our cache
62
+ * in Supabase and fetches courtlistener.com. An `internallyHosted: true` on
63
+ * either pack would relabel a real third-party outage as ours — inventing
64
+ * work, which is the same class of error in the opposite direction.
65
+ * - It covers every future internal pack for free, instead of one declared
66
+ * slug at a time.
67
+ *
68
+ * WHY IT SURVIVES A REWORD. The marker below is not matched as a literal by two
69
+ * separate files. `markInternalOrigin()` writes it and `internalHostMetricsClass()`
70
+ * reads it, both from the single exported `INTERNAL_ORIGIN_MARKER` constant in
71
+ * this module — so changing the wording changes both sides in the same edit and
72
+ * cannot desynchronise them. The pack's own label (`fleet db error:`,
73
+ * `Pipeworx catalog error:`) is not read at all: reword it freely, the class is
74
+ * unaffected. That is the property `stripClassPrefix` lacked when it drifted
75
+ * from its own classifier three times and needed a CI gate to hold them
76
+ * together.
77
+ *
78
+ * WHERE THE 5xx TEST LIVES. `markInternalOrigin` is called from the places that
79
+ * hold the real `Response` — `httpError`/`httpErrorMessage` and the timeout
80
+ * branch of `fetchWithTimeout` in `shared/src/http.ts` — so "is this an
81
+ * availability failure" is decided from the actual status code, never re-derived
82
+ * by scraping a number out of a sentence. A 404 from our own registry for a slug
83
+ * that does not exist is a caller's bad argument and is deliberately NOT marked.
84
+ */
85
+
86
+ /**
87
+ * OUR OWN web service was unreachable — not an upstream, and never `upstream_down`.
88
+ *
89
+ * ONE value, not three, unlike `internal_db_*`. That split existed because a
90
+ * slow query, an exhausted pool and an unknown SQLSTATE have different owners
91
+ * and different fixes. Here there is only one story to tell — an origin we run
92
+ * did not answer the edge — and one owner. A bucket with no distinct owner per
93
+ * value is decoration; #724 is what happens when a class holds several
94
+ * situations, and inventing sub-values ahead of a reason to act on them
95
+ * differently is the same mistake with the sign flipped.
96
+ *
97
+ * METRICS ONLY, exactly like PLATFORM_KEY_ERROR_CLASS and the internal_db
98
+ * values. `classifyToolError` still answers `upstream_down` for the retry and
99
+ * hint paths, which only care whether retrying or a sibling tool might work —
100
+ * and it might. Nothing a caller sees or is charged changes here.
101
+ *
102
+ * READ SIDE: this value is in BROKEN_TOOL_CLASSES, FAULT_CLASSES and
103
+ * ALL_ERROR_CLASSES in `workers/registry-api/src/index.ts`. All three, or it
104
+ * lands on no dashboard — fleet #721 is the warning, where the #719 split
105
+ * worked on the write side and was invisible for weeks.
106
+ */
107
+ const INTERNAL_SERVICE_UNREACHABLE_CLASS = 'internal_service_unreachable';
108
+
109
+ /**
110
+ * The token that carries "this origin is ours" from the call site to the
111
+ * classifier.
112
+ *
113
+ * Appended to the error message rather than attached to the Error object,
114
+ * because the object does not survive the trip: 275 packs return `{ error:
115
+ * string }` instead of throwing, the gateway reads `observedError` as a string,
116
+ * and the fleet pack rebuilds its error from a captured status + body across a
117
+ * retry loop. A property on an Error would be dropped by every one of those
118
+ * paths and the class would work in tests and vanish in production.
119
+ *
120
+ * WORDING IS LOAD-BEARING, same rule as labelAge's note in authority.ts. This
121
+ * string is appended to a pack's thrown Error message (shared/src/http.ts),
122
+ * and a thrown Error's message is exactly what the gateway hands back to the
123
+ * caller as `content[0].text` when nothing rewrites it (workers/gateway/src
124
+ * catches the throw and sets `rawResult.message = stripClassPrefix(error)`,
125
+ * which does not touch this suffix) — so the original wording,
126
+ * " [pipeworx-hosted origin — our own service, not a third party]", was not a
127
+ * theoretical leak: it shipped live on pipeworx-catalog's 522s, 7 times in 6
128
+ * hours on 2026-09-02 (see tests/golden-internal-service.test.ts), verbatim
129
+ * naming Pipeworx as the host. check:hosting-claims never caught it because it
130
+ * did not scan shared/ at all (task #2009). Reworded to describe the
131
+ * OBSERVATION (the origin did not answer) without a claim about who runs it —
132
+ * the identical fix labelAge got: drop the possessive, keep the fact.
133
+ */
134
+ const INTERNAL_ORIGIN_MARKER = ' [origin did not respond — retry before concluding the named source is down]';
135
+
136
+ /**
137
+ * Supabase's data plane for a project is `<ref>.supabase.co`, where the ref is
138
+ * exactly twenty lowercase letters (ours is `pqauisounztsgdgfkhke`).
139
+ *
140
+ * Matching the shape rather than listing the ref keeps this correct when we add
141
+ * a project — `supabaseEnv` on a pack entry already points some packs at a
142
+ * second one — while still excluding `status.supabase.co`, which is Supabase's
143
+ * own status page and emphatically not our database. Verified 2026-09-02 by
144
+ * `grep -rhoE '[a-z0-9-]+\.supabase\.(co|in)' mcps shared workers scripts`: the
145
+ * only real project ref anywhere in the tree is ours, the rest are doc
146
+ * placeholders (`abc`, `xyz`, `example`) which this pattern also excludes. Same
147
+ * finding internal-db-class.ts relies on for the PostgREST envelope being ours
148
+ * by construction.
149
+ */
150
+ const SUPABASE_PROJECT_HOST = /^[a-z]{20}\.supabase\.(co|in)$/;
151
+
152
+ /**
153
+ * Is this a host WE run?
154
+ *
155
+ * Deliberately NOT including `*.workers.dev`: plenty of third-party APIs are
156
+ * hosted on workers.dev, so the suffix says where something runs and not who
157
+ * owns it. Every internal call we actually make goes to a `pipeworx.io`
158
+ * hostname or to our Supabase project, both of which are ownership facts.
159
+ *
160
+ * `workers/gateway/src/provenance.ts`'s `OUR_HOSTS` answers the same
161
+ * question and DOES include `workers.dev` — a documented divergence
162
+ * (task #2051), not a bug to converge. That list decides what a response may
163
+ * cite as a data SOURCE, where a false negative (citing our own worker as an
164
+ * external source) is the hosting-disclosure leak this whole file exists to
165
+ * prevent, so it errs broad. This one decides who gets BLAMED for a 5xx in
166
+ * outage metrics read by on-call, where a false positive (crediting our own
167
+ * infra with a third party's outage) hides the real failure, so it errs
168
+ * narrow. Same suffix, opposite direction, because they are never called for
169
+ * the same reason.
170
+ *
171
+ * Returns false on anything unparseable rather than throwing — this runs inside
172
+ * an error path, and an error path that can itself throw turns a diagnosable
173
+ * failure into a mystery.
174
+ */
175
+ function isPipeworxOrigin(url: string | URL | undefined | null): boolean {
176
+ if (!url) return false;
177
+ let host: string;
178
+ try {
179
+ host = new URL(url instanceof URL ? url.href : url).hostname.toLowerCase();
180
+ } catch {
181
+ return false;
182
+ }
183
+ if (host === 'pipeworx.io' || host.endsWith('.pipeworx.io')) return true;
184
+ return SUPABASE_PROJECT_HOST.test(host);
185
+ }
186
+
187
+ /**
188
+ * Append the marker when this failure was OUR origin failing to answer.
189
+ *
190
+ * `status` is the HTTP status when there is one, and omitted for a timeout —
191
+ * where there is no response at all, and "the origin did not answer" is the
192
+ * whole observation. Statuses below 500 are left alone: a 404 from our own
193
+ * registry for a slug that does not exist is the caller's argument, not our
194
+ * outage, and marking it would put ordinary 404s on the incident dashboard.
195
+ *
196
+ * Idempotent, so a message that is wrapped and re-marked on the way up (the
197
+ * fleet pack's retry loop re-throws through two layers) carries the marker once.
198
+ */
199
+ function markInternalOrigin(
200
+ message: string,
201
+ url: string | URL | undefined | null,
202
+ status?: number,
203
+ ): string {
204
+ if (status !== undefined && status < 500) return message;
205
+ if (!isPipeworxOrigin(url)) return message;
206
+ if (message.includes(INTERNAL_ORIGIN_MARKER)) return message;
207
+ return message + INTERNAL_ORIGIN_MARKER;
208
+ }
209
+
210
+ /**
211
+ * Which blob4 value a failure from our own web services books as, or undefined
212
+ * if this is not one.
213
+ *
214
+ * Ordered AFTER `internalDbMetricsClass` at the call site: a PostgREST envelope
215
+ * from our own Supabase is a strictly more specific statement about the same
216
+ * row (which of our services, and why), and the two cannot disagree about
217
+ * whether the failure is ours.
218
+ */
219
+ function internalHostMetricsClass(error: string): string | undefined {
220
+ return error.includes(INTERNAL_ORIGIN_MARKER) ? INTERNAL_SERVICE_UNREACHABLE_CLASS : undefined;
221
+ }
222
+
223
+
224
+ /**
225
+ * One place to turn a failed `fetch` into an error a caller can act on.
226
+ *
227
+ * Nearly every pack was written the same way:
228
+ *
229
+ * if (!res.ok) throw new Error(`Unsplash: ${res.status}`);
230
+ *
231
+ * which discards the response body — and the body is usually where the upstream
232
+ * says what was actually wrong ("**symbol** not found: GBP", "parameter `year`
233
+ * out of range", "unknown taxonomy id"). The caller gets a number, cannot
234
+ * self-correct, and retries the same broken call. A 2026-07-31 sweep found this
235
+ * shape in 481 of 1,400 packs, 47 of them PLATFORM-keyed.
236
+ *
237
+ * It also hides bugs one level down. Two of the first three packs audited had a
238
+ * second defect that only existed because of this line: unsplash's rate-limit
239
+ * branch sat BELOW a catch-all and was unreachable, and bea-gov parsed
240
+ * `BEAAPI.Error.APIErrorDescription` below a `!res.ok` throw that made the
241
+ * parsing dead code for every non-200.
242
+ *
243
+ * DELIBERATELY NOT A CLASSIFIER. It does not add `user_error:` /
244
+ * `upstream_down:` prefixes. Those decide which tier a failure lands in, and the
245
+ * `error` tier is what the daily problem-tools list is built from — it means
246
+ * "Pipeworx has a defect". A 400 is genuinely ambiguous: often a caller's bad
247
+ * argument, but sometimes a query WE built wrong (ted-eu comma-joined its CPV
248
+ * values into something TED rejected, and that bug was found only because it sat
249
+ * in `error`). Blanket-classifying 400s as caller mistakes would have hidden it.
250
+ * A pack that KNOWS which it is should keep saying so explicitly; this helper is
251
+ * for the 481 that say nothing at all.
252
+ */
253
+
254
+ /** Longest upstream explanation we'll pass through. Enough for a real message,
255
+ * short enough that an HTML page or a stack trace can't swamp the error. */
256
+
257
+ const MAX_DETAIL = 300;
258
+
259
+ /**
260
+ * Default bound for `fetchWithTimeout` when a pack doesn't state its own.
261
+ *
262
+ * 25s mirrors the number `epo-ops` landed on after measuring the real failure:
263
+ * a degraded upstream that doesn't error, it just never answers, and a Worker
264
+ * sits in `await fetch()` until ITS OWN execution budget kills the request —
265
+ * which can take minutes, not seconds (epo_ops_search_patents measured 4-8
266
+ * MINUTE hangs before this existed). 25s is short enough that a caller gets a
267
+ * fast, actionable error instead of holding the connection, and long enough
268
+ * that it doesn't false-trip on a merely-slow-but-alive upstream.
269
+ */
270
+ const DEFAULT_FETCH_TIMEOUT_MS = 25_000;
271
+
272
+ /**
273
+ * Read the body of a failed response and fold it into a throwable Error.
274
+ *
275
+ * Usage — note the `await`, which is the one thing that makes this a mechanical
276
+ * change rather than a drop-in:
277
+ *
278
+ * if (!res.ok) throw await httpError(res, 'Unsplash');
279
+ *
280
+ * Safe to call on any non-ok response: a body that is missing, empty, unreadable
281
+ * or HTML degrades to exactly the old `Name: 404` string rather than throwing
282
+ * something new from inside the error path.
283
+ */
284
+ async function httpError(res: Response, name: string): Promise<Error> {
285
+ return new Error(await httpErrorMessage(res, name));
286
+ }
287
+
288
+ /** The message text without constructing an Error — for packs that need to wrap
289
+ * it in their own envelope or add an explicit classification prefix. */
290
+ async function httpErrorMessage(res: Response, name: string): Promise<string> {
291
+ // The one place a 5xx from a host WE run gets stamped as ours. `res.url` is
292
+ // the URL the fetch actually resolved to (after redirects), so this is a fact
293
+ // about the call rather than a guess from the `name` the pack passed in —
294
+ // reword that label freely, the class does not move. See
295
+ // internal-host-class.ts; no-op for every third-party upstream, which is why
296
+ // this touches 481 packs' error text and changes none of it.
297
+ return markInternalOrigin(
298
+ `${name}: ${res.status}${detailSuffix(await readDetail(res))}`,
299
+ res.url,
300
+ res.status,
301
+ );
302
+ }
303
+
304
+ /**
305
+ * Just the upstream's own explanation — no name, no status.
306
+ *
307
+ * For a pack that has already said both in its own sentence. epo-ops reads
308
+ * `EPO rejected this search as too large (HTTP 413) — ${httpErrorMessage(…)}`,
309
+ * which rendered as `… (HTTP 413) — EPO: 413.` once the XML detail was being
310
+ * dropped: the upstream named twice, the status twice, and the one thing EPO
311
+ * actually said ("Not enough characters before truncation character") nowhere
312
+ * (fleet #712). Returns '' when the body carries nothing readable, so a caller
313
+ * can fall back to its own wording.
314
+ */
315
+ async function upstreamDetail(res: Response): Promise<string> {
316
+ return readDetail(res);
317
+ }
318
+
319
+ /**
320
+ * Read a SUCCESSFUL response as JSON, failing loudly when it isn't JSON.
321
+ *
322
+ * `httpError` above only ever runs on `!res.ok`, which leaves the nastier half
323
+ * of the problem unhandled: an upstream that answers **HTTP 200 with an HTML
324
+ * page**. A bot wall, a login redirect, a maintenance interstitial and a CDN
325
+ * error page are all 200s, so `res.ok` is true, and `res.json()` then throws
326
+ * `Unexpected token '<', "<!DOCTYPE "... is not valid JSON`.
327
+ *
328
+ * That string is the problem. It names no upstream, carries no status, and
329
+ * reads like a parser bug in Pipeworx — so it lands in the `error` tier, which
330
+ * means "we have a defect", and the caller is told nothing they can act on.
331
+ * data.govt.nz sat dead behind an Imperva challenge this way and every
332
+ * status-code health check we own reported it green (7889a845). A zero-length
333
+ * body has the same shape: `Unexpected end of JSON input`, seen this week on
334
+ * uk-gazette (83% of external calls) and census.
335
+ *
336
+ * UNLIKE `httpError`, this one DOES classify, and the asymmetry is deliberate.
337
+ * A 400 is genuinely ambiguous — often the caller's bad argument, sometimes a
338
+ * query we built wrong — so blanket-classifying it would hide our own bugs.
339
+ * There is no such ambiguity here: **no argument a caller can pass makes a JSON
340
+ * API return an HTML page.** It is always the upstream, so `upstream_down:` is
341
+ * a statement of fact rather than a guess, and it keeps these out of the
342
+ * problem-tools list where they crowd out real defects.
343
+ *
344
+ * const data = await parseJson<Feed>(res, 'UK Gazette');
345
+ *
346
+ * Call it only after the `!res.ok` check — on a failed response you want
347
+ * `httpError`, which mines the body for the upstream's own explanation.
348
+ */
349
+ async function parseJson<T>(res: Response, name: string): Promise<T> {
350
+ let raw: string;
351
+ try {
352
+ raw = await res.text();
353
+ } catch {
354
+ throw new Error(
355
+ `upstream_down: ${name} returned a body that could not be read (HTTP ${res.status}). ` +
356
+ 'The connection most likely dropped mid-response; retrying is reasonable.',
357
+ );
358
+ }
359
+
360
+ const type = res.headers.get('content-type') ?? 'no content-type';
361
+
362
+ if (!raw.trim()) {
363
+ throw new Error(
364
+ `upstream_down: ${name} answered HTTP ${res.status} with an EMPTY body where JSON was expected (${type}). ` +
365
+ 'Nothing about the request can cause this — it is an upstream fault, and the same call may well work on retry.',
366
+ );
367
+ }
368
+
369
+ // Checked before parsing rather than in the catch, because knowing it is
370
+ // markup is what turns "we failed to parse something" into "they served a
371
+ // web page" — the second is diagnosable, the first is not.
372
+ const head = raw.slice(0, 200).trimStart().toLowerCase();
373
+ if (head.startsWith('<!doctype') || head.startsWith('<html') || head.startsWith('<?xml')) {
374
+ const kind = head.startsWith('<?xml') ? 'an XML document' : 'an HTML page';
375
+ // The summary, not the source. Pasting the first 120 characters of a web
376
+ // page handed the agent `<!DOCTYPE html><html lang="en"…` — the same leak
377
+ // this branch exists to describe (fleet #712).
378
+ throw new Error(
379
+ `upstream_down: ${name} answered HTTP ${res.status} with ${kind} instead of JSON (${type}). ` +
380
+ 'That is typically a bot wall, a login redirect or a maintenance page — it is returned as a SUCCESS, ' +
381
+ `so status-code health checks read it as fine. No argument change will get past it. ` +
382
+ `The page says: ${summarizeErrorBody(raw) || 'nothing readable'}`,
383
+ );
384
+ }
385
+
386
+ try {
387
+ return JSON.parse(raw) as T;
388
+ } catch {
389
+ throw new Error(
390
+ `upstream_down: ${name} answered HTTP ${res.status} with a body that is not valid JSON (${type}). ` +
391
+ `It begins: ${stripMarkup(raw).slice(0, 120) || '(unreadable)'}`,
392
+ );
393
+ }
394
+ }
395
+
396
+ /**
397
+ * `fetch`, but bounded — the fix for a systemic gap found 2026-08-30: a grep
398
+ * audit of every pack's `mcps/*\/src/index.ts` found 1,339 of ~1,500 call
399
+ * `fetch()` with NO timeout guard anywhere in the file. Two of those
400
+ * (epo-ops, statcan) were confirmed live-hanging for 4-8 minutes before this
401
+ * existed — every unguarded call carries the same risk, just unconfirmed.
402
+ *
403
+ * Mirrors the `epoFetch` wrapper `mcps/epo-ops/src/index.ts` shipped first:
404
+ * bound the request with `AbortSignal.timeout`, and on a timeout/abort throw
405
+ * an `upstream_down:` error that names the upstream and the bound rather than
406
+ * letting the raw `TimeoutError`/`AbortError` (which names neither) propagate.
407
+ * `upstream_down:` is deliberate, same reasoning as `parseJson` above — no
408
+ * argument a caller passes can make an upstream hang, so it is always the
409
+ * upstream's fault, and marking it that way keeps a slow API off the
410
+ * problem-tools list where it would crowd out our own defects.
411
+ *
412
+ * Usage — a mechanical swap for a bare `fetch(url, init)`:
413
+ *
414
+ * const res = await fetchWithTimeout(url, init, 'Some API');
415
+ *
416
+ * Pass `timeoutMs` as a fourth argument to override the default for a pack
417
+ * with a known-slower upstream; the label should be the same short name you'd
418
+ * pass to `httpError`/`httpErrorMessage` for that call.
419
+ */
420
+ async function fetchWithTimeout(
421
+ url: string | URL,
422
+ init: RequestInit = {},
423
+ name: string,
424
+ timeoutMs: number = DEFAULT_FETCH_TIMEOUT_MS,
425
+ ): Promise<Response> {
426
+ try {
427
+ return await fetch(url, { ...init, signal: AbortSignal.timeout(timeoutMs) });
428
+ } catch (err) {
429
+ if (err instanceof Error && (err.name === 'TimeoutError' || err.name === 'AbortError')) {
430
+ // States the OBSERVATION (no response in N seconds), not a diagnosis.
431
+ // "appears to be degraded" is an inference about the vendor that we have
432
+ // not checked, and it is wrong in a way that misdirects whoever reads it:
433
+ // a timeout from a Worker can equally mean OUR egress is blocked.
434
+ //
435
+ // Measured today (2026-09-01, fleet #1047): every call to
436
+ // mainnet.base.org failed from the x402 facilitator while the identical
437
+ // request from a laptop returned 200. Base was entirely healthy; the
438
+ // public RPC refuses Cloudflare Worker egress. Had this message fired
439
+ // there it would have blamed Base by name, and the next person would have
440
+ // waited for a vendor outage to clear that did not exist.
441
+ // A timeout has no status to test — there is no response at all — so
442
+ // `markInternalOrigin` is called without one: an origin we run that never
443
+ // answered is an availability failure by definition. This is the half of
444
+ // fleet #1096 with neither a SQLSTATE nor a status code to key on.
445
+ throw new Error(
446
+ markInternalOrigin(
447
+ `upstream_down: ${name} did not respond within ${timeoutMs / 1000}s. ` +
448
+ `That can be ${name} being slow or down, or this environment being unable to reach it ` +
449
+ `(some hosts refuse datacenter/Worker egress) — retry shortly, and check reachability ` +
450
+ `from elsewhere before concluding ${name} is down.`,
451
+ url,
452
+ ),
453
+ );
454
+ }
455
+ // Fleet #2382. Everything that isn't a timeout/abort here is a genuine
456
+ // NETWORK-LEVEL failure — DNS resolution, connection refused, TLS handshake,
457
+ // Cloudflare's own "Network connection lost." — meaning `fetch()` itself
458
+ // threw and no HTTP response of any kind was ever received. Until this fix
459
+ // that raw exception was rethrown VERBATIM: a bare `TypeError: fetch failed`
460
+ // (or the Workers-runtime equivalent) names no upstream, carries no class
461
+ // token, and reads exactly like a defect in OUR code — because it says
462
+ // nothing about the call at all. It landed in `error`, the tier that means
463
+ // "Pipeworx has a defect", for every one of the (at the time of writing)
464
+ // ~470 packs that call this helper directly with no wrapper of their own.
465
+ //
466
+ // `dexscreener` hit this independently (fleet #1579) and fixed it with a
467
+ // bespoke per-pack try/catch around `fetchWithTimeout`. That fix is correct
468
+ // but only covers one pack; every other caller of this shared helper still
469
+ // leaked the raw exception. Moving the same fix HERE — the one place that
470
+ // already carries the timeout case — covers every pack that uses
471
+ // `fetchWithTimeout` without a wrapper, for free, and without widening
472
+ // `classifyToolError`'s regex list: the fix is giving the message a proper
473
+ // `upstream_down:` token at the point the two facts (no response was ever
474
+ // received, and which host we were trying to reach) are actually in hand,
475
+ // not teaching the classifier to guess from prose after the fact.
476
+ //
477
+ // Safe on the same grounds as the timeout branch above: no argument a
478
+ // caller passes can make `fetch()` itself throw a connection-level error,
479
+ // so this is always an availability failure, never a caller mistake. Same
480
+ // `markInternalOrigin` treatment — an origin we run that never answered is
481
+ // still ours, not a third party's outage.
482
+ const raw = err instanceof Error ? err.message : String(err);
483
+ throw new Error(
484
+ markInternalOrigin(
485
+ `upstream_down: could not reach ${name} at all (${raw.slice(0, 160)}). ` +
486
+ `No request reached ${name}, so this says NOTHING about whether the arguments you passed ` +
487
+ 'are valid — do not re-check them on the strength of this error. Retry shortly.',
488
+ url,
489
+ ),
490
+ );
491
+ }
492
+ }
493
+
494
+ function detailSuffix(detail: string): string {
495
+ return detail ? ` — ${detail}` : '';
496
+ }
497
+
498
+ async function readDetail(res: Response): Promise<string> {
499
+ let raw: string;
500
+ try {
501
+ raw = await res.text();
502
+ } catch {
503
+ // Body already consumed, or the connection died mid-read. The status alone
504
+ // is still worth throwing — never let the error path throw its own error.
505
+ return '';
506
+ }
507
+ return summarizeErrorBody(raw);
508
+ }
509
+
510
+ /**
511
+ * Turn ANY error body — JSON, HTML, XML or plain text — into one short phrase
512
+ * that never contains markup.
513
+ *
514
+ * This used to just drop an HTML or XML body on the floor, on the reasoning
515
+ * that markup crowds out the status. That was half right. Dropping it loses the
516
+ * one sentence a caller could have acted on: an `Access Denied` title, an SDMX
517
+ * `<message:Error>` text, an OPS fault string. A 2026-08-30 support sweep
518
+ * measured 13 of 291 caller-facing error rows carrying a raw page or document
519
+ * verbatim, across 11 packs, and in every one of them the useful content —
520
+ * "Access Denied", "Invalid country code", "SCRAPE_TIMEOUT" — was in there,
521
+ * buried in markup the agent had to parse out of a string (fleet #712).
522
+ *
523
+ * So: extract the meaning, discard the markup. The output is passed through
524
+ * `stripMarkup` unconditionally, which is what lets `check:error-body-leak`
525
+ * assert mechanically that no caller-facing message can contain `<?xml`,
526
+ * `<!DOCTYPE` or `<html`.
527
+ */
528
+ function summarizeErrorBody(raw: string): string {
529
+ if (!raw || !raw.trim()) return '';
530
+
531
+ const head = raw.slice(0, 400).trimStart().toLowerCase();
532
+
533
+ // An HTML error page (Cloudflare interstitial, nginx default, a login
534
+ // redirect) says what it is in its <title>, and almost nowhere else.
535
+ if (head.startsWith('<!doctype') || head.startsWith('<html')) {
536
+ const title = htmlTitle(raw);
537
+ return title
538
+ ? `${title} (upstream returned an HTML error page, not an API response)`
539
+ : 'upstream returned an HTML error page, not an API response';
540
+ }
541
+
542
+ // XML fault documents — EPO OPS, SDMX (`<message:Error>`), SOAP faults. The
543
+ // human sentence sits in a child element whose tag name says what it is.
544
+ if (head.startsWith('<?xml') || head.startsWith('<')) {
545
+ const fault = xmlFaultText(raw);
546
+ return fault
547
+ ? `${stripMarkup(fault).slice(0, MAX_DETAIL)} (from the upstream's XML error document)`
548
+ : 'upstream returned an XML error document with no readable message';
549
+ }
550
+
551
+ // Most JSON error bodies bury one human sentence among ids and echoed request
552
+ // params. Prefer that sentence; fall back to the whole body when the shape is
553
+ // unfamiliar, since an unfamiliar shape is exactly when we can least afford to
554
+ // guess wrong and show nothing.
555
+ const fromJson = messageFromJson(raw);
556
+ return stripMarkup(fromJson ?? raw).slice(0, MAX_DETAIL);
557
+ }
558
+
559
+ /** The `<title>` of an HTML error page, or its first `<h1>` — the two places a
560
+ * bot wall, a 502 and an "Access Denied" all state what happened. */
561
+ function htmlTitle(raw: string): string | null {
562
+ const head = raw.slice(0, 4000);
563
+ for (const re of [/<title[^>]*>([\s\S]*?)<\/title>/i, /<h1[^>]*>([\s\S]*?)<\/h1>/i]) {
564
+ const m = re.exec(head);
565
+ const text = m ? stripMarkup(m[1]) : '';
566
+ if (text) return text.slice(0, 160);
567
+ }
568
+ return null;
569
+ }
570
+
571
+ /** Tag names that carry the explanation in an XML fault document, namespace
572
+ * prefix optional (`<message:Error>`, `<com:Text>`, `<faultstring>`). */
573
+ const XML_FAULT_TAG_RE =
574
+ /<(?:[A-Za-z0-9_.-]+:)?(?:text|message|description|faultstring|reason|detail|title|errormessage|error)\b[^>]*>([^<]{2,400})</i;
575
+
576
+ function xmlFaultText(raw: string): string | null {
577
+ const head = raw.slice(0, 8000);
578
+ const tagged = XML_FAULT_TAG_RE.exec(head);
579
+ if (tagged && tagged[1].trim()) return tagged[1];
580
+
581
+ // Nothing conventionally named — take the longest text node instead. A fault
582
+ // document with one sentence in an oddly named element is still readable;
583
+ // returning nothing at all is not.
584
+ let best = '';
585
+ for (const m of head.matchAll(/>([^<>]{8,400})</g)) {
586
+ const text = m[1].trim();
587
+ if (text.length > best.length) best = text;
588
+ }
589
+ return best || null;
590
+ }
591
+
592
+ /**
593
+ * Remove every tag and stray angle bracket, then collapse whitespace.
594
+ *
595
+ * Applied to everything on the way out, including the JSON and plain-text
596
+ * paths, because an upstream is free to embed markup in a JSON string field —
597
+ * and a leak is a leak regardless of which branch produced it.
598
+ */
599
+ function stripMarkup(s: string): string {
600
+ return collapse(decodeEntities(s.replace(/<[^>]*>/g, ' ')).replace(/[<>]/g, ' '));
601
+ }
602
+
603
+ /** The handful of entities that show up in error-page titles. Decoded AFTER
604
+ * tags are stripped and BEFORE the angle-bracket sweep, so `&lt;script&gt;`
605
+ * in a title cannot decode into markup that survives — EMBL-EBI's ChEMBL 500
606
+ * page renders as `500 Internal Server Error &lt; EMBL-EBI` otherwise. */
607
+ function decodeEntities(s: string): string {
608
+ return s
609
+ .replace(/&(?:amp|#0*38);/gi, '&')
610
+ .replace(/&(?:lt|#0*60);/gi, '<')
611
+ .replace(/&(?:gt|#0*62);/gi, '>')
612
+ .replace(/&(?:quot|#0*34);/gi, '"')
613
+ .replace(/&(?:#0*39|apos|#x0*27);/gi, "'")
614
+ .replace(/&nbsp;/gi, ' ');
615
+ }
616
+
617
+ /** The conventional "what went wrong" field, under any of the names upstreams
618
+ * actually use. Checked in order; first non-empty string wins. */
619
+ const MESSAGE_KEYS = [
620
+ 'message', 'error_message', 'errorMessage', 'detail', 'details',
621
+ 'description', 'error_description', 'reason', 'title', 'fault',
622
+ ];
623
+
624
+ function messageFromJson(raw: string): string | null {
625
+ let parsed: unknown;
626
+ try {
627
+ parsed = JSON.parse(raw);
628
+ } catch {
629
+ return null;
630
+ }
631
+ return pickMessage(parsed, 0);
632
+ }
633
+
634
+ function pickMessage(node: unknown, depth: number): string | null {
635
+ // Two levels covers `{error: {message}}` and `{errors: [{detail}]}`, the two
636
+ // shapes that account for nearly all of them, without walking a large payload.
637
+ if (depth > 2 || node == null) return null;
638
+
639
+ if (typeof node === 'string') return node.trim() || null;
640
+
641
+ if (Array.isArray(node)) {
642
+ for (const item of node) {
643
+ const found = pickMessage(item, depth + 1);
644
+ if (found) return found;
645
+ }
646
+ return null;
647
+ }
648
+
649
+ if (typeof node !== 'object') return null;
650
+ const obj = node as Record<string, unknown>;
651
+
652
+ for (const key of MESSAGE_KEYS) {
653
+ const v = obj[key];
654
+ if (typeof v === 'string' && v.trim()) return v.trim();
655
+ }
656
+ // `{error: …}` where error is itself an object or a string — the single most
657
+ // common wrapper, so it is worth descending into by name rather than scanning
658
+ // every key and risking picking up an echoed request parameter.
659
+ for (const key of ['error', 'errors', 'fault', 'Error', 'data']) {
660
+ if (key in obj) {
661
+ const found = pickMessage(obj[key], depth + 1);
662
+ if (found) return found;
663
+ }
664
+ }
665
+ return null;
666
+ }
667
+
668
+ /** Errors are read in a single line of log output; newlines and runs of
669
+ * whitespace make a multi-line body unreadable there. */
670
+ function collapse(s: string): string {
671
+ return s.replace(/\s+/g, ' ').trim();
672
+ }
19
673
  /**
20
674
  * LeadConnector / GoHighLevel MCP Pack — wraps the GoHighLevel CRM for AI agents.
21
675
  *
22
- * BYO key: pass _apiKey on every call. This is a GoHighLevel/LeadConnector
23
- * **Location API key** (in the dashboard: Settings → Business Profile → API Key).
24
- * It is a single static bearer token scoped to one Location (sub-account).
676
+ * BYO key: pass _apiKey on every call. TWO token generations are accepted and the
677
+ * pack routes on the prefix — see "TWO TOKEN GENERATIONS" below:
678
+ * - `pit-` → v2 **Private Integration Token** (Settings → Private Integrations).
679
+ * Preferred, and the only one new accounts can create. Requires `locationId`.
680
+ * - anything else → v1 **Location API key** (Settings → Business Profile → API
681
+ * Key), a static bearer scoped to one Location. Still works if you hold one,
682
+ * but GoHighLevel is retiring them.
25
683
  *
26
- * API: GoHighLevel v1 REST API — base https://rest.gohighlevel.com/v1
27
- * Auth: `Authorization: Bearer ${apiKey}`.
684
+ * API: v2 https://services.leadconnectorhq.com (needs `Version: 2021-07-28`)
685
+ * v1 https://rest.gohighlevel.com/v1
686
+ * Auth: `Authorization: Bearer ${apiKey}` on both.
28
687
  * Quirks:
29
688
  * - Collection responses are wrapped, e.g. {contacts:[...], meta:{...}},
30
689
  * {pipelines:[...]}, {campaigns:[...]}.
@@ -34,10 +693,57 @@ interface McpToolExport {
34
693
  * - A missing/invalid key returns HTTP 401 {"msg":"Api key is invalid."}.
35
694
  * - v1 /users/ is deprecated for Location keys (401 "Switch to the new API token"),
36
695
  * so no users tool is exposed.
696
+ *
697
+ * TWO TOKEN GENERATIONS, and v1 cannot tell you which one you have.
698
+ * GoHighLevel now issues v2 **Private Integration Tokens** (`pit-` prefixed) to
699
+ * new accounts, and v1 answers one of those with the SAME generic
700
+ * {"msg":"Api key is invalid."} it gives a typo'd key. Measured 2026-08-27:
701
+ * v1 /pipelines/ + a fake v1 key -> 401 {"msg":"Api key is invalid."}
702
+ * v1 /pipelines/ + a fake pit- key -> 401 {"msg":"Api key is invalid."} <- identical
703
+ * So a caller holding a perfectly valid pit- token gets told their key is bad,
704
+ * which is the one thing it is not. We check the prefix ourselves and say so.
705
+ *
706
+ * v2 lives at https://services.leadconnectorhq.com and needs a `Version:
707
+ * 2021-07-28` header alongside the bearer token (same probe: omit it and v2
708
+ * answers 401 "version header was not found."; include it with a bad token and
709
+ * it answers 401 "Invalid Private Integration token" — i.e. the endpoint and
710
+ * header shape are right, only the token was fake).
711
+ *
712
+ * BOTH GENERATIONS NOW WORK (fleet #1046, 2026-09-01). GoHighLevel has retired
713
+ * v1 key creation, so refusing `pit-` tokens meant refusing every new account.
714
+ * We now pick the generation off the token prefix: `pit-` routes to v2, anything
715
+ * else to v1. v2 is location-scoped in the QUERY STRING rather than in the token,
716
+ * so a `pit-` token must be accompanied by `locationId` — that is not optional
717
+ * and v2 answers a missing one with a 422, so we ask for it up front instead.
718
+ *
719
+ * HONESTY NOTE, because the distinction matters more than the code: the v1 path
720
+ * below was verified against live 401s (see the measured probes above). The v2
721
+ * path is written to the documented v2 contract and is NOT verified against a
722
+ * live `pit-` token — we hold none, and no free tier issues one (GoHighLevel is
723
+ * a paid CRM). What IS verified is the routing: a `pit-` token reaches v2 with
724
+ * the Version header rather than being rejected locally. If a v2 route is wrong,
725
+ * the caller gets GoHighLevel's own error, which is a far better failure than
726
+ * the "Api key is invalid." lie v1 told them.
37
727
  */
38
728
 
39
729
 
730
+ // Bound every fetch() in this pack to a fixed timeout — an upstream that
731
+ // degrades without erroring would otherwise hold the Worker in `await fetch()`
732
+ // until its own execution budget kills the request (minutes, not seconds).
733
+ // Mirrors the epoFetch / usaspending retryFetch pattern (fleet #685).
734
+ async function pwFetch(url: string | URL, init?: RequestInit): Promise<Response> {
735
+ return fetchWithTimeout(url, init ?? {}, 'LeadConnector / GoHighLevel');
736
+ }
737
+
40
738
  const API = 'https://rest.gohighlevel.com/v1';
739
+ const API_V2 = 'https://services.leadconnectorhq.com';
740
+ // v2 rejects any request without this header, before it even looks at the token.
741
+ const V2_VERSION = '2021-07-28';
742
+
743
+ /** A `pit-` prefix is the only thing that distinguishes the two generations. */
744
+ function isV2Token(apiKey: string): boolean {
745
+ return /^pit-/i.test(apiKey.trim());
746
+ }
41
747
 
42
748
  function headers(apiKey: string): Record<string, string> {
43
749
  return {
@@ -47,12 +753,92 @@ function headers(apiKey: string): Record<string, string> {
47
753
  };
48
754
  }
49
755
 
756
+ function headersV2(apiKey: string): Record<string, string> {
757
+ return { ...headers(apiKey), Version: V2_VERSION };
758
+ }
759
+
760
+ // Said in one place because it is the answer to every 401 this pack can produce.
761
+ //
762
+ // Leads with the instruction that WORKS TODAY, and names the token generation,
763
+ // because this pack accepts both and the caller's 401 is nearly always a caller
764
+ // holding the older one. Routing is by prefix: `pit-` -> v2, anything else -> v1.
765
+ //
766
+ // This string used to end "this pack cannot reach your account until we ship v2
767
+ // support", which was true when feedback #102 was filed and became false the day
768
+ // v2 landed (fleet #1046). It survived the rewrite, so the pack shipped v2 while
769
+ // still telling every rejected caller that v2 did not exist — and telling them
770
+ // flatly that a `pit-` token "will not work here", which is the one thing that
771
+ // does. Worst case it aimed a caller at a v1 key GoHighLevel will no longer
772
+ // issue. A refusal is a caller-facing instruction; when the capability changes
773
+ // underneath it, the instruction is part of the change (fleet #797).
774
+ const WRONG_KEY_HELP =
775
+ 'This pack speaks BOTH GoHighLevel APIs and picks by token prefix. Preferred: a v2 ' +
776
+ '**Private Integration Token** (`pit-` prefixed) from Settings → Private Integrations ' +
777
+ 'in the sub-account — pass it as `_apiKey` together with `locationId`, which v2 ' +
778
+ 'requires. Legacy v1 **Location API keys** (the long JWT-style string under Settings → ' +
779
+ 'Business Profile → API Key) still work if you already hold one, but GoHighLevel has ' +
780
+ 'been retiring them and new accounts can no longer create one, so a `pit-` token is ' +
781
+ 'the answer if your dashboard does not offer a v1 key.';
782
+
783
+ /**
784
+ * v1 answers a v2 token with the same "Api key is invalid." it gives a typo, so
785
+ * the caller cannot tell a WRONG KEY from a wrong KIND of key. Catch the shape
786
+ * before spending a request on it.
787
+ *
788
+ * RETURNS an error envelope rather than throwing (fleet #615). A thrown Error
789
+ * lands in the gateway's generic catch block, which stamps `error: 'tool_error'`
790
+ * on EVERY thrown exception regardless of wording — the caller was told this is
791
+ * a Pipeworx defect when it is a BYOK wall one branch away from the pack's own
792
+ * `_apiKey`-missing check, which the gateway itself answers with `auth_required`.
793
+ * Returning the same shape here (and naming `_apiKey` in the message, which is
794
+ * what the gateway's classifier keys on) makes both branches agree.
795
+ */
796
+ function checkV2Location(
797
+ toolName: string,
798
+ apiKey: string,
799
+ locationId: string | undefined,
800
+ ): { error: string; message: string; pack: string } | undefined {
801
+ if (!isV2Token(apiKey) || (locationId ?? '').trim()) return undefined;
802
+ return {
803
+ error: 'auth_required',
804
+ pack: 'leadconnector',
805
+ message: `${toolName} requires an API key AND a locationId when using a v2 Private Integration Token. Your token starts with "pit-", which is v2 — v2 does not carry the sub-account in the token the way a v1 Location key did, so pass \`locationId\` alongside \`_apiKey\`. Find it in the GoHighLevel URL for the sub-account (…/location/<locationId>/…) or under Settings → Business Profile.`,
806
+ };
807
+ }
808
+
809
+ async function lcGetV2(apiKey: string, path: string, params: URLSearchParams): Promise<unknown> {
810
+ const qs = params.toString();
811
+ const url = `${API_V2}${path}${qs ? `?${qs}` : ''}`;
812
+ const res = await pwFetch(url, { headers: headersV2(apiKey) });
813
+ if (!res.ok) {
814
+ const body = await res.text();
815
+ if (res.status === 401) {
816
+ throw new Error(
817
+ `LeadConnector v2 returned 401 — GoHighLevel rejected the Private Integration Token. Check the token is current and that its scopes cover this endpoint. GoHighLevel said: ${summarizeErrorBody(body)}`,
818
+ );
819
+ }
820
+ throw new Error(`LeadConnector v2: ${res.status} ${summarizeErrorBody(body)}`);
821
+ }
822
+ return res.json();
823
+ }
824
+
50
825
  async function lcGet(apiKey: string, path: string, params?: URLSearchParams): Promise<unknown> {
51
826
  const qs = params?.toString();
52
827
  const url = `${API}${path}${qs ? `?${qs}` : ''}`;
53
- const res = await fetch(url, { headers: headers(apiKey) });
828
+ const res = await pwFetch(url, { headers: headers(apiKey) });
54
829
  if (!res.ok) {
55
830
  const body = await res.text();
831
+ if (res.status === 401) {
832
+ // NO `auth_required:` prefix here. `auth_required` joined CLASS_TOKENS
833
+ // 2026-08-29 (fleet #638) so the token IS stripped now — but this file
834
+ // predates that fix, was caught leaking it live, and switched to plain
835
+ // wording instead of trusting the strip. No reason to revert: the 401
836
+ // below is what classifyToolError keys on regardless, and it reads as
837
+ // English either way, so there's nothing to gain by adding the token back.
838
+ throw new Error(
839
+ `LeadConnector returned 401. ${WRONG_KEY_HELP} GoHighLevel said: ${body.slice(0, 120)}`,
840
+ );
841
+ }
56
842
  throw new Error(`LeadConnector: ${res.status} ${body.slice(0, 200)}`);
57
843
  }
58
844
  return res.json();
@@ -64,11 +850,12 @@ const tools: McpToolExport['tools'] = [
64
850
  {
65
851
  name: 'leadconnector_list_contacts',
66
852
  description:
67
- 'Search or list CRM contacts in a GoHighLevel/LeadConnector account. Free-text query matches name, email, or phone. Returns a {contacts:[...], meta} envelope with contact IDs, names, emails, phones, tags, and custom fields.',
853
+ 'Search or list CRM contacts in a GoHighLevel/LeadConnector account. Free-text query matches name, email, or phone. Returns a {contacts:[...], meta} envelope with contact IDs, names, emails, phones, tags, and custom fields. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token).',
68
854
  inputSchema: {
69
855
  type: 'object' as const,
70
856
  properties: {
71
- _apiKey: { type: 'string', description: 'GoHighLevel/LeadConnector Location API key (Settings → Business Profile → API Key)' },
857
+ _apiKey: { type: 'string', description: 'Your own GoHighLevel/LeadConnector token (BYO — Pipeworx does not supply one). Either a v2 Private Integration Token (`pit-` prefixed; Settings → Private Integrations) — pass `locationId` with it — or a legacy v1 Location API key (Settings → Business Profile → API Key). GoHighLevel has retired v1 key creation, so new accounts will have a v2 token.' },
858
+ locationId: { type: 'string', description: 'GoHighLevel sub-account (Location) ID. REQUIRED with a v2 `pit-` token, ignored for a v1 key. It is the id in the dashboard URL: …/location/<locationId>/…' },
72
859
  query: { type: 'string', description: 'Free-text search across contact name, email, and phone' },
73
860
  limit: { type: 'number', description: 'Max contacts to return (default 20, max 100)' },
74
861
  },
@@ -78,11 +865,12 @@ const tools: McpToolExport['tools'] = [
78
865
  {
79
866
  name: 'leadconnector_get_contact',
80
867
  description:
81
- 'Fetch a single CRM contact by its contact ID. Returns full detail: name, email, phone, tags, source, custom fields, and timestamps.',
868
+ 'Fetch a single CRM contact by its contact ID. Returns full detail: name, email, phone, tags, source, custom fields, and timestamps. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token).',
82
869
  inputSchema: {
83
870
  type: 'object' as const,
84
871
  properties: {
85
- _apiKey: { type: 'string', description: 'GoHighLevel/LeadConnector Location API key' },
872
+ _apiKey: { type: 'string', description: 'Your own GoHighLevel/LeadConnector token (BYO — Pipeworx does not supply one). Either a v2 Private Integration Token (`pit-` prefixed; Settings → Private Integrations) — pass `locationId` with it — or a legacy v1 Location API key (Settings → Business Profile → API Key). GoHighLevel has retired v1 key creation, so new accounts will have a v2 token.' },
873
+ locationId: { type: 'string', description: 'GoHighLevel sub-account (Location) ID. REQUIRED with a v2 `pit-` token, ignored for a v1 key. It is the id in the dashboard URL: …/location/<locationId>/…' },
86
874
  contactId: { type: 'string', description: 'GoHighLevel contact ID' },
87
875
  },
88
876
  required: ['_apiKey', 'contactId'],
@@ -91,11 +879,12 @@ const tools: McpToolExport['tools'] = [
91
879
  {
92
880
  name: 'leadconnector_list_pipelines',
93
881
  description:
94
- 'List all sales pipelines and their stages in the account. Returns a {pipelines:[...]} envelope with pipeline IDs, names, and ordered stages. Use the returned pipeline ID with leadconnector_list_opportunities.',
882
+ 'List all sales pipelines and their stages in the account. Returns a {pipelines:[...]} envelope with pipeline IDs, names, and ordered stages. Use the returned pipeline ID with leadconnector_list_opportunities. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token).',
95
883
  inputSchema: {
96
884
  type: 'object' as const,
97
885
  properties: {
98
- _apiKey: { type: 'string', description: 'GoHighLevel/LeadConnector Location API key' },
886
+ _apiKey: { type: 'string', description: 'Your own GoHighLevel/LeadConnector token (BYO — Pipeworx does not supply one). Either a v2 Private Integration Token (`pit-` prefixed; Settings → Private Integrations) — pass `locationId` with it — or a legacy v1 Location API key (Settings → Business Profile → API Key). GoHighLevel has retired v1 key creation, so new accounts will have a v2 token.' },
887
+ locationId: { type: 'string', description: 'GoHighLevel sub-account (Location) ID. REQUIRED with a v2 `pit-` token, ignored for a v1 key. It is the id in the dashboard URL: …/location/<locationId>/…' },
99
888
  },
100
889
  required: ['_apiKey'],
101
890
  },
@@ -103,11 +892,12 @@ const tools: McpToolExport['tools'] = [
103
892
  {
104
893
  name: 'leadconnector_list_opportunities',
105
894
  description:
106
- 'List opportunities (pipeline deals) for a given pipeline. Requires a pipelineId (get one from leadconnector_list_pipelines). Returns deals with monetary value, stage, status, and the associated contact.',
895
+ 'List opportunities (pipeline deals) for a given pipeline. Requires a pipelineId (get one from leadconnector_list_pipelines). Returns deals with monetary value, stage, status, and the associated contact. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token).',
107
896
  inputSchema: {
108
897
  type: 'object' as const,
109
898
  properties: {
110
- _apiKey: { type: 'string', description: 'GoHighLevel/LeadConnector Location API key' },
899
+ _apiKey: { type: 'string', description: 'Your own GoHighLevel/LeadConnector token (BYO — Pipeworx does not supply one). Either a v2 Private Integration Token (`pit-` prefixed; Settings → Private Integrations) — pass `locationId` with it — or a legacy v1 Location API key (Settings → Business Profile → API Key). GoHighLevel has retired v1 key creation, so new accounts will have a v2 token.' },
900
+ locationId: { type: 'string', description: 'GoHighLevel sub-account (Location) ID. REQUIRED with a v2 `pit-` token, ignored for a v1 key. It is the id in the dashboard URL: …/location/<locationId>/…' },
111
901
  pipelineId: { type: 'string', description: 'Pipeline ID to list opportunities for (from leadconnector_list_pipelines)' },
112
902
  limit: { type: 'number', description: 'Max opportunities to return (default 20, max 100)' },
113
903
  },
@@ -117,11 +907,12 @@ const tools: McpToolExport['tools'] = [
117
907
  {
118
908
  name: 'leadconnector_list_campaigns',
119
909
  description:
120
- 'List marketing/automation campaigns in the account. Returns a {campaigns:[...]} envelope with campaign IDs, names, and status. Useful for finding a campaign to attribute or enroll contacts.',
910
+ 'List marketing/automation campaigns in the account. Returns a {campaigns:[...]} envelope with campaign IDs, names, and status. Useful for finding a campaign to attribute or enroll contacts. Requires your own GoHighLevel token via _apiKey (plus locationId for a v2 `pit-` token).',
121
911
  inputSchema: {
122
912
  type: 'object' as const,
123
913
  properties: {
124
- _apiKey: { type: 'string', description: 'GoHighLevel/LeadConnector Location API key' },
914
+ _apiKey: { type: 'string', description: 'Your own GoHighLevel/LeadConnector token (BYO — Pipeworx does not supply one). Either a v2 Private Integration Token (`pit-` prefixed; Settings → Private Integrations) — pass `locationId` with it — or a legacy v1 Location API key (Settings → Business Profile → API Key). GoHighLevel has retired v1 key creation, so new accounts will have a v2 token.' },
915
+ locationId: { type: 'string', description: 'GoHighLevel sub-account (Location) ID. REQUIRED with a v2 `pit-` token, ignored for a v1 key. It is the id in the dashboard URL: …/location/<locationId>/…' },
125
916
  },
126
917
  required: ['_apiKey'],
127
918
  },
@@ -132,10 +923,19 @@ const tools: McpToolExport['tools'] = [
132
923
 
133
924
  async function callTool(name: string, args: Record<string, unknown>): Promise<unknown> {
134
925
  const apiKey = args._apiKey as string | undefined;
926
+ const locationId = typeof args.locationId === 'string' ? args.locationId.trim() : undefined;
135
927
  delete args._context;
136
928
  delete args._apiKey;
137
929
 
138
- if (!apiKey) throw new Error('_apiKey is required for LeadConnector/GoHighLevel API access');
930
+ if (!apiKey) {
931
+ throw new Error(
932
+ `user_error: LeadConnector/GoHighLevel requires an API key. Pass your own token via _apiKey — Pipeworx does not front one for this source, because GoHighLevel is a paid CRM and the token is scoped to YOUR account. ${WRONG_KEY_HELP}`,
933
+ );
934
+ }
935
+ const locErr = checkV2Location(name, apiKey, locationId);
936
+ if (locErr) return locErr;
937
+
938
+ if (isV2Token(apiKey)) return callV2(name, apiKey, locationId as string, args);
139
939
 
140
940
  switch (name) {
141
941
  case 'leadconnector_list_contacts': {
@@ -160,4 +960,40 @@ async function callTool(name: string, args: Record<string, unknown>): Promise<un
160
960
  }
161
961
  }
162
962
 
963
+ /**
964
+ * v2 routes, per the documented 2021-07-28 contract. The shapes differ from v1
965
+ * in two ways that matter: the sub-account travels as a query param instead of
966
+ * being baked into the token, and opportunities are a top-level /search rather
967
+ * than a child of the pipeline.
968
+ */
969
+ async function callV2(
970
+ name: string,
971
+ apiKey: string,
972
+ locationId: string,
973
+ args: Record<string, unknown>,
974
+ ): Promise<unknown> {
975
+ switch (name) {
976
+ case 'leadconnector_list_contacts': {
977
+ const params = new URLSearchParams({ locationId });
978
+ if (args.query) params.set('query', String(args.query));
979
+ params.set('limit', String(Math.min(100, Number(args.limit) || 20)));
980
+ return lcGetV2(apiKey, '/contacts/', params);
981
+ }
982
+ case 'leadconnector_get_contact':
983
+ return lcGetV2(apiKey, `/contacts/${encodeURIComponent(String(args.contactId))}`, new URLSearchParams());
984
+ case 'leadconnector_list_pipelines':
985
+ return lcGetV2(apiKey, '/opportunities/pipelines', new URLSearchParams({ locationId }));
986
+ case 'leadconnector_list_opportunities': {
987
+ const params = new URLSearchParams({ location_id: locationId });
988
+ if (args.pipelineId) params.set('pipelineId', String(args.pipelineId));
989
+ params.set('limit', String(Math.min(100, Number(args.limit) || 20)));
990
+ return lcGetV2(apiKey, '/opportunities/search', params);
991
+ }
992
+ case 'leadconnector_list_campaigns':
993
+ return lcGetV2(apiKey, '/campaigns/', new URLSearchParams({ locationId }));
994
+ default:
995
+ throw new Error(`Unknown tool: ${name}`);
996
+ }
997
+ }
998
+
163
999
  export default { tools, callTool, meter: { credits: 1 } } satisfies McpToolExport;
package/src/server.ts ADDED
@@ -0,0 +1,45 @@
1
+ /**
2
+ * Stdio MCP server entry point for @pipeworx/mcp-leadconnector.
3
+ * Generated by scripts/publish-pack.sh — do not hand-edit in the pack repo;
4
+ * edit scripts/publish-pack.sh (the server.ts heredoc) and republish instead.
5
+ */
6
+ import { Server } from '@modelcontextprotocol/sdk/server/index.js';
7
+ import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
8
+ import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';
9
+ import pack from './index.js';
10
+
11
+ const server = new Server(
12
+ { name: '@pipeworx/mcp-leadconnector', version: '0.1.2' },
13
+ { capabilities: { tools: {} } },
14
+ );
15
+
16
+ server.setRequestHandler(ListToolsRequestSchema, async () => ({
17
+ tools: pack.tools.map((t) => ({
18
+ name: t.name,
19
+ description: t.description,
20
+ inputSchema: t.inputSchema,
21
+ })),
22
+ }));
23
+
24
+ server.setRequestHandler(CallToolRequestSchema, async (request) => {
25
+ const { name, arguments: args } = request.params;
26
+ try {
27
+ const result = await pack.callTool(name, (args ?? {}) as Record<string, unknown>);
28
+ return { content: [{ type: 'text', text: JSON.stringify(result, null, 2) }] };
29
+ } catch (err) {
30
+ return {
31
+ content: [{ type: 'text', text: err instanceof Error ? err.message : String(err) }],
32
+ isError: true,
33
+ };
34
+ }
35
+ });
36
+
37
+ async function main() {
38
+ const transport = new StdioServerTransport();
39
+ await server.connect(transport);
40
+ }
41
+
42
+ main().catch((err) => {
43
+ console.error('Fatal error running server:', err);
44
+ process.exit(1);
45
+ });
package/tsconfig.json CHANGED
@@ -3,12 +3,16 @@
3
3
  "target": "ES2022",
4
4
  "module": "ESNext",
5
5
  "moduleResolution": "bundler",
6
+ "lib": ["ES2022"],
7
+ "types": ["@cloudflare/workers-types"],
6
8
  "strict": true,
7
9
  "esModuleInterop": true,
8
10
  "skipLibCheck": true,
11
+ "resolveJsonModule": true,
9
12
  "outDir": "dist",
10
13
  "rootDir": "src",
11
14
  "declaration": true
12
15
  },
13
- "include": ["src"]
16
+ "include": ["src"],
17
+ "exclude": ["src/server.ts"]
14
18
  }