@jaypie/mcp 0.8.60 → 0.8.62

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/README.md CHANGED
@@ -1,61 +1,9 @@
1
- # Jaypie MCP
1
+ # Jaypie MCP 🐦‍⬛
2
2
 
3
- MCP (Model Context Protocol) server for Jaypie development. Provides tools for AI agents to access Jaypie documentation, development guides, Datadog observability data, and AWS CLI operations.
3
+ Model Context Protocol server for Jaypie.
4
4
 
5
- ## Usage
5
+ See [jaypie.net](https://jaypie.net) for documentation.
6
6
 
7
- ```bash
8
- npx jaypie-mcp # Run MCP server via stdio
9
- npx jaypie-mcp --verbose # Run with debug logging
10
- ```
7
+ ## 📜 License
11
8
 
12
- ## Environment Variables
13
-
14
- ### AWS CLI Integration
15
- | Variable | Description |
16
- |----------|-------------|
17
- | `AWS_PROFILE` | Default profile if not specified per-call |
18
- | `AWS_REGION` or `AWS_DEFAULT_REGION` | Default region if not specified |
19
-
20
- AWS tools use the host's existing credential chain:
21
- - `~/.aws/credentials` and `~/.aws/config` files
22
- - Environment variables (`AWS_ACCESS_KEY_ID`, etc.)
23
- - SSO sessions established via `aws sso login`
24
-
25
- ### Datadog Integration
26
- | Variable | Description |
27
- |----------|-------------|
28
- | `DATADOG_API_KEY` or `DD_API_KEY` | Datadog API key |
29
- | `DATADOG_APP_KEY` or `DD_APP_KEY` | Datadog Application key |
30
- | `DD_ENV` | Default environment filter |
31
- | `DD_QUERY` | Default query terms appended to searches |
32
-
33
- ## MCP Tools
34
-
35
- ### Documentation Tools
36
- - `skill` - Access Jaypie development documentation by alias
37
- - `version` - Returns package version string
38
- - `list_release_notes` - List available release notes
39
- - `read_release_note` - Read specific release note content
40
-
41
- ### AWS CLI Tools (16 tools)
42
- - Step Functions: `aws_stepfunctions_list_executions`, `aws_stepfunctions_stop_execution`
43
- - Lambda: `aws_lambda_list_functions`, `aws_lambda_get_function`
44
- - CloudWatch Logs: `aws_logs_filter_log_events`
45
- - S3: `aws_s3_list_objects`
46
- - CloudFormation: `aws_cloudformation_describe_stack`
47
- - DynamoDB: `aws_dynamodb_describe_table`, `aws_dynamodb_scan`, `aws_dynamodb_query`, `aws_dynamodb_get_item`
48
- - SQS: `aws_sqs_list_queues`, `aws_sqs_get_queue_attributes`, `aws_sqs_receive_message`, `aws_sqs_purge_queue`
49
- - Profiles: `aws_list_profiles`
50
-
51
- ### Datadog Tools (6 tools)
52
- - `datadog_logs`, `datadog_log_analytics`, `datadog_monitors`, `datadog_synthetics`, `datadog_metrics`, `datadog_rum`
53
-
54
- ### LLM Tools (2 tools)
55
- - `llm_debug_call`, `llm_list_providers`
56
-
57
- See [CLAUDE.md](./CLAUDE.md) for detailed documentation.
58
-
59
- ## License
60
-
61
- [MIT License](./LICENSE.txt). Published by Finlayson Studio
9
+ [MIT License](./LICENSE.txt). Published by Finlayson Studio.
@@ -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.60#21fed95d"
12
+ const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.62#b2bba65a"
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.60",
3
+ "version": "0.8.62",
4
4
  "description": "Jaypie MCP",
5
5
  "repository": {
6
6
  "type": "git",
@@ -0,0 +1,11 @@
1
+ ---
2
+ version: 1.2.58
3
+ date: 2026-05-18
4
+ summary: Add bedrock:*, bedrock-agent:*, and bedrock-agentcore:* to Developer SSO permission set
5
+ ---
6
+
7
+ ## @jaypie/constructs 1.2.58
8
+
9
+ ### Features
10
+
11
+ - **JaypieSsoPermissions**: Added `bedrock:*`, `bedrock-agent:*`, and `bedrock-agentcore:*` to the Developer permission set inline policy
@@ -0,0 +1,32 @@
1
+ ---
2
+ version: 0.6.2
3
+ date: 2026-05-29
4
+ summary: Add schema-agnostic scanTable/countTable and createTable/destroyTable to support table-rebuild migrations
5
+ ---
6
+
7
+ ## New
8
+
9
+ Table-rebuild primitives. The 0.5.0 primary-key change cannot be migrated in
10
+ place, so moving from 0.4.x requires copying records into a new table. These
11
+ exports provide the verbs; the per-record transform stays application-specific.
12
+
13
+ - **`scanTable({ tableName?, pageSize? })`**: async generator yielding every
14
+ raw item via a schema-agnostic `Scan`, paginating internally. Unlike the
15
+ query functions it does not depend on the GSI shape, so it reads an old
16
+ (0.4.x) table whose indexes no longer match the registered models. Pass an
17
+ explicit `tableName` to read a table other than the initialized one.
18
+ - **`countTable({ tableName? })`**: total item count via a paginated `COUNT`
19
+ scan -- compare source and destination before destroying the old table.
20
+ - **`createTable({ tableName?, billingMode?, wait? })`**: create a table with
21
+ the registered-model GSI schema, honoring the `initClient` config (real AWS
22
+ or local). Waits until the table is `ACTIVE` by default.
23
+ - **`destroyTable({ tableName })`**: delete a table. `tableName` is required
24
+ with no default -- deleting is destructive and must be intentional.
25
+ - **`getClient()`**: the raw `DynamoDBClient` (control-plane), alongside the
26
+ existing `getDocClient()` (data-plane).
27
+
28
+ ## Docs
29
+
30
+ - New "Rebuilding a table (0.4 → 0.6)" guide documenting the CDK-managed,
31
+ maintenance-window cutover: deploy new table → scan/transform/write →
32
+ validate counts → flip `DYNAMODB_TABLE_NAME` → destroy old table later.
@@ -0,0 +1,34 @@
1
+ ---
2
+ version: 0.6.3
3
+ date: 2026-05-31
4
+ summary: transactWriteEntities supports conditional writes (conditionalCreate / condition) and throws ConflictError on a conditional-check failure
5
+ ---
6
+
7
+ ## Added
8
+
9
+ - **Conditional `transactWriteEntities`**. The transaction writer now accepts
10
+ two optional params so callers can express the canonical DynamoDB
11
+ uniqueness / atomic-create pattern in a single transaction:
12
+
13
+ - `conditionalCreate: true` guards **every** `Put` with
14
+ `attribute_not_exists(id)` — mirroring `createEntity` for the multi-item
15
+ case (e.g. writing an entity **and** its uniqueness-sentinel row atomically).
16
+ - `condition: string` supplies a custom `ConditionExpression` applied to
17
+ every `Put` (takes precedence over `conditionalCreate`).
18
+
19
+ ```ts
20
+ await transactWriteEntities({
21
+ conditionalCreate: true, // attribute_not_exists(id) on every Put
22
+ entities: [organization, aliasLock],
23
+ });
24
+ ```
25
+
26
+ - **Distinct conflict signal**. When a conditional write causes DynamoDB to
27
+ cancel the transaction (`ConditionalCheckFailed`), `transactWriteEntities`
28
+ now throws a `ConflictError` (409, from `@jaypie/errors`) instead of a raw
29
+ `TransactionCanceledException`, so callers can map the conflict to a 4xx.
30
+ Non-conditional cancellations propagate unchanged.
31
+
32
+ The default (no condition) remains an unconditional write — fully additive.
33
+
34
+ Issue: [#357](https://github.com/finlaysonstudio/jaypie/issues/357)
@@ -0,0 +1,20 @@
1
+ ---
2
+ version: 1.2.2
3
+ date: 2026-05-31
4
+ summary: Add ConflictError (409) for uniqueness / state-conflict responses
5
+ ---
6
+
7
+ ## Added
8
+
9
+ - **`ConflictError` (409)**. Jaypie previously had no 409, so callers had to
10
+ reach for a generic `BadRequestError` (400) for uniqueness violations and
11
+ other state conflicts. `ConflictError` fills the gap and is wired into
12
+ `jaypieErrorFromStatus(409)`.
13
+
14
+ ```ts
15
+ import { ConflictError } from "jaypie";
16
+
17
+ throw new ConflictError("Alias already claimed");
18
+ ```
19
+
20
+ Issue: [#357](https://github.com/finlaysonstudio/jaypie/issues/357)
@@ -0,0 +1,13 @@
1
+ ---
2
+ version: 1.2.48
3
+ date: 2026-05-11
4
+ summary: pick up @jaypie/lambda 1.2.8 fix for migrationHandler waiter loop (#350)
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - Updated `@jaypie/lambda` dependency to `^1.2.8`.
10
+
11
+ ## Details
12
+
13
+ See `@jaypie/lambda` 1.2.8 release notes. Consumers of `jaypie` now automatically pick up the `migrationHandler` discriminator fix that prevented `JaypieMigration` deploys from completing.
@@ -0,0 +1,12 @@
1
+ ---
2
+ version: 1.2.49
3
+ date: 2026-05-31
4
+ summary: Re-export the new ConflictError (409) via the @jaypie/errors 1.2.2 bump
5
+ ---
6
+
7
+ ## Changed
8
+
9
+ - Bumped `@jaypie/errors` to `^1.2.2`, so `ConflictError` (409) is now
10
+ available from the `jaypie` entrypoint.
11
+
12
+ Issue: [#357](https://github.com/finlaysonstudio/jaypie/issues/357)
@@ -0,0 +1,9 @@
1
+ ---
2
+ version: 1.2.9
3
+ date: 2026-05-26
4
+ summary: Add X-Webhook-Signature HTTP header constant
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - Added `HTTP.HEADER.WEBHOOK_SIGNATURE` (`"X-Webhook-Signature"`) to the HTTP header constants
@@ -0,0 +1,17 @@
1
+ ---
2
+ version: 1.2.8
3
+ date: 2026-05-11
4
+ summary: fix migrationHandler discriminator — onEventHandler now returns Data marker so isComplete polls route correctly (#350)
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `migrationHandler`'s `onEventHandler` branch now returns `Data: { __migration: true }` alongside `PhysicalResourceId`.
10
+
11
+ ## Motivation
12
+
13
+ `cr.Provider` only propagates `Data` into `isComplete` events when `onEvent` returned a `Data` field. The previous implementation returned `{ PhysicalResourceId }` with no `Data`, so every `isComplete` poll also had no `Data`, causing the `"Data" in cfnEvent` discriminator to always take the `onEventHandler` short-circuit branch. The waiter loop never received `IsComplete: true` and ran until `totalTimeout` (default 2 h), then failed the stack.
14
+
15
+ ## Migration
16
+
17
+ No changes required. Consumers using `@jaypie/constructs@^1.2.56` and `@jaypie/lambda@^1.2.8` together will have working `JaypieMigration` deploys.
@@ -0,0 +1,12 @@
1
+ ---
2
+ version: 1.2.37
3
+ date: 2026-05-29
4
+ summary: Update Anthropic LARGE model constant to claude-opus-4-8
5
+ ---
6
+
7
+ ## @jaypie/llm 1.2.37
8
+
9
+ ### Changes
10
+
11
+ - **Model constants**: Updated Anthropic `LARGE` to `claude-opus-4-8`
12
+ - **Tests/CI**: Refreshed the Anthropic, OpenAI, and xAI model matrices to current releases
@@ -0,0 +1,13 @@
1
+ ---
2
+ version: 0.8.61
3
+ date: 2026-05-29
4
+ summary: Document @jaypie/dynamodb table-rebuild primitives and the table-rebuild migration pattern
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `skill("dynamodb")`: document `getClient`, `scanTable`, `countTable`,
10
+ `createTable`, and `destroyTable`, plus a "Rebuilding a table" section
11
+ covering the one-off, validated cutover from a 0.4.x table to the 0.5.0+
12
+ schema (distinct from the deploy-time `JaypieMigration` in
13
+ `skill("migrations")`).
@@ -0,0 +1,14 @@
1
+ ---
2
+ version: 0.8.62
3
+ date: 2026-05-31
4
+ summary: Document conditional transactWriteEntities and ConflictError in the dynamodb and errors skills
5
+ ---
6
+
7
+ ## Changed
8
+
9
+ - **`dynamodb` skill** documents `transactWriteEntities`' new
10
+ `conditionalCreate` / `condition` params and the atomic conditional-write
11
+ pattern.
12
+ - **`errors` skill** lists the new `ConflictError` (409).
13
+
14
+ Issue: [#357](https://github.com/finlaysonstudio/jaypie/issues/357)
@@ -0,0 +1,11 @@
1
+ ---
2
+ version: 1.2.39
3
+ date: 2026-05-29
4
+ summary: Mock the new @jaypie/dynamodb table-rebuild exports
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - Add mocks for `@jaypie/dynamodb` 0.6.2 exports: `getClient`, `scanTable`
10
+ (empty async generator), `countTable` (resolves `0`), `createTable`
11
+ (resolves a success result), and `destroyTable`.
@@ -0,0 +1,18 @@
1
+ ---
2
+ version: 1.2.40
3
+ date: 2026-05-31
4
+ summary: Mock the new ConflictError and the conditional transactWriteEntities signature
5
+ ---
6
+
7
+ ## Added
8
+
9
+ - **`ConflictError` mock**. Re-exported from `@jaypie/testkit/mock` and mapped
10
+ in the mocked `errorFromStatusCode(409)`, matching the new
11
+ `@jaypie/errors` export.
12
+
13
+ ## Changed
14
+
15
+ - **`transactWriteEntities` mock signature** now accepts the optional
16
+ `conditionalCreate` and `condition` params added in `@jaypie/dynamodb` 0.6.3.
17
+
18
+ Issue: [#357](https://github.com/finlaysonstudio/jaypie/issues/357)
@@ -68,11 +68,23 @@ initClient({
68
68
  | Function | Description |
69
69
  |----------|-------------|
70
70
  | `initClient(config?)` | Initialize the DynamoDB client (call once) |
71
+ | `getClient()` | Get the raw client for control-plane ops (CreateTable/DeleteTable) |
71
72
  | `getDocClient()` | Get the initialized Document Client |
72
73
  | `getTableName()` | Get the configured table name |
73
74
  | `isInitialized()` | Check if client is initialized |
74
75
  | `resetClient()` | Reset client state (for testing) |
75
76
 
77
+ ### Scan and Table Administration
78
+
79
+ Schema-agnostic table operations that honor the `initClient` config (real AWS or local). These are the building blocks for table rebuilds.
80
+
81
+ | Function | Description |
82
+ |----------|-------------|
83
+ | `scanTable({ tableName?, pageSize? })` | Async generator yielding every raw item via a full `Scan` (paginates internally). Reads any table regardless of GSI shape -- pass the old table during a rebuild. |
84
+ | `countTable({ tableName? })` | Total item count via paginated `COUNT` scan (validation) |
85
+ | `createTable({ tableName?, billingMode?, wait? })` | Create a table with the registered-model GSI schema; waits until `ACTIVE` by default |
86
+ | `destroyTable({ tableName })` | Delete a table; `tableName` required (no default) |
87
+
76
88
  ### Constants
77
89
 
78
90
  | Constant | Value | Description |
@@ -163,6 +175,27 @@ await destroyEntity({ id: "abc-123" });
163
175
  | `deleteEntity({ id })` | Soft delete (`deletedAt`, `#deleted` suffix on GSI pk) |
164
176
  | `archiveEntity({ id })` | Archive (`archivedAt`, `#archived` suffix on GSI pk) |
165
177
  | `destroyEntity({ id })` | Hard delete (permanent) |
178
+ | `transactWriteEntities({ entities, conditionalCreate?, condition? })` | Write many entities atomically; `conditionalCreate: true` guards every `Put` with `attribute_not_exists(id)` (`condition` for a custom expression), throwing `ConflictError` (409) when a conditional check fails |
179
+
180
+ ### Atomic Conditional Writes
181
+
182
+ Use `conditionalCreate` to write an entity **and** a uniqueness-sentinel row in a single transaction -- both commit or neither does:
183
+
184
+ ```typescript
185
+ import { ConflictError, transactWriteEntities } from "@jaypie/dynamodb";
186
+
187
+ try {
188
+ await transactWriteEntities({
189
+ conditionalCreate: true, // attribute_not_exists(id) on every Put
190
+ entities: [organization, aliasLock],
191
+ });
192
+ } catch (error) {
193
+ if (error instanceof ConflictError) {
194
+ // alias already claimed -- map to 409
195
+ }
196
+ throw error;
197
+ }
198
+ ```
166
199
 
167
200
  ### Scope and Hierarchy
168
201
 
@@ -439,6 +472,30 @@ Version 0.5.0 is a breaking change. **Tables must be recreated** (pre-1.0 breaki
439
472
  | `DEFAULT_INDEXES` implicit fallback | Must `registerModel()` with `fabricIndex()` before querying |
440
473
  | Callers set `createdAt`/`updatedAt` | `indexEntity` manages both automatically |
441
474
 
475
+ ### Rebuilding a table
476
+
477
+ The 0.5.0 primary-key change cannot be applied in place (DynamoDB cannot alter a primary key). The migration is a one-off, human-in-the-loop cutover to a new physical table, validated before destroying the old one. Run it once per environment, not as a deploy step. (Distinct from `JaypieMigration` in `skill("migrations")`, which runs CDK custom resources on every deploy.)
478
+
479
+ Cutover (CDK-managed table name, maintenance window):
480
+
481
+ 1. Deploy the new table alongside the old (CDK).
482
+ 2. Pause writes so the copy can't go stale.
483
+ 3. Run a script: `scanTable({ tableName: OLD })` → transform → `updateEntity` (writes to the new table = the `initClient` singleton).
484
+ 4. Validate: `countTable(NEW)` matches `countTable(OLD)`; spot-check records.
485
+ 5. Flip `DYNAMODB_TABLE_NAME` (via `CDK_ENV`) to the new table and deploy; resume.
486
+ 6. `destroyTable({ tableName: OLD })` later, once confident (it is your rollback until then).
487
+
488
+ ```ts
489
+ initClient({ tableName: NEW }); // singleton → destination
490
+ await createTable({ tableName: NEW }); // new schema, waits ACTIVE
491
+ for await (const item of scanTable({ tableName: OLD })) {
492
+ const { sequence, pk, sk, ...rest } = item; // 0.4 → 0.6 transform
493
+ await updateEntity({ entity: rest }); // re-indexes + re-timestamps
494
+ }
495
+ ```
496
+
497
+ `scanTable` issues a raw `Scan`, so it reads the old table despite its mismatched GSIs; the transform is yours (field semantics are app-specific).
498
+
442
499
  ## See Also
443
500
 
444
501
  - **`skill("apikey")`** - API key hash storage in DynamoDB
package/skills/errors.md CHANGED
@@ -29,6 +29,7 @@ throw new ConfigurationError("Missing API key");
29
29
  | UnauthorizedError | 401 | Authentication required |
30
30
  | ForbiddenError | 403 | Authenticated but not permitted |
31
31
  | NotFoundError | 404 | Resource doesn't exist |
32
+ | ConflictError | 409 | Request conflicts with current state (e.g. uniqueness violation) |
32
33
  | ConfigurationError | 500 | Missing or invalid config |
33
34
  | InternalError | 500 | Unexpected server error |
34
35