@aws/nx-plugin-mcp 1.0.0-rc.44 → 1.0.0-rc.46

package/docs/guides/ts-nx-plugin.mdx

@@ -55,14 +55,14 @@ The generator will create the following project structure:
 
 ### Adding Generators
 
-Once you have your plugin project, you can add generators using the <Link path="/guides/ts-nx-generator">`ts#nx-generator`</Link> generator:
+Once you have your plugin project, you can add generators using the <Link path="/guides/nx-generator">`ts#nx-generator`</Link> generator:
 
 <RunGenerator generator="ts#nx-generator" requiredParameters={{ pluginProject: 'your-plugin' }} />
 
 This will add a new generator to your plugin.
 
 :::tip[Generator Documentation]
-Read the <Link path="/guides/ts-nx-generator">`ts#nx-generator` guide</Link> for details about how to implement generators.
+Read the <Link path="/guides/nx-generator">`ts#nx-generator` guide</Link> for details about how to implement generators.
 :::
 
 Make sure to write a detailed `README.md` for your generator, since this is used by the MCP Server's `generator-guide` tool.

package/docs/guides/ts-smithy-api.mdx

@@ -69,7 +69,7 @@ The generator creates two related projects in the `<directory>/<api-name>` direc
 
 ### Infrastructure
 
-Since this generator creates 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 creates 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:
 
@@ -581,7 +581,7 @@ The local server will not only hot-reload when you make TypeScript changes to yo
 
 ## Deploying your Smithy API
 
-The generator creates CDK or Terraform infrastructure based on your selected `iacProvider`.
+The generator creates CDK or Terraform infrastructure based on your selected `iac`.
 
 <Infrastructure>
 <Fragment slot="cdk">
@@ -765,7 +765,7 @@ If you are actively working on both your CDK infrastructure and Smithy API toget
 </Fragment>
 <Fragment slot="terraform">
 :::note[Terraform Limitations]
-We do not support type-safe integrations for Terraform, and therefore no code generation targets are configured if you selected Terraform for your `iacProvider`.
+We do not support type-safe integrations for Terraform, and therefore no code generation targets are configured if you selected Terraform for your `iac`.
 :::
 </Fragment>
 </Infrastructure>

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,13 +99,14 @@ 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)"
-import stagesConfig from ':my-scope/common-infra-config';
+```ts title="src/main.ts (with stageConfig)"
+import { resolveStage } from ':my-scope/common-infra-config';
 
-const projectStages = stagesConfig.projects?.['packages/infra']?.stages ?? {};
-const sandboxConfig = projectStages['my-app-sandbox'];
+// Looks up the stage under this project (packages/infra), falling back to
+// shared stages. Returns undefined when no config exists for the stage.
+const sandboxConfig = resolveStage('packages/infra', 'my-app-sandbox');
 
 new ApplicationStage(app, 'my-app-sandbox', {
   env: {
@@ -158,12 +159,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.
@@ -242,7 +243,7 @@ Each stage config includes a required `region` and an optional `account`:
 The generated `main.ts` reads these values from the config so that CDK synthesis and deployment use the same environment settings:
 
 ```ts title="src/main.ts"
-const sandboxConfig = projectStages['my-app-sandbox'];
+const sandboxConfig = resolveStage('packages/infra', 'my-app-sandbox');
 new ApplicationStage(app, 'my-app-sandbox', {
   env: {
     account: sandboxConfig?.account ?? process.env.CDK_DEFAULT_ACCOUNT,
@@ -375,7 +376,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/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

@@ -7,7 +7,7 @@
       "factory": "./src/init/generator",
       "schema": "./src/init/schema.json",
       "description": "Configure an existing Nx workspace to use the @aws/nx-plugin",
-      "metric": "g57",
+      "metric": "g66",
       "guidePages": ["existing-project"]
     },
     "agentcore-gateway": {
@@ -27,7 +27,7 @@
       "factory": "./src/agentcore-gateway/gateway-connection/generator",
       "schema": "./src/agentcore-gateway/gateway-connection/schema.json",
       "description": "Connect an AgentCore Gateway to another AgentCore Gateway",
-      "metric": "g52",
+      "metric": "g65",
       "hidden": true
     },
     "connection": {
@@ -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": "g67"
+    },
     "ts#mcp-server": {
       "factory": "./src/ts/mcp-server/generator",
       "schema": "./src/ts/mcp-server/schema.json",
@@ -242,7 +248,7 @@
       "factory": "./src/ts/website/app/generator",
       "schema": "./src/ts/website/app/schema.json",
       "description": "Generates a website application",
-      "metric": "g43",
+      "metric": "g60",
       "guidePages": ["website", "react-website"]
     },
     "ts#website#auth": {
@@ -399,27 +405,27 @@
       "factory": "./src/ts/dynamodb/generator",
       "schema": "./src/ts/dynamodb/schema.json",
       "description": "Create a TypeScript DynamoDB project",
-      "metric": "g43"
+      "metric": "g61"
     },
     "ts#dynamodb#trpc-connection": {
       "factory": "./src/ts/dynamodb/trpc-connection/generator",
       "schema": "./src/ts/dynamodb/trpc-connection/schema.json",
       "description": "Connect a ts#trpc-api project to a ts#dynamodb project",
-      "metric": "g44",
+      "metric": "g62",
       "hidden": true
     },
     "ts#dynamodb#smithy-connection": {
       "factory": "./src/ts/dynamodb/smithy-connection/generator",
       "schema": "./src/ts/dynamodb/smithy-connection/schema.json",
       "description": "Connect a Smithy backend to a ts#dynamodb project",
-      "metric": "g45",
+      "metric": "g63",
       "hidden": true
     },
     "ts#dynamodb#agent-connection": {
       "factory": "./src/ts/dynamodb/agent-connection/generator",
       "schema": "./src/ts/dynamodb/agent-connection/schema.json",
       "description": "Connect a ts#agent to a ts#dynamodb project",
-      "metric": "g46",
+      "metric": "g64",
       "hidden": true
     },
     "ts#dynamodb#mcp-server-connection": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws/nx-plugin-mcp",
-  "version": "1.0.0-rc.44",
+  "version": "1.0.0-rc.46",
   "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
+    }
+  }
+}