@jaypie/mcp 0.8.90 → 0.8.91

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.8.90#2f0d3db8"
12
+ const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.91#18d21761"
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.8.90",
3
+ "version": "0.8.91",
4
4
  "description": "Jaypie MCP",
5
5
  "repository": {
6
6
  "type": "git",
@@ -0,0 +1,15 @@
1
+ ---
2
+ version: 1.2.61
3
+ date: 2026-07-04
4
+ summary: Pick up @jaypie/logger 1.2.19 (serialization limits) and @jaypie/llm 1.3.7 (quiet operate logging, onProgress)
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `@jaypie/logger` dependency raised to `^1.2.19` — `log` now caps entries
10
+ at 256KB by default with largest-first attribute truncation, supports
11
+ `maxStringLength`/`maxDepth`, and exposes `log.config()` for runtime
12
+ overrides (issue #410)
13
+ - `@jaypie/llm` optional peer raised to `^1.3.7` — `operate()` logs
14
+ `operate.*` vars at trace with minimal payloads and accepts an
15
+ `onProgress` progress-event callback
@@ -0,0 +1,44 @@
1
+ ---
2
+ version: 1.3.7
3
+ date: 2026-07-04
4
+ summary: Quiet operate.* logging to trace with minimal payloads; add onProgress callback for progress events
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ ### Logging
10
+
11
+ - All `operate.*` log vars (`operate.input`, `operate.options`,
12
+ `operate.request`, `operate.response`) now emit at **trace** instead of the
13
+ logger's var level (debug by default)
14
+ - `operate.request` and `operate.response` log draconian subsets instead of
15
+ full provider payloads (which re-logged the entire conversation history
16
+ every turn):
17
+ - `operate.request`: `{ model, turn, messages: <count>, latest: <last message text or type> }`
18
+ - `operate.response`: the text content, or the requested tool calls
19
+ (`{ name, arguments }`) when the model calls tools
20
+ - Full provider payloads remain available via the
21
+ `beforeEachModelRequest` / `afterEachModelResponse` hooks and LLM
22
+ Observability spans
23
+
24
+ ### Progress Events
25
+
26
+ - New `onProgress` option on `operate()` — a single callback receiving
27
+ lightweight, serializable progress events, suitable for forwarding to
28
+ websockets, queues, or UI updates
29
+ - Event types (`LlmProgressEventType`): `start`, `model_request`,
30
+ `model_response`, `tool_call`, `tool_result`, `tool_error`, `retry`, `done`
31
+ - Event fields: `content`, `error`, `maxTurns`, `model`, `provider`, `tool`,
32
+ `toolCalls`, `turn` (1-indexed), `usage`
33
+ - Errors thrown by the callback are logged at warn and never interrupt the
34
+ loop
35
+ - New exports: `LlmProgressEventType` (enum), `LlmProgressEvent`,
36
+ `LlmProgressCallback`, `LlmProgressToolCall` (types)
37
+ - `stream()` is unchanged — its chunks already communicate progress
38
+
39
+ ## Migration
40
+
41
+ No changes required. Consumers who relied on debug-level `operate.request` /
42
+ `operate.response` payload logging should switch to the
43
+ `beforeEachModelRequest` / `afterEachModelResponse` hooks or set
44
+ `LOG_LEVEL=trace` for the summarized vars.
@@ -0,0 +1,43 @@
1
+ ---
2
+ version: 1.2.19
3
+ date: 2026-07-04
4
+ summary: Serialization limits with rational defaults — maxEntryBytes 256KB on by default, maxStringLength/maxDepth opt-in, log.config() runtime overrides (issue #410)
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - **Entries are capped at 256KB by default** (`maxEntryBytes: 262144`) — the
10
+ CloudWatch Logs event limit that fronts Datadog in Lambda (Datadog's own
11
+ per-log cap is 1MB). Oversized payloads previously flooded the pipeline or
12
+ were cut arbitrarily mid-JSON; now they truncate deliberately (issue #410)
13
+ - Entry truncation degrades gracefully: the top-level attributes of `data`
14
+ are truncated **largest-first**, each preserving a 72-character preview
15
+ plus a visible marker — `data:application/pdf;base64,JVBERi0xLjcK…
16
+ [truncated 612,340 chars]` — until the entry fits. Only if every attribute
17
+ is truncated and the entry is still oversized does `data` collapse to
18
+ `[truncated N bytes]`
19
+ - New opt-in limits:
20
+ - `maxStringLength` — truncate each string field beyond N characters with
21
+ the same marker style
22
+ - `maxDepth` — replace objects/arrays nested beyond N levels with
23
+ `[Object]` / `[Array(n)]` (like `util.inspect`)
24
+ - Configuration, in precedence order:
25
+ 1. Constructor options — `new Logger({ maxEntryBytes, maxDepth,
26
+ maxStringLength })` / `createLogger` loggers pass through
27
+ 2. `log.config({ maxStringLength: 1024 })` — runtime override, propagates
28
+ to derived loggers (`lib`, `with`, `flag`) and persists across `init()`
29
+ 3. Env vars — `LOG_MAX_ENTRY_BYTES`, `LOG_MAX_STRING`, `LOG_MAX_DEPTH`;
30
+ set `0`/`false`/`none`/`off` to disable a limit
31
+ - Pass `false` for any option to disable it (`log.config({ maxEntryBytes:
32
+ false })` restores unlimited entries)
33
+ - Applied at serialization time only — the caller's object is never mutated.
34
+ Circular references are handled (`[Circular]`); class instances (Error,
35
+ Date) are not traversed so their serialization is unchanged
36
+ - New type exports: `SerializationLimitOptions`, `SerializationLimits`
37
+
38
+ ## Migration
39
+
40
+ No changes required for typical logging. Entries over 256KB — which were
41
+ already lossy in CloudWatch — now truncate deliberately with visible
42
+ markers. To restore unlimited output, set `LOG_MAX_ENTRY_BYTES=false` or
43
+ call `log.config({ maxEntryBytes: false })`.
@@ -0,0 +1,13 @@
1
+ ---
2
+ version: 0.8.91
3
+ date: 2026-07-04
4
+ summary: Document operate() progress events (onProgress) in the llm skill and serialization limits in the logs skill
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `skill("llm")` documents the new `onProgress` progress-event callback on
10
+ `operate()` shipped in `@jaypie/llm@1.3.7`
11
+ - `skill("logs")` documents the serialization limits (`maxEntryBytes` 256KB
12
+ default, `maxStringLength`, `maxDepth`, `log.config()`, `LOG_MAX_*` env
13
+ vars) shipped in `@jaypie/logger@1.2.19`
@@ -0,0 +1,13 @@
1
+ ---
2
+ version: 1.2.51
3
+ date: 2026-07-04
4
+ summary: Mirror @jaypie/llm LlmProgressEventType export; mock log.config() from @jaypie/logger
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `@jaypie/testkit/mock` re-exports `LlmProgressEventType` alongside the
10
+ existing `LlmMessageRole`, `LlmMessageType`, and `LlmStreamChunkType`
11
+ mocks, matching `@jaypie/llm@1.3.7`
12
+ - `mockLogFactory` / `spyLog` mock the new `log.config()` method from
13
+ `@jaypie/logger@1.2.19`
package/skills/llm.md CHANGED
@@ -316,6 +316,39 @@ const response = await Llm.operate(input, {
316
316
  });
317
317
  ```
318
318
 
319
+ ## Progress Events
320
+
321
+ For progress reporting (UI updates, websockets, queue notifications), prefer `onProgress` over wiring individual hooks. It receives lightweight, serializable events as the loop runs:
322
+
323
+ ```typescript
324
+ import { LlmProgressEventType } from "@jaypie/llm";
325
+
326
+ const response = await Llm.operate(input, {
327
+ model: "gpt-5.1",
328
+ tools: toolkit,
329
+ onProgress: (event) => {
330
+ // event.type: start, model_request, model_response,
331
+ // tool_call, tool_result, tool_error, retry, done
332
+ websocket.send(JSON.stringify(event));
333
+ },
334
+ });
335
+ ```
336
+
337
+ Fields carried by each event (`turn` is 1-indexed):
338
+
339
+ | Event | Fields |
340
+ |-------|--------|
341
+ | `start` | `model`, `provider`, `maxTurns` |
342
+ | `model_request` | `turn`, `model` |
343
+ | `model_response` | `turn`, `content` (text, if any), `toolCalls` (`[{ name, arguments }]`, if any), `usage` (this turn) |
344
+ | `tool_call` | `turn`, `tool: { name, arguments }` — fires before the tool runs; `arguments` is the JSON string |
345
+ | `tool_result` | `turn`, `tool: { name }` — the result value is deliberately omitted (it can be arbitrarily large); use the `afterEachTool` hook to receive it |
346
+ | `tool_error` | `turn`, `tool: { name }`, `error` (message string) |
347
+ | `retry` | `turn`, `error` (message string) |
348
+ | `done` | `turn` (total turns used), `content` (final text or structured output), `usage` (cumulative) |
349
+
350
+ Errors thrown by the callback are logged and never interrupt the loop. Hooks remain the right choice when you need the full provider request/response payloads. `stream()` communicates progress through its chunks; `onProgress` applies to `operate()`.
351
+
319
352
  ## Fallback Providers
320
353
 
321
354
  Configure a chain of fallback providers that automatically retry failed calls when the primary provider fails:
package/skills/logs.md CHANGED
@@ -110,6 +110,39 @@ const logger = new Logger({ format: "json", level: "debug", levelField: "status"
110
110
  logger.info("test"); // { "message": "test", "status": "info" }
111
111
  ```
112
112
 
113
+ ## Serialization Limits
114
+
115
+ Entries are capped at 256KB by default (`maxEntryBytes: 262144` — the CloudWatch Logs event limit that fronts Datadog in Lambda). Oversized entries truncate the top-level attributes of `data` largest-first, each keeping a 72-character preview plus a visible marker:
116
+
117
+ ```
118
+ data:application/pdf;base64,JVBERi0xLjcK… [truncated 612,340 chars]
119
+ ```
120
+
121
+ Two more limits are available, off by default:
122
+
123
+ - `maxStringLength` — truncate each string field beyond N characters
124
+ - `maxDepth` — replace objects/arrays nested beyond N levels with `[Object]` / `[Array(n)]`
125
+
126
+ Configure via env vars (`0`/`false` disables a limit):
127
+
128
+ ```bash
129
+ LOG_MAX_ENTRY_BYTES=1048576 # Raise entry cap to 1MB (Datadog direct)
130
+ LOG_MAX_ENTRY_BYTES=false # Unlimited entries
131
+ LOG_MAX_STRING=16384 # Truncate strings beyond 16KB
132
+ LOG_MAX_DEPTH=8 # Collapse nesting beyond 8 levels
133
+ ```
134
+
135
+ Or at runtime with `log.config()` — propagates to derived loggers (`lib`, `with`, `flag`) and persists across `init()`:
136
+
137
+ ```typescript
138
+ import { log } from "jaypie";
139
+
140
+ log.config({ maxStringLength: 1024 });
141
+ log.config({ maxEntryBytes: false }); // false disables a limit
142
+ ```
143
+
144
+ Limits apply at serialization time only — the caller's object is never mutated.
145
+
113
146
  ## Lambda Logging
114
147
 
115
148
  Lambda handlers automatically add context: