@jaypie/mcp 0.8.76 → 0.8.77
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.
- package/dist/suites/docs/index.js +1 -1
- package/package.json +1 -1
- package/release-notes/constructs/1.2.67.md +19 -0
- package/release-notes/mcp/0.8.77.md +13 -0
- package/skills/api.md +1 -1
- package/skills/llm.md +1 -1
- package/skills/models.md +21 -0
|
@@ -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.
|
|
12
|
+
const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.77#1fb6d6fa"
|
|
13
13
|
;
|
|
14
14
|
const __filename$1 = fileURLToPath(import.meta.url);
|
|
15
15
|
const __dirname$1 = path.dirname(__filename$1);
|
package/package.json
CHANGED
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 1.2.67
|
|
3
|
+
date: 2026-06-20
|
|
4
|
+
summary: Add serviceTag to JaypieDistribution for CloudFront metric and log attribution
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Changes
|
|
8
|
+
|
|
9
|
+
- `JaypieDistribution` now accepts an optional `serviceTag` prop, parallel to
|
|
10
|
+
`roleTag` and matching `JaypieLambda`. When set:
|
|
11
|
+
- The distribution is tagged with `CDK.TAG.SERVICE`, so Datadog metrics carry
|
|
12
|
+
`service:<value>` instead of `service:N/A`.
|
|
13
|
+
- The created access-log and WAF-log buckets are tagged with the same value,
|
|
14
|
+
so the Datadog forwarder attributes their forwarded logs to the service
|
|
15
|
+
instead of the generic `cloudfront`/source default.
|
|
16
|
+
- Omitting `serviceTag` preserves current behavior. External/imported log
|
|
17
|
+
buckets are not tagged (the construct does not own them).
|
|
18
|
+
|
|
19
|
+
Issue: [#387](https://github.com/finlaysonstudio/jaypie/issues/387)
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 0.8.77
|
|
3
|
+
date: 2026-06-20
|
|
4
|
+
summary: Lead LLM structured-output docs with natural schema syntax over Zod
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Changes
|
|
8
|
+
|
|
9
|
+
- Reordered the `llm` and `models` skills to present Jaypie's natural schema
|
|
10
|
+
syntax first for structured output, with JSON Schema and Zod as alternatives.
|
|
11
|
+
- Fixed the `llm` skill's `format` type signature to include `NaturalSchema`.
|
|
12
|
+
- Added a natural-schema validation example to the `models` skill so its
|
|
13
|
+
Validation Patterns section is no longer Zod-only.
|
package/skills/api.md
CHANGED
|
@@ -60,4 +60,4 @@ Every response body is a JSON object with one top-level key:
|
|
|
60
60
|
3. Single records use an object: `{ data: {} }`
|
|
61
61
|
4. Multiple records use an array: `{ data: [] }`
|
|
62
62
|
5. Errors always use an array: `{ errors: [] }` (responses only)
|
|
63
|
-
6. No other top-level keys (no `status`, `message`, `meta` at the root)
|
|
63
|
+
6. No other top-level keys (no `status`, `message`, `meta` at the root) except `metadata`
|
package/skills/llm.md
CHANGED
|
@@ -455,7 +455,7 @@ describe("LLM Integration", () => {
|
|
|
455
455
|
interface LlmOperateOptions {
|
|
456
456
|
data?: Record<string, any>; // Placeholder substitution data
|
|
457
457
|
fallback?: LlmFallbackConfig[] | false; // Fallback provider chain
|
|
458
|
-
format?: JsonObject | ZodType;
|
|
458
|
+
format?: NaturalSchema | JsonObject | ZodType; // Structured output schema (natural syntax preferred)
|
|
459
459
|
history?: LlmHistory; // Previous conversation
|
|
460
460
|
hooks?: LlmHooks; // Lifecycle callbacks
|
|
461
461
|
instructions?: string; // Additional instructions
|
package/skills/models.md
CHANGED
|
@@ -83,6 +83,27 @@ const createUser = fabricService({
|
|
|
83
83
|
|
|
84
84
|
## Validation Patterns
|
|
85
85
|
|
|
86
|
+
Prefer Jaypie's natural schema syntax — it validates and types inline without a schema library. Reach for Zod only when you need refinements the natural form can't express.
|
|
87
|
+
|
|
88
|
+
### Natural Schema
|
|
89
|
+
|
|
90
|
+
The fabric `input` object is itself a natural schema: each field declares a `type` (a constructor like `String`/`Number`, or a `const` tuple of allowed values), `required`, and `description`. Input is validated and typed before `service` runs.
|
|
91
|
+
|
|
92
|
+
```typescript
|
|
93
|
+
const createUser = fabricService({
|
|
94
|
+
alias: "user_create",
|
|
95
|
+
input: {
|
|
96
|
+
email: { type: String, required: true, description: "User email address" },
|
|
97
|
+
name: { type: String, required: true, description: "User display name" },
|
|
98
|
+
role: { type: ["user", "admin"] as const, required: false },
|
|
99
|
+
},
|
|
100
|
+
service: async ({ email, name, role }) => {
|
|
101
|
+
// email, name, role are validated and typed here
|
|
102
|
+
return createUserInDatabase({ email, name, role: role || "user" });
|
|
103
|
+
},
|
|
104
|
+
});
|
|
105
|
+
```
|
|
106
|
+
|
|
86
107
|
### Zod Schemas
|
|
87
108
|
|
|
88
109
|
```typescript
|