AWS Builder Center

Set Up AgentCore and Strands Gateway MCP Tool Fabric Through the AWS Console

Set Up AgentCore and Strands Gateway MCP Tool Fabric Through the AWS Console

Series: Financial Service (19 articles)

  1. …
  2. 17
    Set Up AgentCore and Strands Gateway MCP Tool Fabric Through the AWS Console This article
Dev @ Vertex Macro

Set Up AgentCore and Strands Gateway MCP Tool Fabric Through the AWS Console

Purpose and target architecture

This guide converts the developer workshop into a console-led AWS build. The finished environment exposes four sovereign-risk analysis tools from one AWS Lambda function through an Amazon Bedrock AgentCore Gateway MCP endpoint. Semantic search lets an agent discover the most relevant tools. A Strands agent then connects to the Gateway, loads the governed tools, and uses them as evidence sources before generating a response.
The AWS Management Console is used for Amazon Bedrock model access, IAM, Amazon Cognito, Lambda, AgentCore Gateway, CloudWatch, and testing configuration. A small amount of code is still required because the Lambda handler and Strands client are application code rather than console settings. AWS CloudShell is used for packaging, dependency installation, token retrieval, and end-to-end tests, so no local workstation is required.
The workshop is an educational engineering implementation. The example tools return structured risk-analysis evidence. They do not execute trades, change positions, provide investment advice, or make autonomous risk decisions.

Architecture

The tool fabric begins with an authorized client running in AWS CloudShell, a developer environment, an application workload, or Amazon Bedrock AgentCore Runtime. The client connects to Amazon Bedrock AgentCore Gateway over HTTPS. Depending on the selected inbound authorization model, the connection uses a JSON Web Token issued by Amazon Cognito or an approved enterprise identity provider, or AWS Signature Version 4 with temporary IAM credentials.
Amazon Bedrock AgentCore Gateway provides the managed MCP entry point. It authenticates the caller, validates the request, exposes the registered tool inventory, processes tools/list and tools/call requests, and provides the optional x_amz_bedrock_agentcore_search tool for semantic discovery. The Gateway separates client authentication from backend authorization, allowing callers to use an approved identity mechanism while the Gateway invokes backend targets through its dedicated IAM service role.
The Gateway contains a Lambda target named sovereign-risk-lambda-target. This target publishes four MCP tools: funding_liquidity, credit_spread_widening, sovereign_debt_risk_repricing, and currency_mismatch. Each tool has a clear description and JSON input schema containing a required query field. The descriptions support semantic retrieval, while the schemas provide consistent validation and invocation contracts.
When a client calls one of the tools, AgentCore Gateway validates the MCP request and invokes the sovereign-risk-tool-handler AWS Lambda function through IAM-authorized access. The Lambda function normalizes any Gateway-generated tool-name prefix, validates the requested tool, applies deterministic business logic, and returns structured JSON containing the selected tool, the original query, relevant risk signals, an evidence-oriented summary, limitations, and a request identifier. The Lambda backend does not execute trades, change positions, or perform autonomous financial actions.
The Strands agent uses an approved Amazon Bedrock foundation model together with the tools exposed through AgentCore Gateway. For a small tool catalog, Strands can load all registered tools when the MCP session starts. For a larger enterprise catalog, the AgentCore Tool Search integration can use semantic search to select only the tools relevant to the user's request. The agent follows an evidence-first instruction that requires it to use the smallest sufficient tool set, distinguish observations from interpretation, state limitations, and avoid investment advice or autonomous trading instructions.
Amazon CloudWatch captures Lambda logs, invocation metrics, errors, duration, throttling, and the AgentCore operational telemetry available in the account. AWS CloudTrail records configuration and management activity involving the Gateway, Lambda functions, authentication resources, and IAM roles. IAM policies enforce least-privilege access between the client, Gateway, Lambda target, and Amazon Bedrock model. AWS KMS provides customer-managed encryption where required by enterprise policy, including eligible Gateway resources, CloudWatch log groups, secrets, and supporting data stores.
The end-to-end request path is therefore client authentication, AgentCore Gateway authorization and MCP routing, semantic or deterministic tool selection, IAM-authorized Lambda invocation, structured tool output, and Strands evidence synthesis through an Amazon Bedrock model. Operational evidence is captured in CloudWatch and CloudTrail throughout the request lifecycle.

Step 1: Select the AWS Region and verify prerequisites

Sign in to the AWS Management Console with an administrator or delegated platform-engineering role. Select one Region and use it consistently for Lambda, Amazon Cognito, Amazon Bedrock, and AgentCore. For this workshop, us-east-1 is a practical default. Confirm that AgentCore Gateway and the chosen Amazon Bedrock model are available in the Region.
Open Amazon Bedrock. In the navigation pane, open Model access or the current model-access page. Confirm access to an approved model that Strands can invoke. The sample client can use an Amazon Nova model, but the exact model ID should be checked in the Bedrock console because model availability and inference profiles vary by Region and account.
Open AWS CloudShell from the console toolbar. Run the following commands to verify the caller and Region.
1
2
3
aws sts get-caller-identity
aws configure get region
aws bedrock list-foundation-models --region us-east-1 --query 'modelSummaries[].modelId' --output text
Set a consistent Region for the CloudShell session.
1
2
3
4
export AWS_DEFAULT_REGION=us-east-1
export AWS_REGION=us-east-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
echo "$ACCOUNT_ID"

Step 2: Create the Lambda execution role in IAM

Open IAM, choose Roles, and choose Create role. Select AWS service as the trusted entity and Lambda as the use case. Continue to permissions. Attach AWSLambdaBasicExecutionRole for the workshop. Name the role SovereignRiskToolsLambdaRole and create it.
For production, replace broad managed policies with a customer-managed policy that permits only the exact log group and downstream resources required by the function. The workshop Lambda is deterministic and does not require S3, DynamoDB, or Amazon Bedrock permissions.
Open the new role and copy its ARN for your build record. Review the Trust relationships tab and verify that lambda.amazonaws.com can assume the role.

Step 3: Create the Lambda function through the console

Open AWS Lambda and choose Create function. Select Author from scratch. Enter sovereign-risk-tool-handler. Select Python 3.12 or another currently supported Python runtime. Under Permissions, expand Change default execution role, choose Use an existing role, and select SovereignRiskToolsLambdaRole. Choose Create function.
In the Code tab, replace the generated function code with the following implementation. AgentCore Gateway prefixes tool names with the target name, so the handler strips the prefix before routing. It also accepts more than one event shape to simplify workshop troubleshooting.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
import json

HANDLERS = {
"funding_liquidity": {
"signals": ["repo stress", "money-market spreads", "USD funding", "swap basis"],
"summary": "Check funding stress before treating yield movement as isolated sovereign repricing.",
},
"credit_spread_widening": {
"signals": ["IG spreads", "HY spreads", "CDS indices", "downgrade risk"],
"summary": "Credit spread widening can indicate default-risk repricing or liquidity-premium expansion.",
},
"sovereign_debt_risk_repricing": {
"signals": ["real yields", "fiscal credibility", "policy divergence", "capital flows"],
"summary": "Sovereign repricing should be decomposed into fiscal, policy, flow, and FX drivers.",
},
"currency_mismatch": {
"signals": ["external debt", "FX reserves", "basis swaps", "forward hedging cost"],
"summary": "Currency mismatch can amplify stress when external refinancing conditions tighten.",
},
}


def normalize_tool_name(tool_name):
if not tool_name:
return None
if "___" in tool_name:
tool_name = tool_name.split("___", 1)[1]
if "__" in tool_name and tool_name not in HANDLERS:
candidate = tool_name.split("__", 1)[1]
if candidate in HANDLERS:
tool_name = candidate
return tool_name


def lambda_handler(event, context):
tool_name = (
event.get("name")
or event.get("toolName")
or event.get("tool_name")
)
tool_name = normalize_tool_name(tool_name)

arguments = event.get("arguments") or event.get("input") or {}
query = arguments.get("query", "") if isinstance(arguments, dict) else ""

if tool_name not in HANDLERS:
return {
"statusCode": 400,
"body": json.dumps({
"error": "Unknown or missing tool",
"received_tool_name": tool_name,
"available_tools": sorted(HANDLERS.keys()),
}),
}

result = {
"tool": tool_name,
"query": query,
"signals": HANDLERS[tool_name]["signals"],
"summary": HANDLERS[tool_name]["summary"],
"limitations": [
"Educational engineering output",
"Not investment advice",
"No autonomous trading action",
],
"request_id": context.aws_request_id,
}
return {"statusCode": 200, "body": json.dumps(result)}
Choose Deploy. Open Configuration, General configuration, and choose Edit. Set the timeout to 30 seconds and memory to 256 MB. Save the change.

Step 4: Test the Lambda function before introducing Gateway

Open the Test tab and create an event named TestSovereignRepricing with the following content.
1
2
3
4
5
6
{
"name": "sovereign_debt_risk_repricing",
"arguments": {
"query": "US-China yield spread widening and RMB pressure"
}
}
Choose Test. Confirm that the result has statusCode 200 and that the body contains the tool name, query, signals, summary, limitations, and request ID.
Create a second event with an invalid tool name and verify that the function returns a controlled 400 response rather than an unhandled exception. Open Monitor, View CloudWatch logs, and confirm that the invocation appears without sensitive credentials or tokens.
Copy the Lambda function ARN from the Function overview. It will resemble the following value.
1
arn:aws:lambda:us-east-1:123456789012:function:sovereign-risk-tool-handler

Step 5: Prepare the Lambda tool schema

AgentCore Gateway needs a tool schema that describes each function the Lambda target exposes. In AWS CloudShell, create tool_schema.json.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
cat > tool_schema.json <<'EOF'
[
{
"name": "funding_liquidity",
"description": "Assess repo stress, money-market pressure, USD funding conditions, swap basis, and cash preference before interpreting market repricing.",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Funding-liquidity analysis request."
}
},
"required": ["query"]
}
},
{
"name": "credit_spread_widening",
"description": "Assess investment-grade and high-yield spread widening, CDS pressure, downgrade risk, default repricing, and liquidity premium.",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Credit-spread analysis request."
}
},
"required": ["query"]
}
},
{
"name": "sovereign_debt_risk_repricing",
"description": "Assess sovereign debt repricing through fiscal credibility, real yields, policy divergence, capital flows, and foreign-exchange pressure.",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Sovereign-debt repricing request."
}
},
"required": ["query"]
}
},
{
"name": "currency_mismatch",
"description": "Assess foreign-exchange mismatch, external debt refinancing, reserve adequacy, cross-currency basis, and hedging cost context.",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Currency-mismatch analysis request."
}
},
"required": ["query"]
}
}
]
EOF
python -m json.tool tool_schema.json > /dev/null && echo "Tool schema is valid JSON"
Keep the CloudShell editor open because the schema can be pasted into the AgentCore console when the Lambda target is added. Strong descriptions matter because semantic search uses tool metadata to retrieve relevant tools.

Step 6: Create the AgentCore Gateway service role

Open IAM, choose Roles, and choose Create role. If the AgentCore service appears under AWS service use cases, select it. If the console workflow creates the role automatically during Gateway creation, prefer that path for the workshop because AWS generates the trust relationship expected by the service.
If you create a customer role, name it AgentCoreGatewaySovereignRiskRole. Attach a least-privilege policy that permits invocation of only the workshop function. Replace the account and Region values.
1
2
3
4
5
6
7
8
9
10
11
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeSovereignRiskToolLambda",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:sovereign-risk-tool-handler"
}
]
}
Do not attach broad Lambda administrator permissions. The Gateway should be able to invoke the tool backend, not modify the function, change its role, or enumerate unrelated functions.

Step 7: Create the AgentCore Gateway in the AWS console

Open Amazon Bedrock AgentCore in the AWS Management Console. In the left navigation pane, choose Gateways, then choose Create gateway.
Enter gateway-sovereign-risk-tools as the name. Add a description that states that the Gateway exposes evidence-oriented sovereign-risk analysis tools and does not include trading execution. Expand Additional configurations.
Enable semantic search during gateway creation. This decision is important because semantic search cannot be enabled later on an existing Gateway. Keep exception-level debugging enabled only for the workshop or non-production environment. Disable it before production promotion to avoid returning unnecessary internal details.
For inbound authentication, choose one of the following console paths.
For the fastest workshop, choose Quick create configurations with Amazon Cognito. The console creates or connects the authorization resources and provides a client that can obtain JWTs.
For an enterprise environment, choose Use existing identity provider configurations. Enter the OpenID discovery URL, allowed audience, allowed client, allowed scopes, and required custom claims defined by the identity team. This path is preferred when the enterprise already operates workforce or machine identity standards.
Under Permissions, choose Create and use a new service role if the console offers it. Give the role a clear name and later reduce it to permission for the workshop Lambda only. If you created AgentCoreGatewaySovereignRiskRole, choose Use an existing service role and select it.
If the console offers a customer-managed KMS key, select the enterprise-approved Gateway key. Otherwise, use the AWS-managed key for the workshop. Review the settings and choose Create gateway. Wait until the status becomes Ready or Available.
Record the Gateway ID, Gateway ARN, Gateway URL, authorizer information, service-role ARN, semantic-search status, supported MCP versions, and Region. The URL should end with the MCP endpoint expected by the console or documentation.

Step 8: Add the Lambda target in the console

Open the new Gateway and choose Targets or Add target. Select AWS Lambda as the target type. Enter sovereign-risk-lambda-target as the target name and add a precise description.
Choose the sovereign-risk-tool-handler Lambda function. For the tool schema, choose the inline option and paste the content of tool_schema.json. If the console supports an S3 schema location, the inline option is simpler for this workshop.
For outbound authorization, choose Gateway IAM role. This lets Gateway invoke Lambda with its service role rather than embedding a static credential. Review the four tool definitions and create the target.
Wait until the target status is Ready. Open its details and inspect the generated tool names. Gateway tool names may include the target-name prefix. The Lambda handler created earlier strips the prefix before routing.
If target creation fails, check the Gateway role's lambda:InvokeFunction permission, the Lambda ARN and Region, schema JSON syntax, duplicate tool names, required fields, and CloudTrail events for denied actions.

Step 9: Verify tool discovery in the Gateway console

Open the Gateway test or MCP inspection experience if it is available in the console. Invoke tools/list and confirm that all four risk tools appear, plus the built-in semantic-search tool when semantic search is enabled.
Expected domain tools are:
1
2
3
4
funding_liquidity
credit_spread_widening
sovereign_debt_risk_repricing
currency_mismatch
The displayed names may have a target prefix. Record their exact names for direct JSON-RPC testing. Confirm that each tool has a useful description, an object input schema, a required query field, and no execution or trading capability.

Step 10: Retrieve a Cognito token for testing

If Quick create with Cognito was selected, open Amazon Cognito in the same Region. Open the user pool created for the Gateway and identify the app client, user-pool domain or token endpoint, and supported OAuth flow.
For a machine-to-machine app client using the client-credentials flow, ensure a client secret and resource-server scope are configured. Do not use the AWS console to expose a production client secret in notes or screenshots. Store production secrets in AWS Secrets Manager.
From CloudShell, request a token using the values from Cognito. The exact scope is determined by the resource server created for the Gateway.
1
2
3
4
5
6
7
8
9
10
11
12
export COGNITO_DOMAIN='https://your-domain.auth.us-east-1.amazoncognito.com'
export COGNITO_CLIENT_ID='replace-me'
export COGNITO_CLIENT_SECRET='replace-me'
export COGNITO_SCOPE='replace-with-approved-scope'

export AGENTCORE_GATEWAY_JWT=$(curl -s \
-u "${COGNITO_CLIENT_ID}:${COGNITO_CLIENT_SECRET}" \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d "grant_type=client_credentials&scope=${COGNITO_SCOPE}" \
"${COGNITO_DOMAIN}/oauth2/token" | python -c 'import json,sys; print(json.load(sys.stdin)["access_token"])')

test -n "$AGENTCORE_GATEWAY_JWT" && echo "JWT obtained"
If the app client uses another OAuth flow, follow the identity-team-approved flow rather than forcing client credentials. Never commit a token or client secret to the workshop repository.

Step 11: Test raw MCP tools/list from CloudShell

Copy the Gateway MCP URL from the AgentCore console and set it in CloudShell.
1
2
export AGENTCORE_GATEWAY_URL='https://replace-with-gateway-endpoint/mcp'
export MCP_PROTOCOL_VERSION='2025-11-25'
Call tools/list with JSON-RPC. Use a protocol version listed in the Gateway's supported MCP versions.
1
2
3
4
5
6
7
8
9
10
11
curl -sS "$AGENTCORE_GATEWAY_URL" \
-H "Authorization: Bearer $AGENTCORE_GATEWAY_JWT" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H "MCP-Protocol-Version: $MCP_PROTOCOL_VERSION" \
-d '{
"jsonrpc": "2.0",
"id": "list-001",
"method": "tools/list",
"params": {}
}'
A 401 or 403 response usually indicates an expired token, wrong audience, client, scope, required claim, or authorizer discovery URL. A protocol error can indicate that the MCP-Protocol-Version header does not match a supported version.

Step 12: Test semantic tool search

Call the built-in semantic-search tool. The query should use natural business language rather than an exact tool name.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
curl -sS "$AGENTCORE_GATEWAY_URL" \
-H "Authorization: Bearer $AGENTCORE_GATEWAY_JWT" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H "MCP-Protocol-Version: $MCP_PROTOCOL_VERSION" \
-d '{
"jsonrpc": "2.0",
"id": "search-001",
"method": "tools/call",
"params": {
"name": "x_amz_bedrock_agentcore_search",
"arguments": {
"query": "RMB pressure, external dollar debt, reserve adequacy, and sovereign repricing"
}
}
}'
Confirm that the results include currency_mismatch and sovereign_debt_risk_repricing near the top. If the ranking is weak, improve the tool descriptions instead of adding hidden prompt tricks. Tool metadata is part of the production interface.

Step 13: Test a direct tool call

Use the exact tool name returned by tools/list, including its target prefix if one is shown.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
export SOVEREIGN_TOOL_NAME='replace-with-listed-sovereign-tool-name'

curl -sS "$AGENTCORE_GATEWAY_URL" \
-H "Authorization: Bearer $AGENTCORE_GATEWAY_JWT" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H "MCP-Protocol-Version: $MCP_PROTOCOL_VERSION" \
-d "{
\"jsonrpc\": \"2.0\",
\"id\": \"call-001\",
\"method\": \"tools/call\",
\"params\": {
\"name\": \"${SOVEREIGN_TOOL_NAME}\",
\"arguments\": {
\"query\": \"US-China yield spread widening, RMB pressure, and capital-flow stress\"
}
}
}"
Confirm the full path: the client receives a successful MCP response, Gateway invokes Lambda, Lambda returns valid JSON, and a new Lambda invocation appears in CloudWatch Logs.

Step 14: Create an IAM role for the Strands client

For production, create a role named StrandsGatewayInvokeRole. Its trust policy should allow only the approved compute identity to assume it. This could be an AgentCore Runtime execution role, ECS task role, EC2 instance profile, or a designated developer role.
Grant the minimum AgentCore data-plane permission required to invoke the specific Gateway resource. Use the current service-authorization reference and the Gateway ARN shown in the console when defining the action and resource. Avoid bedrock-agentcore:* on *. Add Amazon Bedrock model invocation permission for only the approved model or inference profile used by Strands.
If this workshop runs from CloudShell with JWT authentication, the Strands client can use the bearer token. If the Gateway is configured for IAM inbound authorization, use the AWS IAM streamable HTTP transport and temporary AWS credentials. Do not mix a JWT-only Gateway configuration with an IAM-only client.

Step 15: Build the Strands client in AWS CloudShell

Create a Python virtual environment in CloudShell and install the current packages.
1
2
3
4
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install strands-agents strands-agents-tools mcp requests boto3
For IAM-authenticated streamable HTTP, install the AWS MCP proxy package used by the current Strands transport guidance.
1
python -m pip install mcp-proxy-for-aws
Create strands_gateway_agent.py for an IAM-authenticated Gateway.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import os
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client

REGION = os.getenv("AWS_REGION", "us-east-1")
GATEWAY_URL = os.environ["AGENTCORE_GATEWAY_URL"]
MODEL_ID = os.environ["BEDROCK_MODEL_ID"]

mcp_client = MCPClient(
lambda: aws_iam_streamablehttp_client(
endpoint=GATEWAY_URL,
aws_region=REGION,
aws_service="bedrock-agentcore",
)
)

with mcp_client:
tools = mcp_client.list_tools_sync()
print("Loaded tools:")
for tool in tools:
print("-", tool.tool_name)

agent = Agent(
model=BedrockModel(model_id=MODEL_ID, temperature=0.2),
tools=tools,
system_prompt=(
"You are an evidence-first sovereign-risk engineering assistant. "
"Use the smallest sufficient set of Gateway tools. "
"Separate observations, interpretations, confirmation signals, "
"limitations, and invalidation triggers. Do not provide investment "
"advice or autonomous trading instructions."
),
)

result = agent(
"Analyze how wider US-China yield spreads could interact with RMB pressure, "
"sovereign debt repricing, dollar funding, and credit-spread widening."
)
print(result)
Set the model and run the client.
1
2
export BEDROCK_MODEL_ID='replace-with-approved-model-or-inference-profile-id'
python strands_gateway_agent.py
If the Gateway uses JWT inbound authorization, use the Strands streamable HTTP MCP transport with an Authorization header instead. Keep token acquisition outside the source file and load the token from an environment variable or Secrets Manager.

Step 16: Add dynamic semantic tool selection to Strands

A small workshop can load all four tools. A large enterprise Gateway should avoid placing hundreds of tool definitions into every model context. Use the AgentCore Tool Search integration for Strands so the agent derives user intent, calls Gateway semantic search, and loads only relevant tools.
Install the AgentCore Strands integration package according to the current SDK documentation.
1
python -m pip install 'bedrock-agentcore[strands-agents]'
Use the semantic tool-search plugin with an IAM-connected MCP client.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import os
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client
from bedrock_agentcore.gateway.integrations.strands.plugins import AgentCoreToolSearchPlugin

REGION = os.getenv("AWS_REGION", "us-east-1")

mcp_client = MCPClient(
lambda: aws_iam_streamablehttp_client(
endpoint=os.environ["AGENTCORE_GATEWAY_URL"],
aws_region=REGION,
aws_service="bedrock-agentcore",
)
)

with mcp_client:
agent = Agent(
model=BedrockModel(
model_id=os.environ["BEDROCK_MODEL_ID"],
temperature=0.2,
),
plugins=[AgentCoreToolSearchPlugin(mcp_client=mcp_client)],
system_prompt=(
"Use semantic discovery to load only evidence tools relevant to the request. "
"Never select execution or trading tools. Clearly state limitations."
),
)
print(agent("Assess RMB pressure and external dollar refinancing risk."))
Dynamic discovery improves context efficiency, but it introduces a retrieval control that must be evaluated. Maintain test cases that verify the expected tool appears in the top results and that prohibited tools are never selected.

Step 17: Configure CloudWatch observability

Open CloudWatch, Logs, and inspect the /aws/lambda/sovereign-risk-tool-handler log group. Set an explicit retention period. For production, encrypt the log group with a customer-managed KMS key and ensure that tool arguments containing sensitive data are not logged.
Create a dashboard named AgentCoreGatewayToolFabric. Add Lambda invocation, error, duration, throttle, and concurrent-execution metrics. Add Gateway and AgentCore metrics available in the account. Create alarms for Lambda errors, elevated duration, throttling, repeated authorization failures, target invocation failure, and unexpected tool-call volume.
Open CloudTrail and ensure management events are enabled. For a regulated deployment, send organization trails to a protected log-archive account. Use CloudTrail Lake or the firm's SIEM to correlate target changes, role changes, authorizer changes, and Lambda deployments.

Step 18: Validate negative paths

Run tests that intentionally fail. Call a nonexistent tool and confirm a controlled error. Remove the query field and confirm schema validation. Use an expired token and confirm authentication failure. Use a token with the wrong audience or scope and confirm authorization failure. Remove Lambda invocation permission from a test role and confirm the target fails without exposing internal data. Send malformed JSON-RPC and confirm the Gateway rejects it.
Test semantic-search ambiguity with queries that overlap funding, credit, sovereign, and currency risk. Record the ranked tools and adjust descriptions when the wrong tool is repeatedly selected. Test the Strands agent with a request for trade execution and confirm that the prompt and tool inventory cannot perform it.

Step 19: Production hardening

Move the Lambda function and schemas into source control and deployment pipelines. Use infrastructure as code for repeatability even though this guide demonstrates the console. Place schema linting, unit tests, JSON-RPC smoke tests, semantic-search evaluations, and Strands integration tests in continuous integration.
Use AWS Organizations, separate development and production accounts, customer-managed KMS keys, permission boundaries, IAM Access Analyzer, AWS Config, Security Hub, GuardDuty, and centralized CloudTrail. Store OAuth client secrets in Secrets Manager. Rotate credentials. Restrict allowed clients, audiences, scopes, and custom claims. Disable exception-level debugging outside controlled troubleshooting windows.
Split high-risk tools into separate Lambda functions and execution roles. Apply deterministic allow lists in addition to semantic search. Return evidence, data freshness, limitations, and correlation IDs from every tool. Do not allow an LLM to create or modify tool authorization context. The backend must independently verify caller, purpose, scope, and requested resource.
Pin MCP protocol versions, SDK versions, model IDs, prompt versions, and tool schemas. Establish change approval for each. A schema or description change can alter agent behavior even when Lambda code does not change.

Step 20: Cleanup

When the workshop is complete, remove resources to avoid ongoing cost and unused access paths. In AgentCore, delete the Lambda target and then delete the Gateway. In Lambda, delete sovereign-risk-tool-handler. In Cognito, delete the workshop app client, domain, and user pool if they are not shared. In IAM, delete the workshop roles after detaching policies. Remove CloudWatch log groups only if retention policy permits. Remove workshop secrets from CloudShell history and unset environment variables.
1
2
3
4
5
unset AGENTCORE_GATEWAY_JWT
unset COGNITO_CLIENT_SECRET
unset COGNITO_CLIENT_ID
unset COGNITO_DOMAIN
unset AGENTCORE_GATEWAY_URL

Final validation checklist

The Lambda function returns valid structured JSON for all four tools. The Gateway has semantic search enabled and uses the approved inbound authorizer. The Lambda target is Ready. tools/list returns the expected tool inventory. Semantic search returns relevant tools for business-language requests. Direct tools/call reaches Lambda successfully. The Strands client loads or dynamically discovers Gateway tools. The Bedrock model produces an evidence-first synthesis. CloudWatch and CloudTrail capture operational evidence without secrets. IAM permissions are limited to the required Gateway, Lambda function, and model. No tool can execute a trade or make an autonomous risk decision.

References

Amazon Web Services. Amazon Bedrock AgentCore Gateway: A Secure AI Gateway for Agents, Tools, and Models. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html
Amazon Web Services. Create an AgentCore Gateway Using the AWS Management Console. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-create-console.html
Amazon Web Services. Create an Amazon Bedrock AgentCore Gateway. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-create.html
Amazon Web Services. Add Targets to an Existing AgentCore Gateway. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-building-adding-targets.html
Amazon Web Services. Define the Gateway Target Configuration. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-add-target-api-target-config.html
Amazon Web Services. AWS Lambda Function Targets for AgentCore Gateway. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-add-target-lambda.html
Amazon Web Services. Search for Tools in an AgentCore Gateway with a Natural-Language Query. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using-mcp-semantic-search.html
Amazon Web Services. Get Started with AgentCore Gateway. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-quick-start.html
Strands Agents. MCP Transports. https://strandsagents.com/docs/user-guide/sdk/tools/mcp-transports/
Strands Agents. Python MCPClient API. https://strandsagents.com/docs/api/python/strands.tools.mcp.mcp_client/
Strands Agents. AgentCore Tool Search Plugin. https://strandsagents.com/docs/community/plugins/agentcore-tool-search/index.md
Strands Agents. Python Deployment to Amazon Bedrock AgentCore Runtime. https://strandsagents.com/docs/user-guide/sdk/deploy/deploy_to_bedrock_agentcore/python/
Danny Chan. Build with AgentCore and Strands: Gateway MCP Tool Fabric Developer Workshop. Internal source file, agentcore-strands-gateway-mcp-tool-fabric.md.

Series: Financial Service (19 articles)

  1. …
  2. 17
    Set Up AgentCore and Strands Gateway MCP Tool Fabric Through the AWS Console This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article