@jaypie/mcp 0.7.7 → 0.7.9

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.
@@ -9,7 +9,7 @@ import { gt } from 'semver';
9
9
  /**
10
10
  * Docs Suite - Documentation services (skill, version, release_notes)
11
11
  */
12
- const BUILD_VERSION_STRING = "@jaypie/mcp@0.7.7#7d7a0427"
12
+ const BUILD_VERSION_STRING = "@jaypie/mcp@0.7.9#3c1d1abd"
13
13
  ;
14
14
  const __filename$1 = fileURLToPath(import.meta.url);
15
15
  const __dirname$1 = path.dirname(__filename$1);
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@jaypie/mcp",
3
- "version": "0.7.7",
3
+ "version": "0.7.9",
4
4
  "description": "Jaypie MCP",
5
5
  "repository": {
6
6
  "type": "git",
@@ -0,0 +1,12 @@
1
+ ---
2
+ version: 1.2.10
3
+ date: 2026-02-02
4
+ summary: Fix Lambda streaming NO_CONTENT detection using Symbol marker
5
+ ---
6
+
7
+ ## Bug Fixes
8
+
9
+ - **#178**: Fixed Lambda streaming NO_CONTENT responses still hanging after previous fix
10
+ - The `_responseStream` property check failed after Express's prototype manipulation
11
+ - Now uses `JAYPIE_LAMBDA_STREAMING` Symbol marker for reliable detection
12
+ - Matches the pattern used for `JAYPIE_LAMBDA_MOCK` in buffered responses
@@ -0,0 +1,22 @@
1
+ ---
2
+ version: 1.2.9
3
+ date: 2026-02-02
4
+ summary: Fix Lambda streaming hang for NO_CONTENT responses via expressHandler
5
+ ---
6
+
7
+ # @jaypie/express 1.2.9
8
+
9
+ ## Bug Fixes
10
+
11
+ - **Lambda streaming NO_CONTENT hang**: Fixed issue where `httpHandler(HTTP.CODE.NO_CONTENT)` routes would hang when using Lambda streaming. The previous fix (1.2.8) only addressed CORS OPTIONS requests; this extends the solution to all responses going through `expressHandler`.
12
+
13
+ ## Technical Details
14
+
15
+ For Lambda streaming responses, `flushHeaders()` must be called before `send()`/`json()` to initialize `_wrappedStream`. Without this, the async `_final()` callback finds `_wrappedStream` null and the Lambda hangs.
16
+
17
+ The fix detects Lambda streaming responses by checking for `"_responseStream" in res`, which is unique to `LambdaResponseStreaming`.
18
+
19
+ ## Related
20
+
21
+ - Fixes GitHub issue #178
22
+ - Builds on fix from 1.2.8 (96dce858)
@@ -0,0 +1,21 @@
1
+ ---
2
+ version: 0.2.2
3
+ date: 2026-02-02
4
+ summary: Fix fabricObject to pass through arbitrary objects instead of requiring value property
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - **Fix**: `fabricObject` now passes through arbitrary objects without requiring a `value` property
10
+ - **Fix**: `resolveFromObject` now passes through objects without `value` instead of throwing
11
+
12
+ ## Background
13
+
14
+ Previously, when using `type: Object` in a `fabricService` input definition, objects without a `value` property would throw `BadRequestError: Object must have a value attribute`. This was problematic for tools like the Datadog MCP tool that accept arbitrary parameter objects like `{ query: "...", from: "now-1h" }`.
15
+
16
+ The fix allows:
17
+ - Objects with `value` property: extracted as before
18
+ - Objects without `value` property: passed through as-is
19
+ - Scalars and arrays: still wrapped in `{ value: ... }`
20
+
21
+ This change follows the "fabric philosophy" - things that feel right should work.