@jaypie/mcp 0.8.90 → 0.8.92

package/dist/suites/docs/index.js

@@ -9,7 +9,7 @@ import { gt } from 'semver';
 /**
  * Docs Suite - Documentation services (skill, version, release_notes)
  */
-const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.90#2f0d3db8"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.92#ea103a82"
     ;
 const __filename$1 = fileURLToPath(import.meta.url);
 const __dirname$1 = path.dirname(__filename$1);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jaypie/mcp",
-  "version": "0.8.90",
+  "version": "0.8.92",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/release-notes/jaypie/1.2.61.md

@@ -0,0 +1,15 @@
+---
+version: 1.2.61
+date: 2026-07-04
+summary: Pick up @jaypie/logger 1.2.19 (serialization limits) and @jaypie/llm 1.3.7 (quiet operate logging, onProgress)
+---
+
+## Changes
+
+- `@jaypie/logger` dependency raised to `^1.2.19` — `log` now caps entries
+  at 256KB by default with largest-first attribute truncation, supports
+  `maxStringLength`/`maxDepth`, and exposes `log.config()` for runtime
+  overrides (issue #410)
+- `@jaypie/llm` optional peer raised to `^1.3.7` — `operate()` logs
+  `operate.*` vars at trace with minimal payloads and accepts an
+  `onProgress` progress-event callback

package/release-notes/llm/1.3.7.md

@@ -0,0 +1,44 @@
+---
+version: 1.3.7
+date: 2026-07-04
+summary: Quiet operate.* logging to trace with minimal payloads; add onProgress callback for progress events
+---
+
+## Changes
+
+### Logging
+
+- All `operate.*` log vars (`operate.input`, `operate.options`,
+  `operate.request`, `operate.response`) now emit at **trace** instead of the
+  logger's var level (debug by default)
+- `operate.request` and `operate.response` log draconian subsets instead of
+  full provider payloads (which re-logged the entire conversation history
+  every turn):
+  - `operate.request`: `{ model, turn, messages: <count>, latest: <last message text or type> }`
+  - `operate.response`: the text content, or the requested tool calls
+    (`{ name, arguments }`) when the model calls tools
+- Full provider payloads remain available via the
+  `beforeEachModelRequest` / `afterEachModelResponse` hooks and LLM
+  Observability spans
+
+### Progress Events
+
+- New `onProgress` option on `operate()` — a single callback receiving
+  lightweight, serializable progress events, suitable for forwarding to
+  websockets, queues, or UI updates
+- Event types (`LlmProgressEventType`): `start`, `model_request`,
+  `model_response`, `tool_call`, `tool_result`, `tool_error`, `retry`, `done`
+- Event fields: `content`, `error`, `maxTurns`, `model`, `provider`, `tool`,
+  `toolCalls`, `turn` (1-indexed), `usage`
+- Errors thrown by the callback are logged at warn and never interrupt the
+  loop
+- New exports: `LlmProgressEventType` (enum), `LlmProgressEvent`,
+  `LlmProgressCallback`, `LlmProgressToolCall` (types)
+- `stream()` is unchanged — its chunks already communicate progress
+
+## Migration
+
+No changes required. Consumers who relied on debug-level `operate.request` /
+`operate.response` payload logging should switch to the
+`beforeEachModelRequest` / `afterEachModelResponse` hooks or set
+`LOG_LEVEL=trace` for the summarized vars.

package/release-notes/llm/1.3.8.md

@@ -0,0 +1,28 @@
+---
+version: 1.3.8
+date: 2026-07-04
+summary: Surface resolved LlmTool.message in tool hooks and the tool_call progress event; add Toolkit.resolveMessage
+---
+
+## Changes
+
+### Tool Messages
+
+- `beforeEachTool`, `afterEachTool`, and `onToolError` hooks receive
+  `message` — the tool's resolved `LlmTool.message` (static string or
+  function of the parsed args), `undefined` when the tool defines none.
+  Applies to both `operate()` and `stream()`
+- The `tool_call` progress event (`onProgress`) carries `tool.message`
+- New public `Toolkit.resolveMessage({ name, arguments })` — resolves a
+  tool's message without calling the tool; returns `undefined` when the
+  tool is missing or defines no message; never throws (resolution errors
+  log at warn)
+- `Toolkit.call({ name, arguments, message })` accepts an optional
+  pre-resolved message so the loops resolve each tool's message exactly
+  once per call (function messages are not invoked twice)
+
+## Migration
+
+No changes required. The Toolkit `log` option remains supported and
+continues to receive the resolved message (or the default
+`name:{args}` line when no message is defined).

package/release-notes/logger/1.2.19.md

@@ -0,0 +1,43 @@
+---
+version: 1.2.19
+date: 2026-07-04
+summary: Serialization limits with rational defaults — maxEntryBytes 256KB on by default, maxStringLength/maxDepth opt-in, log.config() runtime overrides (issue #410)
+---
+
+## Changes
+
+- **Entries are capped at 256KB by default** (`maxEntryBytes: 262144`) — the
+  CloudWatch Logs event limit that fronts Datadog in Lambda (Datadog's own
+  per-log cap is 1MB). Oversized payloads previously flooded the pipeline or
+  were cut arbitrarily mid-JSON; now they truncate deliberately (issue #410)
+- Entry truncation degrades gracefully: the top-level attributes of `data`
+  are truncated **largest-first**, each preserving a 72-character preview
+  plus a visible marker — `data:application/pdf;base64,JVBERi0xLjcK…
+  [truncated 612,340 chars]` — until the entry fits. Only if every attribute
+  is truncated and the entry is still oversized does `data` collapse to
+  `[truncated N bytes]`
+- New opt-in limits:
+  - `maxStringLength` — truncate each string field beyond N characters with
+    the same marker style
+  - `maxDepth` — replace objects/arrays nested beyond N levels with
+    `[Object]` / `[Array(n)]` (like `util.inspect`)
+- Configuration, in precedence order:
+  1. Constructor options — `new Logger({ maxEntryBytes, maxDepth,
+     maxStringLength })` / `createLogger` loggers pass through
+  2. `log.config({ maxStringLength: 1024 })` — runtime override, propagates
+     to derived loggers (`lib`, `with`, `flag`) and persists across `init()`
+  3. Env vars — `LOG_MAX_ENTRY_BYTES`, `LOG_MAX_STRING`, `LOG_MAX_DEPTH`;
+     set `0`/`false`/`none`/`off` to disable a limit
+- Pass `false` for any option to disable it (`log.config({ maxEntryBytes:
+  false })` restores unlimited entries)
+- Applied at serialization time only — the caller's object is never mutated.
+  Circular references are handled (`[Circular]`); class instances (Error,
+  Date) are not traversed so their serialization is unchanged
+- New type exports: `SerializationLimitOptions`, `SerializationLimits`
+
+## Migration
+
+No changes required for typical logging. Entries over 256KB — which were
+already lossy in CloudWatch — now truncate deliberately with visible
+markers. To restore unlimited output, set `LOG_MAX_ENTRY_BYTES=false` or
+call `log.config({ maxEntryBytes: false })`.

package/release-notes/mcp/0.8.91.md

@@ -0,0 +1,13 @@
+---
+version: 0.8.91
+date: 2026-07-04
+summary: Document operate() progress events (onProgress) in the llm skill and serialization limits in the logs skill
+---
+
+## Changes
+
+- `skill("llm")` documents the new `onProgress` progress-event callback on
+  `operate()` shipped in `@jaypie/llm@1.3.7`
+- `skill("logs")` documents the serialization limits (`maxEntryBytes` 256KB
+  default, `maxStringLength`, `maxDepth`, `log.config()`, `LOG_MAX_*` env
+  vars) shipped in `@jaypie/logger@1.2.19`

package/release-notes/mcp/0.8.92.md

@@ -0,0 +1,13 @@
+---
+version: 0.8.92
+date: 2026-07-04
+summary: Document tool messages in the llm skill — hooks message field, tool_call event message, Toolkit.resolveMessage
+---
+
+## Changes
+
+- `skill("llm")` documents Tool Messages: the `LlmTool.message` field, the
+  `message` field on `beforeEachTool`/`afterEachTool`/`onToolError` hook
+  contexts, `tool.message` on the `tool_call` progress event, and
+  `Toolkit.resolveMessage()`
+- Release notes for `@jaypie/llm` 1.3.8

package/release-notes/testkit/1.2.51.md

@@ -0,0 +1,13 @@
+---
+version: 1.2.51
+date: 2026-07-04
+summary: Mirror @jaypie/llm LlmProgressEventType export; mock log.config() from @jaypie/logger
+---
+
+## Changes
+
+- `@jaypie/testkit/mock` re-exports `LlmProgressEventType` alongside the
+  existing `LlmMessageRole`, `LlmMessageType`, and `LlmStreamChunkType`
+  mocks, matching `@jaypie/llm@1.3.7`
+- `mockLogFactory` / `spyLog` mock the new `log.config()` method from
+  `@jaypie/logger@1.2.19`

package/skills/llm.md

@@ -166,6 +166,30 @@ When enabled:
 - The explanation is stripped before the tool executes (tools receive clean arguments)
 - Useful for debugging and understanding LLM decision-making
 
+### Tool Messages
+
+Tools may define a `message` — a human-readable status line for the call, either a static string or a function of the parsed arguments:
+
+```typescript
+const toolkit = new Toolkit([
+  {
+    name: "get_weather",
+    description: "Get current weather for a city",
+    type: "function",
+    parameters: { type: "object", properties: { city: { type: "string" } } },
+    call: async ({ city }) => ({ temp: 72 }),
+    message: ({ city }) => `Checking weather in ${city}`,
+  },
+]);
+```
+
+The resolved message surfaces in three places during `operate()`/`stream()`:
+- The Toolkit's `log` option: `new Toolkit(tools, { log: (message, { name, args }) => ... })`
+- The `beforeEachTool`, `afterEachTool`, and `onToolError` hooks as `message`
+- The `tool_call` progress event as `tool.message` (`operate()` only)
+
+Resolve one directly with `toolkit.resolveMessage({ name, arguments })` — returns the resolved string, or `undefined` when the tool is missing or defines no message; it never throws.
+
 ## Structured Output
 
 ### Natural Schema
@@ -303,19 +327,54 @@ const response = await Llm.operate(input, {
     afterEachModelResponse: ({ content, usage }) => {
       console.log(`Tokens: ${usage.total}`);
     },
-    beforeEachTool: ({ toolName, args }) => {
-      console.log(`Calling ${toolName} with`, args);
+    beforeEachTool: ({ toolName, args, message }) => {
+      console.log(message ?? `Calling ${toolName} with ${args}`);
     },
-    afterEachTool: ({ result, toolName }) => {
+    afterEachTool: ({ result, toolName, message }) => {
       console.log(`${toolName} returned:`, result);
     },
-    onToolError: ({ error, toolName }) => {
+    onToolError: ({ error, toolName, message }) => {
       console.error(`${toolName} failed:`, error);
     },
   },
 });
 ```
 
+The tool hooks receive `message` — the tool's resolved `LlmTool.message`, when the tool defines one (see Tool Messages).
+
+## Progress Events
+
+For progress reporting (UI updates, websockets, queue notifications), prefer `onProgress` over wiring individual hooks. It receives lightweight, serializable events as the loop runs:
+
+```typescript
+import { LlmProgressEventType } from "@jaypie/llm";
+
+const response = await Llm.operate(input, {
+  model: "gpt-5.1",
+  tools: toolkit,
+  onProgress: (event) => {
+    // event.type: start, model_request, model_response,
+    //             tool_call, tool_result, tool_error, retry, done
+    websocket.send(JSON.stringify(event));
+  },
+});
+```
+
+Fields carried by each event (`turn` is 1-indexed):
+
+| Event | Fields |
+|-------|--------|
+| `start` | `model`, `provider`, `maxTurns` |
+| `model_request` | `turn`, `model` |
+| `model_response` | `turn`, `content` (text, if any), `toolCalls` (`[{ name, arguments }]`, if any), `usage` (this turn) |
+| `tool_call` | `turn`, `tool: { name, arguments, message }` — fires before the tool runs; `arguments` is the JSON string; `message` is the resolved `LlmTool.message`, when the tool defines one |
+| `tool_result` | `turn`, `tool: { name }` — the result value is deliberately omitted (it can be arbitrarily large); use the `afterEachTool` hook to receive it |
+| `tool_error` | `turn`, `tool: { name }`, `error` (message string) |
+| `retry` | `turn`, `error` (message string) |
+| `done` | `turn` (total turns used), `content` (final text or structured output), `usage` (cumulative) |
+
+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()`.
+
 ## Fallback Providers
 
 Configure a chain of fallback providers that automatically retry failed calls when the primary provider fails:

package/skills/logs.md

@@ -110,6 +110,39 @@ const logger = new Logger({ format: "json", level: "debug", levelField: "status"
 logger.info("test"); // { "message": "test", "status": "info" }
 ```
 
+## Serialization Limits
+
+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:
+
+```
+data:application/pdf;base64,JVBERi0xLjcK… [truncated 612,340 chars]
+```
+
+Two more limits are available, off by default:
+
+- `maxStringLength` — truncate each string field beyond N characters
+- `maxDepth` — replace objects/arrays nested beyond N levels with `[Object]` / `[Array(n)]`
+
+Configure via env vars (`0`/`false` disables a limit):
+
+```bash
+LOG_MAX_ENTRY_BYTES=1048576   # Raise entry cap to 1MB (Datadog direct)
+LOG_MAX_ENTRY_BYTES=false     # Unlimited entries
+LOG_MAX_STRING=16384          # Truncate strings beyond 16KB
+LOG_MAX_DEPTH=8               # Collapse nesting beyond 8 levels
+```
+
+Or at runtime with `log.config()` — propagates to derived loggers (`lib`, `with`, `flag`) and persists across `init()`:
+
+```typescript
+import { log } from "jaypie";
+
+log.config({ maxStringLength: 1024 });
+log.config({ maxEntryBytes: false }); // false disables a limit
+```
+
+Limits apply at serialization time only — the caller's object is never mutated.
+
 ## Lambda Logging
 
 Lambda handlers automatically add context: