@pipeworx/mcp-abn-lookup 0.1.0 → 0.1.1

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/README.md CHANGED
@@ -4,7 +4,7 @@ BYOK. Australian Business Register lookup: resolve an ABN or ACN to the register
4
4
  legal entity name, entity type, ABN status, GST registration, address state/postcode,
5
5
  and business names, or search the register by entity/business name.
6
6
 
7
- Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 1558+ live data sources.
7
+ Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 1679+ live data sources.
8
8
 
9
9
  ## Tools
10
10
 
@@ -97,10 +97,14 @@ directly, instead of just this one's:
97
97
  }
98
98
  ```
99
99
 
100
- Both URLs reach the same gateway and the same 1558+ data sources. The
100
+ Both URLs reach the same gateway and the same 1679+ data sources. The
101
101
  only difference is which pack's tools are listed **directly**; `ask_pipeworx`
102
102
  reaches all of them from either one.
103
103
 
104
+ ## No MCP client? Call it over HTTP
105
+
106
+ 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/abn_lookup`. Find one: `POST https://gateway.pipeworx.io/v1/tools/search_packs` with `{"query":"..."}`.
107
+
104
108
  ## Standalone (no gateway account)
105
109
 
106
110
  This package also runs as a local stdio MCP server — no Pipeworx account, no
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@pipeworx/mcp-abn-lookup",
3
- "version": "0.1.0",
3
+ "version": "0.1.1",
4
4
  "description": "ABN Lookup MCP — BYOK wrapper around the Australian Business Register's",
5
5
  "type": "module",
6
6
  "main": "src/index.ts",
@@ -22,6 +22,11 @@
22
22
  "tsx": "^4.19.0"
23
23
  },
24
24
  "devDependencies": {
25
- "typescript": "^5.7.0"
25
+ "typescript": "^5.9.3",
26
+ "@cloudflare/workers-types": "^4.20260405.1"
27
+ },
28
+ "pipeworx": {
29
+ "sourceHash": "v1-ea96701fd499288b722815e689fbcdabee808f2665df1a55dcc9a2d9281b6e1f",
30
+ "sourceCommit": "60f04b68c347e970c6be94a53439d1364061fc06"
26
31
  }
27
32
  }
package/server.json CHANGED
@@ -3,7 +3,7 @@
3
3
  "name": "io.github.pipeworx-io/abn-lookup",
4
4
  "title": "Abn Lookup",
5
5
  "description": "ABN Lookup MCP — BYOK wrapper around the Australian Business Register's",
6
- "version": "0.1.0",
6
+ "version": "0.1.1",
7
7
  "websiteUrl": "https://pipeworx.io/packs/abn-lookup",
8
8
  "repository": {
9
9
  "url": "https://github.com/pipeworx-io/mcp-abn-lookup",
package/src/index.ts CHANGED
@@ -1,6 +1,10 @@
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>;
@@ -20,6 +24,203 @@ interface McpToolExport {
20
24
  provider?: string;
21
25
  }
22
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
+
23
224
  /**
24
225
  * One place to turn a failed `fetch` into an error a caller can act on.
25
226
  *
@@ -434,185 +635,6 @@ function pickMessage(node: unknown, depth: number): string | null {
434
635
  function collapse(s: string): string {
435
636
  return s.replace(/\s+/g, ' ').trim();
436
637
  }
437
-
438
- /**
439
- * Was this failure OUR OWN web service? — the other half of `internal-db-class.ts`.
440
- *
441
- * fleet #1089 pulled failures from our own Postgres out of `upstream_down` by
442
- * keying on the SQLSTATE inside PostgREST's four-key error envelope. That
443
- * covered the majority and structurally could not cover the rest: the rest
444
- * never reach Postgres, so they carry no SQLSTATE. What was left, measured over
445
- * the 24h to 2026-09-02T15:00Z (fleet #1096):
446
- *
447
- * 5 pipeworx-catalog get_pack_tools Pipeworx catalog error: 522 — error code: 522
448
- * 3 fleet fleet_list_open … upstream_down: Fleet task queue did not respond within 25s
449
- *
450
- * 521/522/523/526 are Cloudflare saying its edge could not reach an ORIGIN, and
451
- * in both of those rows the origin is ours — `gateway.pipeworx.io` for the
452
- * catalog pack (it self-fetches when the gateway hasn't injected a manifest),
453
- * our own Supabase for fleet. There is no third party anywhere in either call.
454
- * Same defect as #1089: our own outage filed under `upstream_down`, the one
455
- * class that means "the source is unreachable and there is nothing for us to
456
- * fix", which is why the problem-tools triage skips it.
457
- *
458
- * WHY NOT A WORDING RULE. The obvious fix is to match `fleet db error:` and
459
- * `Pipeworx catalog error:` in classifyToolError. Each is emitted from exactly
460
- * one site today, so it would work today. It would also rot the first time
461
- * somebody rewords a label — silently, and in the direction of hiding our own
462
- * outage, which is worse than the bug being fixed. Every prose rule in
463
- * error-class.ts has needed widening as packs invented new wording (#409/#450/
464
- * #584); that history is most of that file's comment budget.
465
- *
466
- * WHAT THIS KEYS ON INSTEAD: **the host the call actually reached.** A URL's
467
- * hostname is a fact about the call, not a guess about its prose. Two
468
- * consequences that a pack-level flag could not give us, and the reason the
469
- * flag was rejected:
470
- *
471
- * - It describes the CALL, not the pack. `govcon-intel` fans out to our own
472
- * Supabase AND to genuine third parties; `court-listener` holds our cache
473
- * in Supabase and fetches courtlistener.com. An `internallyHosted: true` on
474
- * either pack would relabel a real third-party outage as ours — inventing
475
- * work, which is the same class of error in the opposite direction.
476
- * - It covers every future internal pack for free, instead of one declared
477
- * slug at a time.
478
- *
479
- * WHY IT SURVIVES A REWORD. The marker below is not matched as a literal by two
480
- * separate files. `markInternalOrigin()` writes it and `internalHostMetricsClass()`
481
- * reads it, both from the single exported `INTERNAL_ORIGIN_MARKER` constant in
482
- * this module — so changing the wording changes both sides in the same edit and
483
- * cannot desynchronise them. The pack's own label (`fleet db error:`,
484
- * `Pipeworx catalog error:`) is not read at all: reword it freely, the class is
485
- * unaffected. That is the property `stripClassPrefix` lacked when it drifted
486
- * from its own classifier three times and needed a CI gate to hold them
487
- * together.
488
- *
489
- * WHERE THE 5xx TEST LIVES. `markInternalOrigin` is called from the places that
490
- * hold the real `Response` — `httpError`/`httpErrorMessage` and the timeout
491
- * branch of `fetchWithTimeout` in `shared/src/http.ts` — so "is this an
492
- * availability failure" is decided from the actual status code, never re-derived
493
- * by scraping a number out of a sentence. A 404 from our own registry for a slug
494
- * that does not exist is a caller's bad argument and is deliberately NOT marked.
495
- */
496
-
497
- /**
498
- * OUR OWN web service was unreachable — not an upstream, and never `upstream_down`.
499
- *
500
- * ONE value, not three, unlike `internal_db_*`. That split existed because a
501
- * slow query, an exhausted pool and an unknown SQLSTATE have different owners
502
- * and different fixes. Here there is only one story to tell — an origin we run
503
- * did not answer the edge — and one owner. A bucket with no distinct owner per
504
- * value is decoration; #724 is what happens when a class holds several
505
- * situations, and inventing sub-values ahead of a reason to act on them
506
- * differently is the same mistake with the sign flipped.
507
- *
508
- * METRICS ONLY, exactly like PLATFORM_KEY_ERROR_CLASS and the internal_db
509
- * values. `classifyToolError` still answers `upstream_down` for the retry and
510
- * hint paths, which only care whether retrying or a sibling tool might work —
511
- * and it might. Nothing a caller sees or is charged changes here.
512
- *
513
- * READ SIDE: this value is in BROKEN_TOOL_CLASSES, FAULT_CLASSES and
514
- * ALL_ERROR_CLASSES in `workers/registry-api/src/index.ts`. All three, or it
515
- * lands on no dashboard — fleet #721 is the warning, where the #719 split
516
- * worked on the write side and was invisible for weeks.
517
- */
518
- const INTERNAL_SERVICE_UNREACHABLE_CLASS = 'internal_service_unreachable';
519
-
520
- /**
521
- * The token that carries "this origin is ours" from the call site to the
522
- * classifier.
523
- *
524
- * Appended to the error message rather than attached to the Error object,
525
- * because the object does not survive the trip: 275 packs return `{ error:
526
- * string }` instead of throwing, the gateway reads `observedError` as a string,
527
- * and the fleet pack rebuilds its error from a captured status + body across a
528
- * retry loop. A property on an Error would be dropped by every one of those
529
- * paths and the class would work in tests and vanish in production.
530
- *
531
- * Written as a sentence rather than a sigil because it is going to be read by
532
- * whoever gets the error, and "our own service, not a third party" is the
533
- * single most useful thing to tell them — fetchWithTimeout's own comment
534
- * (fleet #1047) is about exactly this ambiguity, where blaming a healthy vendor
535
- * by name sent the next person waiting for an outage that did not exist.
536
- */
537
- const INTERNAL_ORIGIN_MARKER = ' [pipeworx-hosted origin — our own service, not a third party]';
538
-
539
- /**
540
- * Supabase's data plane for a project is `<ref>.supabase.co`, where the ref is
541
- * exactly twenty lowercase letters (ours is `pqauisounztsgdgfkhke`).
542
- *
543
- * Matching the shape rather than listing the ref keeps this correct when we add
544
- * a project — `supabaseEnv` on a pack entry already points some packs at a
545
- * second one — while still excluding `status.supabase.co`, which is Supabase's
546
- * own status page and emphatically not our database. Verified 2026-09-02 by
547
- * `grep -rhoE '[a-z0-9-]+\.supabase\.(co|in)' mcps shared workers scripts`: the
548
- * only real project ref anywhere in the tree is ours, the rest are doc
549
- * placeholders (`abc`, `xyz`, `example`) which this pattern also excludes. Same
550
- * finding internal-db-class.ts relies on for the PostgREST envelope being ours
551
- * by construction.
552
- */
553
- const SUPABASE_PROJECT_HOST = /^[a-z]{20}\.supabase\.(co|in)$/;
554
-
555
- /**
556
- * Is this a host WE run?
557
- *
558
- * Deliberately NOT including `*.workers.dev`: plenty of third-party APIs are
559
- * hosted on workers.dev, so the suffix says where something runs and not who
560
- * owns it. Every internal call we actually make goes to a `pipeworx.io`
561
- * hostname or to our Supabase project, both of which are ownership facts.
562
- *
563
- * Returns false on anything unparseable rather than throwing — this runs inside
564
- * an error path, and an error path that can itself throw turns a diagnosable
565
- * failure into a mystery.
566
- */
567
- function isPipeworxOrigin(url: string | URL | undefined | null): boolean {
568
- if (!url) return false;
569
- let host: string;
570
- try {
571
- host = new URL(url instanceof URL ? url.href : url).hostname.toLowerCase();
572
- } catch {
573
- return false;
574
- }
575
- if (host === 'pipeworx.io' || host.endsWith('.pipeworx.io')) return true;
576
- return SUPABASE_PROJECT_HOST.test(host);
577
- }
578
-
579
- /**
580
- * Append the marker when this failure was OUR origin failing to answer.
581
- *
582
- * `status` is the HTTP status when there is one, and omitted for a timeout —
583
- * where there is no response at all, and "the origin did not answer" is the
584
- * whole observation. Statuses below 500 are left alone: a 404 from our own
585
- * registry for a slug that does not exist is the caller's argument, not our
586
- * outage, and marking it would put ordinary 404s on the incident dashboard.
587
- *
588
- * Idempotent, so a message that is wrapped and re-marked on the way up (the
589
- * fleet pack's retry loop re-throws through two layers) carries the marker once.
590
- */
591
- function markInternalOrigin(
592
- message: string,
593
- url: string | URL | undefined | null,
594
- status?: number,
595
- ): string {
596
- if (status !== undefined && status < 500) return message;
597
- if (!isPipeworxOrigin(url)) return message;
598
- if (message.includes(INTERNAL_ORIGIN_MARKER)) return message;
599
- return message + INTERNAL_ORIGIN_MARKER;
600
- }
601
-
602
- /**
603
- * Which blob4 value a failure from our own web services books as, or undefined
604
- * if this is not one.
605
- *
606
- * Ordered AFTER `internalDbMetricsClass` at the call site: a PostgREST envelope
607
- * from our own Supabase is a strictly more specific statement about the same
608
- * row (which of our services, and why), and the two cannot disagree about
609
- * whether the failure is ours.
610
- */
611
- function internalHostMetricsClass(error: string): string | undefined {
612
- return error.includes(INTERNAL_ORIGIN_MARKER) ? INTERNAL_SERVICE_UNREACHABLE_CLASS : undefined;
613
- }
614
-
615
-
616
638
  /**
617
639
  * ABN Lookup MCP — BYOK wrapper around the Australian Business Register's
618
640
  * ABN Lookup JSON web services (https://abr.business.gov.au/json/).
package/src/server.ts CHANGED
@@ -9,7 +9,7 @@ import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprot
9
9
  import pack from './index.js';
10
10
 
11
11
  const server = new Server(
12
- { name: '@pipeworx/mcp-abn-lookup', version: '0.1.0' },
12
+ { name: '@pipeworx/mcp-abn-lookup', version: '0.1.1' },
13
13
  { capabilities: { tools: {} } },
14
14
  );
15
15
 
package/tsconfig.json CHANGED
@@ -3,9 +3,12 @@
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