@jaypie/mcp 0.8.91 → 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.91#18d21761"
+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.91",
+  "version": "0.8.92",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

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/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/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,21 @@ 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:
@@ -341,7 +367,7 @@ Fields carried by each event (`turn` is 1-indexed):
 | `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 }` — fires before the tool runs; `arguments` is the JSON string |
+| `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) |