@aws/nx-plugin-mcp 1.0.0-rc.67 → 1.0.0-rc.69

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/bin/aws-nx-mcp.js CHANGED
@@ -54177,6 +54177,13 @@ var generators$1 = {
54177
54177
  "metric": "g70",
54178
54178
  "hidden": true
54179
54179
  },
54180
+ "agentcore-harness": {
54181
+ "factory": "./src/agentcore-harness/generator",
54182
+ "schema": "./src/agentcore-harness/schema.json",
54183
+ "description": "Generate an AgentCore Harness project",
54184
+ "metric": "g71",
54185
+ "guidePages": ["agentcore-harness"]
54186
+ },
54180
54187
  "connection": {
54181
54188
  "factory": "./src/connection/generator",
54182
54189
  "schema": "./src/connection/schema.json",
@@ -0,0 +1,275 @@
1
+ ---
2
+ title: AgentCore Harness
3
+ description: Create an Amazon Bedrock AgentCore Harness project
4
+ generator: agentcore-harness
5
+ ---
6
+
7
+ import { FileTree } from '@astrojs/starlight/components';
8
+ import GeneratorParameters from '@components/generator-parameters.astro';
9
+ import Infrastructure from '@components/infrastructure.astro';
10
+ import Link from '@components/link.astro';
11
+ import NxCommands from '@components/nx-commands.astro';
12
+ import RunGenerator from '@components/run-generator.astro';
13
+ import Snippet from '@components/snippet.astro';
14
+
15
+ Generate an [Amazon Bedrock AgentCore Harness](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness.html) project. A Harness is a managed agent loop powered by Strands Agents: it owns deployment defaults for the model, system prompt, tools, memory, skills, environments, truncation, authorization, and execution limits, while the service accepts per-invocation overrides for supported fields. Reusing the same Runtime Session ID continues the same Harness session.
16
+
17
+ ## Usage
18
+
19
+ ### Generate an AgentCore Harness
20
+
21
+ <RunGenerator generator="agentcore-harness" />
22
+
23
+ ### Options
24
+
25
+ <GeneratorParameters generator="agentcore-harness" />
26
+
27
+ ## Generator Output
28
+
29
+ The generator creates a standalone project at `packages/<name>/`. Because AWS runs the agent loop for you, the project holds only the prompt that shapes it and a script for talking to it:
30
+
31
+ <FileTree>
32
+ - packages/\<name>/
33
+ - src/PROMPT.md The Harness system prompt
34
+ - scripts/chat.ts Multi-turn chat client for the deployed Harness
35
+ - project.json Adds the `chat` target
36
+ - README.md Chat and customization instructions
37
+ </FileTree>
38
+
39
+ ### Infrastructure
40
+
41
+ Infrastructure is generated when `infra` is `agentcore` (the default). With `infra: none` no infrastructure is generated — set `HARNESS_ARN` to invoke a Harness managed elsewhere, and re-run the generator with `infra: agentcore` later to add infrastructure; existing project files (including your edits) are preserved.
42
+
43
+ <Snippet name="shared-constructs" />
44
+
45
+ <Infrastructure>
46
+ <Fragment slot="cdk">
47
+ <FileTree>
48
+ - packages/common/constructs/src/app/harnesses/\<name>/
49
+ - \<name>.ts CDK construct containing the Harness and execution role
50
+ </FileTree>
51
+ </Fragment>
52
+ <Fragment slot="terraform">
53
+ <FileTree>
54
+ - packages/common/terraform/src/app/harnesses/\<name>/
55
+ - \<name>.tf Terraform module containing the Harness and execution role
56
+ </FileTree>
57
+ </Fragment>
58
+ </Infrastructure>
59
+
60
+ The generated infrastructure manages the Harness through the native resource (CDK `aws_bedrockagentcore.CfnHarness`, Terraform `aws_bedrockagentcore_harness`) with your generated defaults, creates an IAM execution role with the baseline permissions described below, and uses IAM inbound authorization (no custom JWT authorizer is configured by default).
61
+
62
+ The Harness ARN is registered at `agentcore.harnesses.<ClassName>` in <Link path="guides/runtime-config">Runtime Configuration</Link>, preserving any existing entries.
63
+
64
+ ## Deploying your AgentCore Harness
65
+
66
+ The generator creates CDK or Terraform infrastructure as code based on your selected `iac` provider. You can use this to deploy your Harness through your usual infrastructure workflow.
67
+
68
+ <Infrastructure>
69
+ <Fragment slot="cdk">
70
+ The CDK construct for deploying your Harness lives in the `common/constructs` folder. Instantiate it from a CDK application:
71
+
72
+ ```ts title="packages/infra/src/stacks/application-stack.ts"
73
+ import { MyHarness } from '@my-scope/common-constructs';
74
+ import { Stack, type StackProps } from 'aws-cdk-lib';
75
+ import type { Construct } from 'constructs';
76
+
77
+ export class ApplicationStack extends Stack {
78
+ constructor(scope: Construct, id: string, props?: StackProps) {
79
+ super(scope, id, props);
80
+
81
+ new MyHarness(this, 'MyHarness');
82
+ }
83
+ }
84
+ ```
85
+
86
+ The construct's props interface (`MyHarnessProps`) extends `Partial<Omit<CfnHarnessProps, 'executionRoleArn' | 'allowedTools'>>`, so any native Harness property can be supplied and takes precedence over the generated defaults:
87
+
88
+ ```ts
89
+ const harness = new MyHarness(this, 'MyHarness', {
90
+ maxIterations: 20,
91
+ timeoutSeconds: 600,
92
+ });
93
+ ```
94
+
95
+ The construct also accepts:
96
+
97
+ - `allowedTools` — the tools the Harness may use. The Harness deploys with none unless you supply them, see <a href="#configuring-tools">Configuring tools</a>.
98
+ - `executionRole` — an existing IAM role to use instead of the generated role. A supplied role is used as-is: the baseline permissions are not added to it, and its ARN always feeds the Harness (the raw `executionRoleArn` string cannot be overridden).
99
+ - `modelResourceArns` — the Bedrock model and inference-profile ARNs the generated execution role may invoke, replacing the default list.
100
+ - `vpc`, `vpcSubnets` and `securityGroups` — run the Harness in a VPC so it can reach private resources, see <a href="#running-in-a-vpc">Running in a VPC</a>.
101
+
102
+ Its public members are `harness` (the `CfnHarness`), `executionRole`, `grantPrincipal`, the `harnessArn` getter, `connections` (in a VPC), `addToRolePolicy(statement)` for execution role extensions, and `grantInvokeAccess(grantee)` for authorizing callers.
103
+
104
+ Deploy the stack with your infrastructure project as usual — see the <Link path="guides/typescript-infrastructure">CDK infrastructure guide</Link>.
105
+ </Fragment>
106
+ <Fragment slot="terraform">
107
+ The Terraform module for deploying your Harness is in the `common/terraform` folder. Reference it from a Terraform configuration:
108
+
109
+ ```hcl title="packages/infra/src/main.tf"
110
+ module "my_harness" {
111
+ source = "../../common/terraform/src/app/harnesses/my-harness"
112
+ }
113
+ ```
114
+
115
+ The module exposes three variables:
116
+
117
+ - `model_id` — the Bedrock model or inference profile the Harness uses by default.
118
+ - `model_resource_arns` — the Bedrock model and inference-profile ARNs the execution role may invoke, replacing the default list.
119
+ - `additional_execution_role_policy_statements` — a list of IAM statement objects (`Effect`, `Action`, `Resource`, optional `Sid` and `Condition`) appended to the execution role policy.
120
+
121
+ Everything else is configured on the generated `aws_bedrockagentcore_harness` resource in the module itself.
122
+
123
+ The module outputs `harness_id`, `harness_arn`, and `execution_role_arn`.
124
+
125
+ Deploy with your Terraform project's plan/apply workflow as usual — see the <Link path="guides/terraform-project">Terraform project guide</Link>.
126
+ </Fragment>
127
+ </Infrastructure>
128
+
129
+ :::note[System prompt visibility]
130
+ Your infrastructure reads `packages/<name>/src/PROMPT.md` when you synthesize (CDK) or plan (Terraform), so the prompt is deployment configuration rather than secret storage: its contents appear in the synthesized CloudFormation template or in Terraform state.
131
+ :::
132
+
133
+ ## Granting access to invoke the harness
134
+
135
+ You can grant a caller permissions to invoke the harness as follows:
136
+
137
+ <Infrastructure>
138
+ <Fragment slot="cdk">
139
+ ```ts
140
+ const harness = new MyHarness(this, 'MyHarness');
141
+
142
+ harness.grantInvokeAccess(caller);
143
+ ```
144
+ </Fragment>
145
+ <Fragment slot="terraform">
146
+ ```hcl
147
+ # Attach to the calling principal's role
148
+ resource "aws_iam_role_policy" "invoke_my_harness" {
149
+ name = "InvokeMyHarness"
150
+ role = aws_iam_role.caller.id
151
+
152
+ policy = jsonencode({
153
+ Version = "2012-10-17"
154
+ Statement = [{
155
+ Effect = "Allow"
156
+ Action = [
157
+ "bedrock-agentcore:InvokeHarness",
158
+ "bedrock-agentcore:InvokeAgentRuntime",
159
+ ]
160
+ Resource = [module.my_harness.harness_arn]
161
+ }]
162
+ })
163
+ }
164
+ ```
165
+ </Fragment>
166
+ </Infrastructure>
167
+
168
+ A caller needs both `bedrock-agentcore:InvokeHarness` and `bedrock-agentcore:InvokeAgentRuntime` on the Harness ARN, which is exactly what `grantInvokeAccess` grants.
169
+
170
+ ## Chatting with your Harness
171
+
172
+ The generated `chat` target runs `scripts/chat.ts`, dropping you into an interactive terminal chat with your deployed Harness:
173
+
174
+ <NxCommands commands={['run <project>:chat']} />
175
+
176
+ Every turn of a run shares one session, so the Harness keeps the conversation context until you exit. Credentials come from the standard AWS SDK credential provider chain, and the AWS Region is derived from the Harness ARN.
177
+
178
+ The Harness ARN is resolved in this order:
179
+
180
+ 1. `HARNESS_ARN` (non-empty): used directly, without reading Runtime Configuration:
181
+
182
+ <NxCommands commands={['run <project>:chat']} env={{ HARNESS_ARN: '<harness-arn>' }} />
183
+
184
+ 2. `RUNTIME_CONFIG_APP_ID`: resolves the ARN from the `agentcore.harnesses.<ClassName>` entry published by the deployed infrastructure:
185
+
186
+ <NxCommands commands={['run <project>:chat']} env={{ RUNTIME_CONFIG_APP_ID: '<application-id>' }} />
187
+
188
+ With neither set, the script fails with an error naming both options.
189
+
190
+ ## Customizing your Harness
191
+
192
+ `src/PROMPT.md` is the Harness system prompt: edit it and redeploy to change how the Harness behaves. Everything else is configured where you instantiate the infrastructure, or by editing the generated construct or module directly. Re-running the generator never overwrites existing files (it only adds missing files and merges project metadata), so your edits to the prompt and to the generated infrastructure are preserved.
193
+
194
+ <Infrastructure>
195
+ <Fragment slot="cdk">
196
+ Every native Harness property of the pinned `aws-cdk-lib/aws-bedrockagentcore` module is available through the construct's props — alternate model providers, tool definitions, memory, skills, environment configuration, truncation, custom JWT authorization, and execution limits — and explicit props take precedence over the generated defaults. Alternatively, edit the generated construct in `packages/common/constructs/src/app/harnesses/<name>/<name>.ts`.
197
+ </Fragment>
198
+ <Fragment slot="terraform">
199
+ The generated module keeps the native `aws_bedrockagentcore_harness` resource directly editable, so provider-native fields — alternate model providers (`gemini_model_config`, `openai_model_config`), `tool` blocks, `memory`, `skill` blocks, environments (`environment`, `environment_variables`, `environment_artifact`), `truncation`, and `authorizer_configuration` with a `custom_jwt_authorizer` — are configured by editing `packages/common/terraform/src/app/harnesses/<name>/<name>.tf`.
200
+ </Fragment>
201
+ </Infrastructure>
202
+
203
+ Omitting authorizer configuration (the default) means IAM inbound authorization; configure a custom JWT authorizer through the native field to change that.
204
+
205
+ ### Configuring tools
206
+
207
+ The Harness deploys with no tools, so it starts with the least capability. Opt in to the tools it may use:
208
+
209
+ <Infrastructure>
210
+ <Fragment slot="cdk">
211
+ ```ts
212
+ new MyHarness(this, 'Harness', { allowedTools: ['@builtin'] });
213
+ ```
214
+ </Fragment>
215
+ <Fragment slot="terraform">
216
+ ```hcl title="packages/common/terraform/src/app/harnesses/my-harness/my-harness.tf"
217
+ resource "aws_bedrockagentcore_harness" "this" {
218
+ # ...
219
+ allowed_tools = ["@builtin"]
220
+ }
221
+ ```
222
+
223
+ Add an `allowed_tools` variable to the module if you would rather set it as a module argument where you reference the module.
224
+ </Fragment>
225
+ </Infrastructure>
226
+
227
+ Narrow `@builtin` to specific patterns such as `@builtin/file_operations` to restrict what the agent loop can do. See [Harness tools](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-tools.html) for the built-in tools you can add.
228
+
229
+ ### Running in a VPC
230
+
231
+ <Infrastructure>
232
+ <Fragment slot="cdk">
233
+ Supply a `vpc` to run the Harness inside it, so it can reach private resources such as a database. The construct implements `IConnectable`, so those resources grant it access the same way they would any other:
234
+
235
+ ```ts
236
+ const harness = new MyHarness(this, 'MyHarness', { vpc });
237
+
238
+ database.connections.allowDefaultPortFrom(harness, 'Harness to database');
239
+ ```
240
+
241
+ The Harness is placed in the VPC's private subnets with egress, in a security group created for it. Override either with `vpcSubnets` and `securityGroups`. Both require `vpc`, and `connections` is only available when the Harness runs in a VPC.
242
+ </Fragment>
243
+ <Fragment slot="terraform">
244
+ Add a `network_configuration` block to the generated `aws_bedrockagentcore_harness` resource's `environment.agent_core_runtime_environment`, then reference the security group you place it in from your other resources' rules:
245
+
246
+ ```hcl title="packages/common/terraform/src/app/harnesses/my-harness/my-harness.tf"
247
+ resource "aws_security_group" "harness" {
248
+ vpc_id = var.vpc_id
249
+ }
250
+
251
+ resource "aws_bedrockagentcore_harness" "this" {
252
+ # ...
253
+ environment {
254
+ agent_core_runtime_environment {
255
+ network_configuration {
256
+ network_mode = "VPC"
257
+ network_mode_config {
258
+ security_groups = [aws_security_group.harness.id]
259
+ subnets = var.subnet_ids
260
+ }
261
+ }
262
+ }
263
+ }
264
+ }
265
+ ```
266
+ </Fragment>
267
+ </Infrastructure>
268
+
269
+ ### Per-invocation overrides
270
+
271
+ The values configured in infrastructure are deployment defaults. The service also accepts per-invocation overrides for supported Harness fields (such as models, tools, and skills) in the `InvokeHarness` request; deployment defaults apply wherever a field is not overridden.
272
+
273
+ :::caution[Validate invocation overrides]
274
+ Per-invocation overrides are trusted inputs at the service boundary: any authorized caller can override supported fields. If untrusted users can reach an application that forwards overrides to `InvokeHarness`, validate and authorize them at the application layer (for example, allowlist models and tools), keep the execution role scoped to required resources, and do not grant `bedrock-agentcore:InvokeAgentRuntimeCommand` unless you specifically need it.
275
+ :::
@@ -86,6 +86,14 @@ When run without `--all`, the script only translates files that have changed
86
86
  since the last translation commit on the current branch — meaning you can
87
87
  safely re-run it on every docs PR without re-translating the whole site.
88
88
 
89
+ Translations whose source file no longer exists are deleted, so renaming or
90
+ removing a page does not leave stale copies behind in each locale.
91
+
92
+ Each translation is written as a whole file. The agent is given the source, the
93
+ existing translation, and a diff of what changed, and reuses the existing
94
+ wording for sections the diff left alone — so only prose the diff touched is
95
+ retranslated, and code blocks are copied from the source as-is.
96
+
89
97
  ### Configuring translation
90
98
 
91
99
  Edit `scripts/translate.config.json` to change:
package/generators.json CHANGED
@@ -44,6 +44,13 @@
44
44
  "metric": "g70",
45
45
  "hidden": true
46
46
  },
47
+ "agentcore-harness": {
48
+ "factory": "./src/agentcore-harness/generator",
49
+ "schema": "./src/agentcore-harness/schema.json",
50
+ "description": "Generate an AgentCore Harness project",
51
+ "metric": "g71",
52
+ "guidePages": ["agentcore-harness"]
53
+ },
47
54
  "connection": {
48
55
  "factory": "./src/connection/generator",
49
56
  "schema": "./src/connection/schema.json",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@aws/nx-plugin-mcp",
3
- "version": "1.0.0-rc.67",
3
+ "version": "1.0.0-rc.69",
4
4
  "repository": {
5
5
  "type": "git",
6
6
  "url": "https://github.com/awslabs/nx-plugin-for-aws.git",
@@ -0,0 +1,53 @@
1
+ {
2
+ "$schema": "https://json-schema.org/schema",
3
+ "$id": "agentcore-harness",
4
+ "title": "agentcore-harness",
5
+ "description": "Generate an Amazon Bedrock AgentCore Harness project",
6
+ "type": "object",
7
+ "properties": {
8
+ "name": {
9
+ "type": "string",
10
+ "description": "The name of your AgentCore Harness project. Must contain at least one non-whitespace character which can be normalized into a kebab-case project name (eg. my-harness).",
11
+ "$default": {
12
+ "$source": "argv",
13
+ "index": 0
14
+ },
15
+ "x-prompt": "What would you like to call your AgentCore Harness?",
16
+ "x-priority": "important",
17
+ "pattern": "\\S"
18
+ },
19
+ "directory": {
20
+ "type": "string",
21
+ "description": "Parent directory where the harness project is placed. Defaults to packages. Must be a relative path which does not contain parent directory (..) segments.",
22
+ "x-priority": "important",
23
+ "pattern": "^(?![A-Za-z]:)(?![\\\\/])(?!.*(?:^|[\\\\/])\\.\\.(?:[\\\\/]|$))(?=.*\\S).+$"
24
+ },
25
+ "subDirectory": {
26
+ "type": "string",
27
+ "description": "The sub directory the project is placed in. Defaults to the kebab-case harness name. Must be a relative path which does not contain parent directory (..) segments.",
28
+ "x-priority": "important",
29
+ "pattern": "^(?![A-Za-z]:)(?![\\\\/])(?!.*(?:^|[\\\\/])\\.\\.(?:[\\\\/]|$))(?=.*\\S).+$"
30
+ },
31
+ "infra": {
32
+ "type": "string",
33
+ "description": "The type of infrastructure to generate for hosting your harness. Defaults to agentcore. Select none for no hosting.",
34
+ "x-prompt": "How would you like to host your harness?",
35
+ "x-priority": "important",
36
+ "enum": ["agentcore", "none"],
37
+ "default": "agentcore"
38
+ },
39
+ "iac": {
40
+ "type": "string",
41
+ "description": "The preferred IaC provider for generated harness infrastructure. Defaults to inherit, which uses the provider configured for your workspace.",
42
+ "x-prompt": "Which provider would you like to manage your infrastructure? (default: inherit)",
43
+ "x-priority": "important",
44
+ "enum": ["inherit", "cdk", "terraform"],
45
+ "default": "inherit"
46
+ },
47
+ "preferInstallDependencies": {
48
+ "type": "boolean",
49
+ "description": "Whether to prefer installing dependencies after the generator runs. Defaults to true. 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."
50
+ }
51
+ },
52
+ "required": ["name"]
53
+ }