@jaypie/mcp 0.8.87 → 0.8.88

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.87#9846ff69"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.88#f5108b78"
     ;
 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.87",
+  "version": "0.8.88",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/release-notes/jaypie/1.2.59.md

@@ -0,0 +1,13 @@
+---
+version: 1.2.59
+date: 2026-07-02
+summary: Bump optional @jaypie/llm peer to ^1.3.6
+---
+
+## Dependencies
+
+- Bump the optional `@jaypie/llm` peer dependency floor to `^1.3.6` — default
+  `max_tokens` now resolves to the model's maximum output (capped at 16,384
+  for non-streaming requests) instead of Anthropic's hardcoded 4,096 or
+  Google's 8,192 provider default, so long generations no longer silently
+  truncate (issue #402).

package/release-notes/llm/1.3.6.md

@@ -0,0 +1,31 @@
+---
+version: 1.3.6
+date: 2026-07-02
+summary: Resolve default max_tokens to model max output instead of hardcoded 4096 (Anthropic) / provider default (Google)
+---
+
+## Changes
+
+- Default output-token limits now resolve from the model's documented maximum
+  output instead of Anthropic's hardcoded 4,096 or Google's low 8,192 provider
+  default, which silently truncated long generations (issue #402):
+  - **Non-streaming** (`operate()`, `send()`): capped at 16,384 tokens —
+    larger non-streaming responses risk HTTP timeouts
+  - **Streaming** (`stream()`): the model maximum output — 128,000 for current
+    Claude models (64,000 for Haiku 4.5; lower legacy caps respected), 65,536
+    for Gemini 2.5/3.x
+- New internal utility `resolveMaxOutputTokens(model, { stream })` with a
+  maintained per-model output-cap table (`src/util/maxOutputTokens.ts`)
+- `PROVIDER.ANTHROPIC.MAX_TOKENS.DEFAULT` raised from 4,096 to 16,384
+- Google requests now set `maxOutputTokens` explicitly; Anthropic requests
+  resolve `max_tokens` per model and transport
+- OpenAI and xAI remain unset (their defaults do not truncate early);
+  OpenRouter remains unset (limit varies by routed model)
+- Caller overrides via `providerOptions` (`max_tokens` for Anthropic,
+  `maxOutputTokens` for Google) continue to take precedence
+
+## Migration
+
+No changes required. Callers who previously worked around truncation with
+`providerOptions: { max_tokens: ... }` can remove the override unless they
+want a limit other than the resolved default.

package/release-notes/mcp/0.8.88.md

@@ -0,0 +1,20 @@
+---
+version: 0.8.88
+date: 2026-07-02
+summary: Document the fabric context parameter; reserve plan/case/scenario vocabulary
+---
+
+## Changes
+
+- Add a "Parameters vs Context" section to the `services` skill explaining
+  Fabric's `ServiceFunction` second argument (`context?: ServiceContext`) —
+  error/fatal callbacks, progress messaging, and `fabricHttp` auth/request
+  metadata — distinct from validated domain `input`/`parameters`. Previously
+  only `fabric`, `vocabulary`, and `packages/fabric/CLAUDE.md` documented this;
+  `services` had no mention of it.
+- Reserve `plan`, `case`, and `scenario` as Fabric Models in the `vocabulary`
+  skill, generalizing across agentic applications (events open cases; cases
+  fall into scenarios; scenarios prescribe plans; jobs run plans against
+  cases). Vocabulary reservation only — no `FabricPlan`/`FabricCase`/
+  `FabricScenario` interfaces yet. Also add `kind => category, tags` to
+  discouraged words, same rationale as `type`. (#404)

package/skills/llm.md

@@ -496,6 +496,7 @@ interface LlmOperateOptions {
   hooks?: LlmHooks;                     // Lifecycle callbacks
   instructions?: string;                // Additional instructions
   model?: string;                       // Model override
+  providerOptions?: JsonObject;         // Provider-specific request fields (passthrough)
   system?: string;                      // System prompt
   temperature?: number;                 // Sampling temperature (0-2)
   tools?: LlmTool[] | Toolkit;         // Available tools
@@ -510,6 +511,44 @@ interface LlmFallbackConfig {
 }
 ```
 
+## Provider Options and Output Limits
+
+`providerOptions` passes provider-specific request fields straight through to
+the underlying API: Anthropic merges them into the Messages request body;
+Google merges them into the generation config.
+
+### Default Output Token Limits
+
+Anthropic and Google requests resolve a default output-token limit from the
+model's documented maximum output, so long generations do not silently
+truncate:
+
+- **Non-streaming** (`operate()`, `send()`): capped at 16,384 tokens —
+  larger non-streaming responses risk HTTP timeouts (stream instead)
+- **Streaming** (`stream()`): the model maximum — e.g., 128,000 for current
+  Claude models (64,000 for Haiku), 65,536 for Gemini 2.5/3.x
+
+Override per call with `providerOptions`:
+
+```typescript
+// Anthropic: max_tokens
+await Llm.operate(input, {
+  model: "claude-sonnet-4-6",
+  providerOptions: { max_tokens: 32000 },
+});
+
+// Google: maxOutputTokens
+await Llm.operate(input, {
+  model: "gemini-3.1-pro-preview",
+  providerOptions: { maxOutputTokens: 32000 },
+});
+```
+
+OpenAI and xAI leave the limit unset (their defaults do not truncate early).
+OpenRouter varies by routed model; pass `max_tokens` via `providerOptions`
+when needed. A truncated response surfaces `stop_reason: "max_tokens"` —
+raise the limit or switch to `stream()`.
+
 ## See Also
 
 - **`skill("streaming")`** - Streaming LLM responses to Lambda and Express with `createLambdaStream`

package/skills/services.md

@@ -173,9 +173,23 @@ describe("getUser", () => {
 });
 ```
 
+## Parameters vs Context
+
+Plain service functions above take only domain input (`userId`, `input`). Fabric's `ServiceFunction` type adds a second, optional argument:
+
+```typescript
+type ServiceFunction<TInput, TOutput> = (
+  input: TInput,
+  context?: ServiceContext,
+) => TOutput | Promise<TOutput>;
+```
+
+`parameters`/`input` is validated domain input; `context` is the surrounding scope the service runs within — error/fatal callbacks, progress messaging, and (via `fabricHttp`) auth results and raw HTTP request metadata. See `skill("fabric")` and `skill("vocabulary")` (`Context: scope in which propositions hold`) for the full pattern.
+
 ## See Also
 
 - **`skill("fabric")`** - Fabric service pattern for multi-platform deployment
 - **`skill("handlers")`** - Handler lifecycle and integration with services
 - **`skill("models")`** - Data model and type definitions
+- **`skill("vocabulary")`** - Reserved terms including `context` as a Fabric Service Attribute
 

package/skills/vocabulary.md

@@ -26,6 +26,7 @@ Arguably identity, instance, and relation would form a more complete vocabulary.
 ### Further Postulates
 
 - "Events" trigger "actions"
+- Events open cases; cases fall into scenarios; scenarios prescribe plans; jobs run plans against cases
 
 ## Attribute Definitions
 
@@ -65,6 +66,7 @@ Arguably identity, instance, and relation would form a more complete vocabulary.
 - data => input, state; `data` is a parameter passed for interpolation or response field signaling success
 - jaypie; reserved
 - key => alias; make api or secret keys explicit in name
+- kind => category, tags; same rationale as `type`
 - ou => scope
 - output => state
 - type => category, tags; reserved (exception: `indexModelType` GSI exists in DynamoDB as a legacy pattern; prefer `category` for new work)
@@ -75,6 +77,15 @@ Avoid words defined elsewhere (services, terminology)
 
 - job
 - message
+- plan
+- case
+- scenario
+
+### Model Definitions
+
+- plan: a persisted definition an executor runs; what a job executes. plan : job :: definition : run. A composition projected into data is a plan. Suggested attributes: `alias`, `name`, `description`, `category` (a vocabulary under the model — e.g. composition plans use `workflow` | `agent`), optional `definitionHash` (content hash gating idempotent reseeds), optional `source` (provenance)
+- case: the subject entity a job operates on; long-lived, accretes jobs and messages over time. Jobs reference their case via `job.case` (optional — jobs usually operate on a case; system jobs may not). Neither model requires the other: a case exists before any job runs on it, and a case never stores a job list (query jobs by case)
+- scenario: a named category of cases (see Category in Ontological Grounding). `case.category` holds the scenario alias; the scenario model defines the category itself: `alias`, `name`, `description`, and `plans` (references) — scenarios prescribe which plans respond to them
 
 ### Implied Attributes