@aws/nx-plugin-mcp 1.0.0-rc.57 → 1.0.0-rc.59

package/docs/get_started/graph-builder.mdx

@@ -0,0 +1,37 @@
+---
+title: Graph Builder
+description: Design your workspace visually, then copy the commands that scaffold it.
+# The builder needs the full content width, which the table of contents column
+# would otherwise take.
+tableOfContents: false
+---
+import Link from '@components/link.astro';
+import GraphBuilder from '@components/graph-builder.astro';
+
+Sketch the projects your workspace needs and the connections between them, and the builder generates the commands that scaffold exactly what you drew. Copy them, run them, and you have a working workspace.
+
+Drag components from the palette onto the canvas, drag from a component's right edge to another to connect them, and edit each component's properties on the right. The generated commands at the bottom update with every change — hit **Copy** to take the whole script.
+
+<GraphBuilder />
+
+## How it works
+
+Each component on the canvas maps to a generator, and each connection to the <Link path="guides/connection">connection generator</Link>. The commands are emitted in dependency order: the workspace first, then the projects, then the components they host, then the connections wiring them together.
+
+A website always gets <Link path="guides/react-website-auth">Cognito authentication</Link> added straight after it, since `ts#website` leaves that to a follow-up generator.
+
+An `infra` project is added at the end — <Link path="guides/typescript-infrastructure">`ts#infra`</Link> or <Link path="guides/terraform-project">`terraform#project`</Link>, matching your IaC choice. Every generated project vends constructs for it to instantiate, so this is what you deploy. Because it owns that name, no component on the canvas can be called `infra`.
+
+Drag the canvas background to pan around, and drag a component to reposition it. Shift-click to select several components and move them as a group. Click a connection to select it, then press <kbd>Delete</kbd> to remove it (or use the ✕ on the connection itself).
+
+The palette lists every project and component type that can take part in a connection, and you can only draw the connections the plugin supports — so a graph that validates is a graph that scaffolds.
+
+Three rules are worth knowing:
+
+- **Components share a host project.** An agent and an MCP server are added _to_ a project rather than being projects of their own. Give them the same host project name to put them in one project, or different names for one project each.
+- **Some connections constrain their endpoints.** Connecting an agent to another agent requires the target to use the `a2a` protocol, for instance. Where a property setting would break a connection you have drawn, the builder says so against the component and the connection.
+- **Drawing a connection can adjust the target.** Connecting a website to an agent switches that agent to the `ag-ui` protocol, and connecting an agent to another agent switches the target to `a2a` — the protocols those connections are built on. A property you have set yourself is never changed.
+
+:::tip[Prefer to build with AI?]
+The plugin ships an MCP server, so your coding agent can scaffold and connect projects for you. See <Link path="get_started/building-with-ai">Building with AI</Link>.
+:::

package/docs/get_started/tutorials/contribute-generator.mdx

@@ -182,7 +182,7 @@ So we'll need to make sure we pass those to `generateFiles`, as well as the dire
 
 Let's update the generator to do that:
 
-```ts title="procedure/generator.ts" {8-19}
+```ts title="procedure/generator.ts" {16-30}
 import {
   generateFiles,
   joinPathFragments,
@@ -230,7 +230,7 @@ Next, we want the generator to hook up the new procedure to the router. This mea
 
 We use [GritQL](https://docs.grit.io/) to declaratively search and transform source code. The `addDestructuredImport` helper adds named imports, and `applyGritQL` applies a GritQL pattern to add the procedure to the router's object literal.
 
-```ts title="procedure/generator.ts" {6, 23-36}
+```ts title="procedure/generator.ts" {11, 33-46}
 import {
   generateFiles,
   joinPathFragments,

package/docs/get_started/tutorials/dungeon-game/1.mdx

@@ -120,7 +120,7 @@ Below is a list of all files which have been generated by the `ts#api` generator
 
 Let us look at these key files:
 
-```ts {5}
+```ts {7}
 // packages/game-api/src/router.ts
 import { echo } from './procedures/echo.js';
 import { t } from './init.js';
@@ -135,7 +135,7 @@ export type AppRouter = typeof appRouter;
 ```
 The router defines the tRPC router for your API and is the place where you will declare all of your API methods. As you can see above, we have a method called `echo` with it's implementation in the `./procedures/echo.ts` file. The Lambda handler entrypoint is in `handler.ts`, which is configured automatically by the generator.
 
-```ts {2-5}
+```ts {7-10}
 // packages/game-api/src/procedures/echo.ts
 import { publicProcedure } from '../init.js';
 import {

package/docs/guides/agentcore-gateway.mdx

@@ -15,7 +15,12 @@ import Link from '@components/link.astro';
 import NxCommands from '@components/nx-commands.astro';
 import OptionFilter from '@components/option-filter.astro';
 
-Generate an [Amazon Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) project. An AgentCore Gateway is a managed entry point that aggregates one or more MCP server targets behind a single MCP endpoint, authenticates inbound requests (IAM or Cognito), evaluates every tool call against a [Cedar policy engine](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html), and signs outbound traffic to MCP servers with IAM SigV4.
+Generate an [Amazon Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) project. An AgentCore Gateway is a managed entry point in front of your MCP servers or agents, authenticating inbound requests (IAM or Cognito) and signing outbound traffic to its targets with IAM SigV4.
+
+The `protocol` option selects what the Gateway fronts:
+
+- **`mcp`** (default) — aggregates one or more MCP server targets behind a single MCP endpoint, and evaluates every tool call against a [Cedar policy engine](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html).
+- **`http`** — proxies requests directly to [AgentCore Runtime targets](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-http-runtime.html) (your agents) via path-based routing (`/<targetName>/invocations`), without aggregation or protocol translation. Use this to front agents with a single governed endpoint — for example so a website can reach agents that are deployed inside a VPC through the Gateway.
 
 ## Usage
 
@@ -33,10 +38,10 @@ The generator creates a new project at `packages/<name>/`, plus a CDK construct
 
 <FileTree>
   - packages/\<name>/
-    - policies/ Cedar policy source files (omitted when `cedarPolicy: false`)
+    - policies/ Cedar policy source files (`mcp` protocol only; omitted when `cedarPolicy: false`)
       - permit-all.cedar Default Cedar policy that permits authenticated callers
       - README.md Reference for writing Cedar policies
-    - local-dev.ts Local gateway aggregating attached MCP servers for local development
+    - local-dev.ts Local gateway for local development — aggregates attached MCP servers (`mcp`) or proxies attached agents (`http`)
     - project.json Adds the `serve` and `dev` targets
 </FileTree>
 
@@ -71,9 +76,9 @@ Infrastructure is generated when `infra` is `agentcore` (the default). With `inf
 
 The generated construct creates the following AWS resources:
 
-- An `AgentCore::Gateway` configured for the MCP protocol with inbound IAM authentication (default) or Cognito JWT authentication (see <a href="#authentication">Authentication</a>)
-- An `AgentCore::PolicyEngine` running in `ENFORCE` mode, attached to the Gateway (omitted when `cedarPolicy: false`)
-- One `AgentCore::Policy` per `.cedar` file in `policies/`
+- An `AgentCore::Gateway` with inbound IAM authentication (default) or Cognito JWT authentication (see <a href="#authentication">Authentication</a>). An `mcp` gateway is configured for the MCP protocol; an `http` gateway has no protocol type, which AgentCore requires for its runtime targets
+- An `AgentCore::PolicyEngine` running in `ENFORCE` mode, attached to the Gateway (`mcp` gateways only; omitted when `cedarPolicy: false`)
+- One `AgentCore::Policy` per `.cedar` file in `policies/` (`mcp` gateways only)
 - An AWS WAFv2 Web ACL associated with the Gateway, with request logging to CloudWatch (enabled by default — see <a href="#aws-waf">AWS WAF</a>)
 
 The Gateway URL is automatically registered in the `agentcore.gateways.<ClassName>` namespace of <Link path="guides/runtime-config">Runtime Configuration</Link> so agents can discover it at runtime.
@@ -146,7 +151,7 @@ export class ApplicationStack extends Stack {
 <Fragment slot="terraform">
 The generated module requires `user_pool_id` and `user_pool_client_ids` variables:
 
-```hcl {6-7} title="packages/infra/src/main.tf"
+```hcl {7-8} title="packages/infra/src/main.tf"
 module "user_identity" {
   source = "../../common/terraform/src/core/user-identity"
 }
@@ -207,7 +212,7 @@ Add new variables where the policies are rendered, for example to pass an agent'
 <Fragment slot="cdk">
 In `packages/common/constructs/src/app/gateways/<name>/<name>.ts`, pass `cedarPolicyVariables` through to the shared construct:
 
-```ts {4-6}
+```ts {5-6}
 super(scope, id, {
   cedarPolicyPath: path.join(
     ...
@@ -347,11 +352,19 @@ This denies the Python agent role from calling `ts-mcp___divide` while leaving t
 
 ## Local Development
 
-The generator adds a `dev` target to the Gateway project, which runs `local-dev.ts`: a local gateway exposing a single MCP endpoint that aggregates every attached MCP server (connected via the <Link path="guides/connection/agentcore-gateway-mcp">`agentcore-gateway#mcp-connection` generator</Link>), with tools prefixed `<target>___<tool>` to match the deployed Gateway. Running it starts the local gateway and all attached MCP servers together:
+The generator adds a `dev` target to the Gateway project, which runs `local-dev.ts`. Running it starts the local gateway and every attached target together:
 
 <NxCommands commands={["dev <name>"]} />
 
-See the connection guide for the full local development story.
+<OptionFilter when={{ protocol: 'mcp' }} description="MCP aggregator local gateway">
+The local gateway exposes a single MCP endpoint that aggregates every attached MCP server (connected via the <Link path="guides/connection/agentcore-gateway-mcp">`agentcore-gateway#mcp-connection` generator</Link>), with tools prefixed `<target>___<tool>` to match the deployed Gateway.
+</OptionFilter>
+
+<OptionFilter when={{ protocol: 'http' }} description="Path-routing proxy local gateway">
+The local gateway proxies `/<targetName>/...` paths to each attached agent's local server (connected via the <Link path="guides/connection/agentcore-gateway-agent">`agentcore-gateway#agent-connection` generator</Link>), matching the deployed Gateway's path-based routing.
+</OptionFilter>
+
+See the connection guides for the full local development story.
 
 ## Deploying your AgentCore Gateway
 
@@ -460,4 +473,18 @@ Use the <Link path="guides/connection">`connection`</Link> generator to integrat
     sourceBadge="python"
     target="agentcore"
   />
+  <ConnectionCard
+    title="AgentCore Gateway to Agent"
+    description="Front an agent with an AgentCore Gateway as a runtime target"
+    href={`/nx-plugin-for-aws/${Astro.currentLocale || 'en'}/guides/connection/agentcore-gateway-agent`}
+    source="agentcore"
+    target="strands"
+  />
+  <ConnectionCard
+    title="React Website to AgentCore Gateway"
+    description="Connect a React website to agents through an AgentCore Gateway"
+    href={`/nx-plugin-for-aws/${Astro.currentLocale || 'en'}/guides/connection/react-agentcore-gateway`}
+    source="react"
+    target="agentcore"
+  />
 </CardGrid>

package/docs/guides/connection/agentcore-gateway-agent.mdx

@@ -0,0 +1,282 @@
+---
+title: AgentCore Gateway to Agent
+description: Front an agent with an AgentCore Gateway as a runtime target
+when:
+  sourceType: agentcore-gateway
+  targetType:
+    - ts#agent
+    - py#agent
+---
+import { FileTree } from '@astrojs/starlight/components';
+import Link from '@components/link.astro';
+import RunGenerator from '@components/run-generator.astro';
+import GeneratorParameters from '@components/generator-parameters.astro';
+import NxCommands from '@components/nx-commands.astro';
+import Infrastructure from '@components/infrastructure.astro';
+
+The `connection` generator can register an agent (either <Link path="guides/ts-agent">TypeScript</Link> or <Link path="guides/py-agent">Python</Link>) as an [AgentCore Runtime target](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-http-runtime.html) of an <Link path="guides/agentcore-gateway">AgentCore Gateway</Link> generated with `protocol: http`.
+
+Once connected, the Gateway proxies requests for the agent under `<gatewayUrl>/<targetName>/invocations`, signing outbound traffic to the runtime with IAM SigV4. This gives your agents a single governed entry point — and since callers only need to reach the Gateway, the agent runtimes themselves can be deployed inside a VPC behind it.
+
+## Prerequisites
+
+Before using this generator, ensure you have:
+
+1. An <Link path="guides/agentcore-gateway">`agentcore-gateway`</Link> project generated with `protocol: http`
+2. An agent component (<Link path="guides/ts-agent">`ts#agent`</Link> or <Link path="guides/py-agent">`py#agent`</Link>) created with `infra: agentcore` and `auth: iam`
+
+:::caution[TypeScript HTTP agents]
+A TypeScript `http` agent serves tRPC over WebSocket, and AgentCore Gateway does not support WebSocket or bidirectional streaming — the generator rejects this combination. Generate the agent with the `ag-ui` protocol instead.
+:::
+
+## Usage
+
+### Run the Generator
+
+<RunGenerator generator="connection" />
+
+Select the Gateway project as the source and the agent project as the target. If the agent project contains multiple components, specify `targetComponent` to disambiguate.
+
+### Options
+
+<GeneratorParameters generator="connection" />
+
+## Generator Output
+
+The generator wires existing projects together rather than emitting new source files. The following files are modified:
+
+<FileTree>
+
+- packages/\<gateway>
+  - project.json the Gateway's `dev` target gains a dependency on the agent's `<agent>-dev`
+  - local-dev.ts `ATTACHED_AGENTS` updated so the local gateway proxies to the agent
+
+</FileTree>
+
+## Adding the agent target to your stack
+
+The generator **cannot** automatically wire the agent target into your infrastructure because it doesn't know which stack or module instantiates the Gateway. Add a single call to `gateway.addAgent(agent)` yourself.
+
+<Infrastructure>
+<Fragment slot="cdk">
+In the stack where you instantiate the Gateway, register the agent as a target:
+
+```ts title="packages/infra/src/stacks/application-stack.ts" {5-8}
+const myAgent = new MyAgent(this, 'MyAgent');
+const myGateway = new MyGateway(this, 'MyGateway');
+
+// Register the agent as a runtime target of the Gateway. The target name
+// defaults to the agent's `agentName` (its class name in kebab-case,
+// e.g. `MyAgent` -> `my-agent`), and forms the target's invocation path:
+// <gatewayUrl>/my-agent/invocations
+myGateway.addAgent(myAgent);
+```
+
+To override the default target name, pass `gatewayTargetName`:
+
+```ts
+myGateway.addAgent(myAgent, { gatewayTargetName: 'my-target' });
+```
+
+The construct grants the Gateway's execution role invoke access to the agent runtime and configures the target with the `GATEWAY_IAM_ROLE` credential provider, so the Gateway signs outbound calls with its own role.
+
+:::tip[Deploying agents into a VPC]
+Fronting an agent with a Gateway is what makes a VPC-deployed agent reachable: callers talk to the Gateway's public endpoint, and the Gateway reaches the runtime internally. Pass a VPC network configuration to the agent construct:
+
+```ts
+import { RuntimeNetworkConfiguration } from 'aws-cdk-lib/aws-bedrockagentcore';
+
+const myAgent = new MyAgent(this, 'MyAgent', {
+  networkConfiguration: RuntimeNetworkConfiguration.usingVpc(this, {
+    vpc,
+    vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
+  }),
+});
+```
+
+Use a **private subnet with egress**, not a private isolated subnet: the runtime needs outbound internet access to reach Bedrock and read its configuration from AWS AppConfig.
+:::
+</Fragment>
+<Fragment slot="terraform">
+In the Terraform file where you instantiate the Gateway, wire the agent target in:
+
+```hcl title="packages/infra/src/main.tf" {9-20,24-40}
+module "my_agent" {
+  source = "../../common/terraform/src/app/agents/my-agent"
+  # ...
+}
+
+module "my_gateway" {
+  source = "../../common/terraform/src/app/gateways/my-gateway"
+
+  # The Gateway signs outbound calls to the runtime with its own role and
+  # validates access at target creation, so it needs invoke access first.
+  additional_iam_policy_statements = [
+    {
+      Effect = "Allow"
+      Action = [
+        "bedrock-agentcore:InvokeAgentRuntime",
+        "bedrock-agentcore:InvokeAgentRuntimeWithWebSocketStream",
+        # A2A targets additionally serve their agent card via the gateway
+        "bedrock-agentcore:GetAgentCard",
+      ]
+      Resource = [
+        module.my_agent.agent_core_runtime_arn,
+        "${module.my_agent.agent_core_runtime_arn}/*",
+      ]
+    }
+  ]
+}
+
+# Register the agent as a runtime target of the Gateway. The target name
+# forms the invocation path: <gatewayUrl>/my-agent/invocations
+resource "aws_bedrockagentcore_gateway_target" "my_agent" {
+  gateway_identifier = module.my_gateway.gateway_id
+  name               = "my-agent"
+  # AgentCore fills in a description when none is set, which the provider
+  # reports as an inconsistent result after apply — so always set one.
+  description = "Agent runtime target my-agent"
+
+  target_configuration {
+    http {
+      agentcore_runtime {
+        arn = module.my_agent.agent_core_runtime_arn
+      }
+    }
+  }
+
+  credential_provider_configuration {
+    gateway_iam_role {}
+  }
+}
+```
+
+:::tip[Deploying agents into a VPC]
+Fronting an agent with a Gateway is what makes a VPC-deployed agent reachable: callers talk to the Gateway's public endpoint, and the Gateway reaches the runtime internally. Set the agent module's VPC variables:
+
+```hcl
+module "my_agent" {
+  source = "../../common/terraform/src/app/agents/my-agent"
+
+  enable_vpc = true
+  vpc_id     = aws_vpc.my_vpc.id
+  subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
+}
+```
+
+Use private subnets with egress (a route to a NAT gateway), not private isolated subnets: the runtime needs outbound internet access to reach Bedrock and read its configuration from AWS AppConfig.
+:::
+</Fragment>
+</Infrastructure>
+
+## Invoking the agent through the Gateway
+
+Requests to `<gatewayUrl origin>/<targetName>/invocations` are forwarded to the agent runtime without protocol translation, so callers use the same request shape they'd use against the runtime directly — SSE streams (AG-UI), JSON streaming (Python HTTP) and A2A JSON-RPC all proxy through. Callers authenticate with the Gateway (IAM SigV4 or Cognito JWT depending on the Gateway's `auth`) rather than with the agent.
+
+To connect a website to the Gateway's agents, use the <Link path="guides/connection/react-agentcore-gateway">`connection` generator</Link>.
+
+## Forwarding caller identity to the runtime
+
+By default the Gateway signs outbound calls with its own IAM role (the `GATEWAY_IAM_ROLE` credential provider), so the runtime sees the _Gateway's_ identity, not the caller's. If you want the agent to authorize on the caller — for example to read the user's `sub` or `scope` claims — the Gateway can instead forward the caller's JWT to the runtime unchanged. This requires three changes:
+
+1. **The Gateway accepts JWTs.** Generate the Gateway with `auth: cognito` so its inbound authorizer validates a Cognito (or other OIDC) bearer token.
+2. **The runtime accepts the same JWTs.** Generate the agent with `auth: cognito` (same user pool) so the runtime revalidates the forwarded token.
+3. **The target uses the `JWT_PASSTHROUGH` credential provider** instead of `GATEWAY_IAM_ROLE`, and the **runtime allowlists the `Authorization` header** so it reaches your agent code. Without the allowlist, AgentCore validates the token but strips the header before your container.
+
+Callers then invoke the Gateway with `Authorization: Bearer <jwt>` (no SigV4), and the agent reads the claims from the `Authorization` header — skipping signature validation, since the runtime's inbound authorizer has already verified the token:
+
+```python title="packages/py_project/.../my_agent/main.py"
+import jwt  # PyJWT
+
+@app.post('/invocations')
+async def invoke(input: InvokeInput, request: Request):
+    token = request.headers['authorization'].removeprefix('Bearer ')
+    claims = jwt.decode(token, options={'verify_signature': False})
+    # authorize on claims['sub'], claims['scope'], ...
+```
+
+<Infrastructure>
+<Fragment slot="cdk">
+Pass `requestHeaderConfiguration` to the agent so the runtime receives the header, and create the target yourself (instead of `gateway.addAgent(agent)`) with the `JWT_PASSTHROUGH` credential provider:
+
+```ts title="packages/infra/src/stacks/application-stack.ts" {5-7,17-19}
+import { CfnGatewayTarget } from 'aws-cdk-lib/aws-bedrockagentcore';
+import { PolicyStatement } from 'aws-cdk-lib/aws-iam';
+
+const myAgent = new MyAgent(this, 'MyAgent', {
+  identity,
+  // Let the runtime receive the forwarded Authorization header.
+  requestHeaderConfiguration: { allowlistedHeaders: ['Authorization'] },
+});
+const myGateway = new MyGateway(this, 'MyGateway', { identity });
+
+const target = new CfnGatewayTarget(this, 'Target-my-agent', {
+  gatewayIdentifier: myGateway.gateway.gatewayId,
+  name: myAgent.agentName,
+  targetConfiguration: {
+    http: { agentcoreRuntime: { arn: myAgent.agentCoreRuntime.agentRuntimeArn } },
+  },
+  // Forward the caller's validated JWT to the runtime unchanged.
+  credentialProviderConfigurations: [
+    { credentialProviderType: 'JWT_PASSTHROUGH' },
+  ],
+});
+
+// The Gateway role still needs invoke access to the runtime.
+myGateway.gateway.role.addToPrincipalPolicy(
+  new PolicyStatement({
+    actions: ['bedrock-agentcore:InvokeAgentRuntime'],
+    resources: [
+      myAgent.agentCoreRuntime.agentRuntimeArn,
+      `${myAgent.agentCoreRuntime.agentRuntimeArn}/*`,
+    ],
+  }),
+);
+```
+</Fragment>
+<Fragment slot="terraform">
+Add a `request_header_configuration` block to the runtime so it receives the header, and configure the target with the `JWT_PASSTHROUGH` credential provider (instead of `gateway_iam_role {}`):
+
+```hcl title="packages/infra/src/main.tf" {5-7,20-22}
+# Let the runtime receive the forwarded Authorization header. Add this block
+# to the runtime resource in the agent module (packages/common/terraform/...).
+resource "aws_bedrockagentcore_agent_runtime" "agent_runtime" {
+  # ...
+  request_header_configuration {
+    request_header_allowlist = ["Authorization"]
+  }
+}
+
+resource "aws_bedrockagentcore_gateway_target" "my_agent" {
+  gateway_identifier = module.my_gateway.gateway_id
+  name               = "my-agent"
+  description        = "Agent runtime target my-agent"
+
+  target_configuration {
+    http {
+      agentcore_runtime {
+        arn = module.my_agent.agent_core_runtime_arn
+      }
+    }
+  }
+
+  # Forward the caller's validated JWT to the runtime unchanged.
+  credential_provider_configuration {
+    credential_provider_type = "JWT_PASSTHROUGH"
+  }
+}
+```
+</Fragment>
+</Infrastructure>
+
+:::note
+`JWT_PASSTHROUGH` suits a single identity provider whose token audience already covers the runtime. If one Gateway fronts agents across multiple tenants or audiences, use OAuth [on-behalf-of token exchange](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-building-adding-targets-authorization.html) instead.
+:::
+
+## Local Development
+
+Running the Gateway locally with:
+
+<NxCommands commands={["dev <gateway-name>"]} />
+
+starts a local gateway plus every attached agent on its assigned local port. The local gateway proxies `/<targetName>/...` paths to each agent's local server, matching the deployed Gateway's path-based routing.

package/docs/guides/connection/agentcore-gateway-gateway.mdx

@@ -58,7 +58,7 @@ The generator **cannot** automatically wire the gateway target into your infrast
 <Fragment slot="cdk">
 In the stack where you instantiate the Gateways, register the target gateway as a target of the source gateway:
 
-```ts title="packages/infra/src/stacks/application-stack.ts" {5-6}
+```ts title="packages/infra/src/stacks/application-stack.ts" {4-7}
 const innerGateway = new InnerGateway(this, 'InnerGateway');
 const outerGateway = new OuterGateway(this, 'OuterGateway');
 
@@ -81,7 +81,7 @@ The construct grants the source gateway's execution role `bedrock-agentcore:Invo
 <Fragment slot="terraform">
 In the Terraform file where you instantiate the Gateways, wire the gateway target in:
 
-```hcl title="packages/infra/src/main.tf" {2-5,11-15,18-36}
+```hcl title="packages/infra/src/main.tf" {4-6,11,13-19,22-40}
 module "inner_gateway" {
   source = "../../common/terraform/src/app/gateways/inner-gateway"
 

package/docs/guides/connection/agentcore-gateway-mcp.mdx

@@ -61,7 +61,7 @@ The generator **cannot** automatically wire the MCP server target into your infr
 <Fragment slot="cdk">
 In the stack where you instantiate the Gateway, register the MCP server as a target:
 
-```ts title="packages/infra/src/stacks/application-stack.ts" {5-6}
+```ts title="packages/infra/src/stacks/application-stack.ts" {4-7}
 const myMcpServer = new MyMcpServer(this, 'MyMcpServer');
 const myGateway = new MyGateway(this, 'MyGateway');
 
@@ -84,7 +84,7 @@ The construct configures the target with `iamCredentialProvider.service = 'bedro
 <Fragment slot="terraform">
 In the Terraform file where you instantiate the Gateway, wire the MCP server target in:
 
-```hcl title="packages/infra/src/main.tf" {7,11-27}
+```hcl title="packages/infra/src/main.tf" {7,10-28}
 module "my_mcp_server" {
   source = "../../common/terraform/src/app/mcp-servers/my-mcp-server"
 }

package/docs/guides/connection/py-agent-a2a.mdx

@@ -92,7 +92,7 @@ def get_agent():
 ```
 </TabItem>
 <TabItem label="LangChain" _filter={{ framework: 'langchain' }}>
-```python title="packages/my-project/my_module/agent/agent.py" {4,7-12,14}
+```python title="packages/my-project/my_module/agent/agent.py" {5,8-13,15}
 from langchain.agents import create_agent
 from langchain_aws import ChatBedrockConverse
 from langchain_core.tools import tool

package/docs/guides/connection/py-agent-gateway.mdx

@@ -91,7 +91,7 @@ def get_agent():
 `MyGatewayClientStrands.create()` returns a single context-manageable `MCPClient` whose `list_tools_sync()` yields every tool available through the Gateway.
 </TabItem>
 <TabItem label="LangChain" _filter={{ framework: 'langchain' }}>
-```python title="packages/example/example/my_agent/agent.py" {4,8,12}
+```python title="packages/example/example/my_agent/agent.py" {4,7,11}
 from langchain.agents import create_agent
 from langchain_aws import ChatBedrockConverse
 
@@ -134,7 +134,7 @@ gateway.grantInvokeAccess(myAgent);
 The Gateway URL is automatically registered in the `agentcore.gateways.<ClassName>` namespace of <Link path="guides/runtime-config">Runtime Configuration</Link> by the generated CDK construct, so the agent can discover it at runtime.
 </Fragment>
 <Fragment slot="terraform">
-```hcl title="packages/infra/src/main.tf" {6-13}
+```hcl title="packages/infra/src/main.tf" {8-13}
 module "my_gateway" {
   source = "../../common/terraform/src/app/gateways/my-gateway"
 }

package/docs/guides/connection/py-agent-mcp.mdx

@@ -70,7 +70,7 @@ The generator transforms your agent's `agent.py` to use the MCP server's tools:
 
 <Tabs syncKey="agent-framework">
 <TabItem label="Strands" _filter={{ framework: 'strands' }}>
-```python title="packages/my-project/my_module/agent/agent.py" {4,9-13}
+```python title="packages/my-project/my_module/agent/agent.py" {4,8,9-13}
 from contextlib import contextmanager
 from strands import Agent
 
@@ -91,7 +91,7 @@ def get_agent():
 The Strands client is a context manager, entered in a `with` block around the agent.
 </TabItem>
 <TabItem label="LangChain" _filter={{ framework: 'langchain' }}>
-```python title="packages/my-project/my_module/agent/agent.py" {4,8,13}
+```python title="packages/my-project/my_module/agent/agent.py" {4,7,11}
 from langchain.agents import create_agent
 from langchain_aws import ChatBedrockConverse
 
@@ -131,7 +131,7 @@ The MCP server's AgentCore runtime ARN is automatically registered in the `agent
 <Fragment slot="terraform">
 After running the connection generator, you need to grant the agent permission to invoke the MCP server in your Terraform configuration:
 
-```hcl title="packages/infra/src/main.tf" {12-24}
+```hcl title="packages/infra/src/main.tf" {9-25}
 module "inventory_mcp_server" {
   source = "../../common/terraform/src/app/mcp-servers/inventory-mcp"
 }