@pipeworx/mcp-sciencebase 0.1.1 → 0.1.3

package/README.md

@@ -2,7 +2,7 @@
 
 USGS ScienceBase catalog MCP.
 
-Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 1679+ live data sources.
+Part of [Pipeworx](https://pipeworx.io) — an MCP gateway connecting AI agents to 1684+ live data sources.
 
 ## Tools
 
@@ -56,7 +56,7 @@ directly, instead of just this one's:
 }
 ```
 
-Both URLs reach the same gateway and the same 1679+ data sources. The
+Both URLs reach the same gateway and the same 1684+ data sources. The
 only difference is which pack's tools are listed **directly**; `ask_pipeworx`
 reaches all of them from either one.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pipeworx/mcp-sciencebase",
-  "version": "0.1.1",
+  "version": "0.1.3",
   "description": "USGS ScienceBase catalog MCP.",
   "type": "module",
   "main": "src/index.ts",
@@ -26,7 +26,7 @@
     "@cloudflare/workers-types": "^4.20260405.1"
   },
   "pipeworx": {
-    "sourceHash": "v1-3f47e33454afb71a27834d24067492798c30f05d9450294804d266860fad1ca7",
-    "sourceCommit": "00c836ddeaecbdd581dcfb0fb1842efea104006e"
+    "sourceHash": "v1-b2e2f72f448fb7906515f7b7bdd0567372bcd833e6a8cac5c6cb9303c906689a",
+    "sourceCommit": "fb13c3bcac104b099040ae8d7d93cb800d570afb"
   }
 }

package/server.json

@@ -3,7 +3,7 @@
   "name": "io.github.pipeworx-io/sciencebase",
   "title": "Sciencebase",
   "description": "USGS ScienceBase catalog MCP.",
-  "version": "0.1.1",
+  "version": "0.1.3",
   "websiteUrl": "https://pipeworx.io/packs/sciencebase",
   "repository": {
     "url": "https://github.com/pipeworx-io/mcp-sciencebase",

package/src/index.ts

@@ -452,7 +452,42 @@ async function fetchWithTimeout(
         ),
       );
     }
-    throw err;
+    // Fleet #2382. Everything that isn't a timeout/abort here is a genuine
+    // NETWORK-LEVEL failure — DNS resolution, connection refused, TLS handshake,
+    // Cloudflare's own "Network connection lost." — meaning `fetch()` itself
+    // threw and no HTTP response of any kind was ever received. Until this fix
+    // that raw exception was rethrown VERBATIM: a bare `TypeError: fetch failed`
+    // (or the Workers-runtime equivalent) names no upstream, carries no class
+    // token, and reads exactly like a defect in OUR code — because it says
+    // nothing about the call at all. It landed in `error`, the tier that means
+    // "Pipeworx has a defect", for every one of the (at the time of writing)
+    // ~470 packs that call this helper directly with no wrapper of their own.
+    //
+    // `dexscreener` hit this independently (fleet #1579) and fixed it with a
+    // bespoke per-pack try/catch around `fetchWithTimeout`. That fix is correct
+    // but only covers one pack; every other caller of this shared helper still
+    // leaked the raw exception. Moving the same fix HERE — the one place that
+    // already carries the timeout case — covers every pack that uses
+    // `fetchWithTimeout` without a wrapper, for free, and without widening
+    // `classifyToolError`'s regex list: the fix is giving the message a proper
+    // `upstream_down:` token at the point the two facts (no response was ever
+    // received, and which host we were trying to reach) are actually in hand,
+    // not teaching the classifier to guess from prose after the fact.
+    //
+    // Safe on the same grounds as the timeout branch above: no argument a
+    // caller passes can make `fetch()` itself throw a connection-level error,
+    // so this is always an availability failure, never a caller mistake. Same
+    // `markInternalOrigin` treatment — an origin we run that never answered is
+    // still ours, not a third party's outage.
+    const raw = err instanceof Error ? err.message : String(err);
+    throw new Error(
+      markInternalOrigin(
+        `upstream_down: could not reach ${name} at all (${raw.slice(0, 160)}). ` +
+          `No request reached ${name}, so this says NOTHING about whether the arguments you passed ` +
+          'are valid — do not re-check them on the strength of this error. Retry shortly.',
+        url,
+      ),
+    );
   }
 }
 
@@ -824,7 +859,21 @@ async function sbGet(path: string, params: Record<string, string>): Promise<unkn
     // A 200 that is not JSON is the catalog answering with something other than
     // its API — report the shape, never let it surface as a parse error.
     return {
-      __error: `ScienceBase returned HTTP ${res.status} with a non-JSON body (${body.slice(0, 120)})`,
+      // `upstream_down:` is a CLASS TOKEN the gateway strips and classifies on
+      // (error-class.ts). Without it this booked plain `error`, which means
+      // PIPEWORX BROKE — and a catalog answering HTML where it promises JSON is
+      // the upstream's fault, not ours.
+      //
+      // It also makes the two remaining failure paths tellable apart in
+      // telemetry, which is why it is worth the token rather than just better
+      // prose. Measured 2026-09-26: `get_item` showed 2 external `error` events
+      // (09-22, 09-25) and they were read as "the not-found fix did not land".
+      // They are not misses — a miss returns `found:false` above and books
+      // `user_error`, verified live. They are THIS branch. With blob5 content
+      // redacted there was no way to see that from the class alone, and the
+      // callers are in regions where USGS may challenge differently: three
+      // probes from here returned clean JSON, so it is not reproducible locally.
+      __error: `upstream_down: ScienceBase returned HTTP ${res.status} with a non-JSON body (${body.slice(0, 120)})`,
     };
   }
 }

package/src/server.ts

@@ -9,7 +9,7 @@ import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprot
 import pack from './index.js';
 
 const server = new Server(
-  { name: '@pipeworx/mcp-sciencebase', version: '0.1.1' },
+  { name: '@pipeworx/mcp-sciencebase', version: '0.1.3' },
   { capabilities: { tools: {} } },
 );