@aws/nx-plugin-mcp 1.0.0-rc.43 → 1.0.0-rc.45

package/docs/guides/typescript-infrastructure.mdx

@@ -43,7 +43,7 @@ The generator will create the following project structure in the `<directory>/<n
 
 </FileTree>
 
-If you set the `enableStageConfig` option, the generator also creates two shared packages for centralized credential management (if they don't already exist):
+If you set the `stageConfig` option, the generator also creates two shared packages for centralized credential management (if they don't already exist):
 
 <FileTree>
 
@@ -99,9 +99,9 @@ new ApplicationStage(app, 'my-app-sandbox', {
 
 The `env` property tells CDK which AWS account and region to deploy to. `CDK_DEFAULT_ACCOUNT` and `CDK_DEFAULT_REGION` are resolved automatically by the CDK CLI from your active AWS credentials. See the [CDK environments documentation](https://docs.aws.amazon.com/cdk/v2/guide/environments.html) for more details.
 
-If you generated with `enableStageConfig`, the `main.ts` reads account and region from a centralized config file instead, falling back to environment variables when no config is set:
+If you generated with `stageConfig`, the `main.ts` reads account and region from a centralized config file instead, falling back to environment variables when no config is set:
 
-```ts title="src/main.ts (with enableStageConfig)"
+```ts title="src/main.ts (with stageConfig)"
 import stagesConfig from ':my-scope/common-infra-config';
 
 const projectStages = stagesConfig.projects?.['packages/infra']?.stages ?? {};
@@ -158,12 +158,12 @@ export class ApplicationStage extends Stage {
 ### Stage Credential Configuration
 
 :::note[Staged Configuration]
-This section applies when you generate with `enableStageConfig`. Without it, the generator produces a simpler setup where you manage AWS credentials yourself (e.g., by exporting `AWS_PROFILE` before deploying).
+This section applies when you generate with `stageConfig`. Without it, the generator produces a simpler setup where you manage AWS credentials yourself (e.g., by exporting `AWS_PROFILE` before deploying).
 :::
 
 When you have multiple stages targeting different AWS accounts, managing credentials manually can be error-prone, especially as the number of stages grows.
 
-The `enableStageConfig` option solves this by generating two shared packages:
+The `stageConfig` option solves this by generating two shared packages:
 
 - **`packages/common/infra-config`** — A single config file where you map each stage to its AWS credentials, account, and region. This is importable from any package in your workspace, so your CDK `main.ts` can read account and region from the same source of truth.
 - **`packages/common/scripts`** — `infra-deploy` and `infra-destroy` commands that wrap CDK with automatic credential resolution. When you run `deploy`, the script reads the config, sets the right AWS environment variables for the CDK child process, and runs `cdk deploy`. Your shell environment is never modified.
@@ -375,7 +375,7 @@ After a build, you can deploy your infrastructure to AWS using the `deploy` targ
 Use the `deploy-ci` target if deploying in a CI/CD pipeline. See below for more details.
 :::
 
-First, make sure you have AWS credentials configured. If you generated with `enableStageConfig` and have configured stage credentials in `packages/common/infra-config/src/stages.config.ts`, the deploy command will automatically resolve and apply the correct credentials for the target stage. Otherwise, ensure your AWS credentials are set in your environment (e.g., via `AWS_PROFILE` or environment variables). See the [AWS credentials documentation](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) for the available options.
+First, make sure you have AWS credentials configured. If you generated with `stageConfig` and have configured stage credentials in `packages/common/infra-config/src/stages.config.ts`, the deploy command will automatically resolve and apply the correct credentials for the target stage. Otherwise, ensure your AWS credentials are set in your environment (e.g., via `AWS_PROFILE` or environment variables). See the [AWS credentials documentation](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) for the available options.
 
 Then run the deploy target:
 

package/docs/snippets/lambda-function/deploying-your-function.mdx

@@ -3,7 +3,7 @@ title: Deploying your Function
 ---
 import Infrastructure from '@components/infrastructure.astro';
 
-This generator creates CDK or Terraform infrastructure as code based on your selected `iacProvider`. You can use this to deploy your function.
+This generator creates CDK or Terraform infrastructure as code based on your selected `iac`. You can use this to deploy your function.
 
 <Infrastructure>
 <Fragment slot="cdk">

package/docs/snippets/rdb/deploying.mdx

@@ -5,7 +5,7 @@ import Infrastructure from '@components/infrastructure.astro';
 import Link from '@components/link.astro';
 import Drawer from '@components/drawer.astro';
 
-The relational database generator creates CDK or Terraform infrastructure based on your selected `iacProvider`.
+The relational database generator creates CDK or Terraform infrastructure based on your selected `iac`.
 
 <Infrastructure>
 <Fragment slot="cdk">

package/docs/snippets/runtime-config-app-id-note.mdx

@@ -0,0 +1,8 @@
+---
+title: Runtime Config App ID Note
+---
+import Link from '@components/link.astro';
+
+:::note[Runtime config]
+This relies on the `RUNTIME_CONFIG_APP_ID` environment variable to fetch configuration from AWS AppConfig at runtime. Projects built with this plugin (APIs, Agents, MCP servers) already have this variable configured automatically. For other projects, ensure `RUNTIME_CONFIG_APP_ID` is set in the runtime environment with the AppConfig application ID provisioned by your infrastructure. For more information, see the <Link path="guides/runtime-config">Runtime Configuration guide</Link>.
+:::

package/docs/snippets/shared-constructs.mdx

@@ -5,7 +5,7 @@ import { FileTree } from '@astrojs/starlight/components';
 import Infrastructure from '@components/infrastructure.astro';
 import Link from '@components/link.astro';
 
-Since this generator vends infrastructure as code based on your chosen `iacProvider`, it will create a project in `packages/common` which includes the relevant CDK constructs or Terraform modules.
+Since this generator vends infrastructure as code based on your chosen `iac`, it will create a project in `packages/common` which includes the relevant CDK constructs or Terraform modules.
 
 The common infrastructure as code project is structured as follows:
 

package/docs/snippets/trivy-image-scan.mdx

@@ -2,11 +2,21 @@
 title: Container Image Scanning
 ---
 
-The Docker image built for this project is scanned for vulnerabilities as part of the build using [Trivy](https://trivy.dev/), running from the [ECR-hosted Trivy image](https://gallery.ecr.aws/aquasecurity/trivy).
+import PackageManagerShortCommand from '@components/package-manager-short-command.astro';
 
-A `trivy` target is added to your project which scans the built image and **fails the build** if any `HIGH` or `CRITICAL` severity vulnerability is found. The generated `Dockerfile` uses a base image with no known fixable vulnerabilities of these severities at time of generation, and upgrades bundled tooling (such as `npm`) to keep it that way.
+The Docker image built for this project can be scanned for vulnerabilities using [Trivy](https://trivy.dev/), running from the [ECR-hosted Trivy image](https://gallery.ecr.aws/aquasecurity/trivy).
 
-The scan uses the same container engine as your image build (`docker` or `finch`), so no additional tooling is required. Since the scan is only re-run when the image changes, an unchanged image is not re-scanned.
+A `trivy` target is added to your project which scans the built image and **exits non-zero** if any `HIGH` or `CRITICAL` severity vulnerability is found. The generated `Dockerfile` uses a base image with no known fixable vulnerabilities of these severities at time of generation, and upgrades bundled tooling (such as `npm`) to keep it that way.
+
+The scan uses the same container engine as your image build (`docker` or `finch`), so no additional tooling is required. Since the scan is only re-run when the image changes, an unchanged image is not re-scanned. The vended `trivy` root script scans every image in the workspace:
+
+<PackageManagerShortCommand commands={['trivy']} />
+
+:::tip[Run Trivy in CI]
+The scan is intentionally not wired into `build` since this can introduce unnecessary friction when iterating during development, as Trivy's vulnerabilty database is continually updated with new CVEs.
+
+Instead we recommend running the above command as a dedicated step in your CI pipeline prior to deployment to production stages.
+:::
 
 :::caution[Unfixable vulnerabilities are ignored]
 The scan runs with `--ignore-unfixed`, so vulnerabilities without an available fix do not fail the build, since they cannot be actioned by upgrading tooling in your `Dockerfile` — they are not reported in the build's scan output. As new vulnerabilities are disclosed the result of scans may change over time, so review the image periodically by running `trivy image <your-image>` without the flag, and rebuild against a newer base image (or add container steps to apply available patches) once a fix is published.

package/generators.json

@@ -211,6 +211,12 @@
       "description": "Generate a TypeScript lambda function",
       "metric": "g21"
     },
+    "ts#dcr-proxy": {
+      "factory": "./src/ts/dcr-proxy/generator",
+      "schema": "./src/ts/dcr-proxy/schema.json",
+      "description": "Generate an OAuth Dynamic Client Registration (DCR) proxy construct for Cognito-authenticated MCP servers",
+      "metric": "g56"
+    },
     "ts#mcp-server": {
       "factory": "./src/ts/mcp-server/generator",
       "schema": "./src/ts/mcp-server/schema.json",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws/nx-plugin-mcp",
-  "version": "1.0.0-rc.43",
+  "version": "1.0.0-rc.45",
   "repository": {
     "type": "git",
     "url": "https://github.com/awslabs/nx-plugin-for-aws.git",

package/src/agentcore-gateway/schema.json

@@ -33,9 +33,10 @@
     },
     "auth": {
       "type": "string",
-      "description": "The method used to authenticate inbound requests to your gateway. Only iam is supported today; cognito and custom-jwt may be added in future.",
-      "enum": ["iam"],
+      "description": "The method used to authenticate inbound requests to your gateway. Only applicable when infra is set (ignored when infra is none).",
+      "enum": ["iam", "cognito"],
       "default": "iam",
+      "x-prompt": "How would you like to authenticate inbound requests to your gateway?",
       "x-priority": "important"
     },
     "cedarPolicy": {

package/src/ts/dcr-proxy/schema.json

@@ -0,0 +1,44 @@
+{
+  "$schema": "https://json-schema.org/schema",
+  "$id": "ts#dcr-proxy",
+  "title": "ts#dcr-proxy",
+  "description": "Generate an OAuth Dynamic Client Registration (DCR) proxy construct for Cognito-authenticated MCP servers",
+  "type": "object",
+  "properties": {
+    "name": {
+      "type": "string",
+      "description": "The name of your DCR proxy, used for its TypeScript handler project, the construct/module class name, and its directory under common/constructs or common/terraform",
+      "default": "dcr-proxy",
+      "$default": {
+        "$source": "argv",
+        "index": 0
+      },
+      "x-prompt": "What would you like to call your DCR proxy?",
+      "x-priority": "important"
+    },
+    "directory": {
+      "description": "The directory to store the DCR proxy handler project in.",
+      "type": "string",
+      "alias": "dir",
+      "x-priority": "important",
+      "default": "packages"
+    },
+    "subDirectory": {
+      "type": "string",
+      "description": "The sub directory the handler project is placed in. By default this is the project name."
+    },
+    "iac": {
+      "type": "string",
+      "description": "The preferred IaC provider (cdk or terraform). By default this is inherited from your initial selection.",
+      "enum": ["inherit", "cdk", "terraform"],
+      "x-priority": "important",
+      "default": "inherit",
+      "x-prompt": "Which provider would you like to manage your infrastructure? (default: inherit)"
+    },
+    "preferInstallDependencies": {
+      "type": "boolean",
+      "description": "Whether to prefer installing dependencies after the generator runs. Set to false to defer installing when batching multiple generators (an install still runs if needed so subsequent generators can compute the Nx project graph); install once at the end.",
+      "default": true
+    }
+  }
+}