Exams / AIP-C01 / Study guide / Tool integration and MCP servers (Lambda, ECS, AgentCore Gateway)
Tool integration and MCP servers (Lambda, ECS, AgentCore Gateway): AIP-C01 study notes and practice questions
What to know about Tool integration and MCP servers (Lambda, ECS, AgentCore Gateway) for the AIP-C01 exam, from the Implementation and Integration domain (26% of the exam guide), then 2 free questions to test it. Part of the AIP-C01 study guide.
AIP-C01 asks how to expose internal APIs and data to a model, how to host the tool servers, and why the model picks the wrong tool or fails to use one. The Model Context Protocol (MCP) is the open standard for tools, so the choice is mostly about where the server runs and how it is built.
Hosting the MCP server
Stateless MCP server on Lambda: best for light, short tools such as a price lookup or a ticket status check. Each call stands alone, and the service scales to zero when idle. Lambda runs up to 15 minutes per call.
MCP server on ECS or Fargate: best for long-running or stateful tools, such as a tool that holds a database connection pool, keeps a session cache or streams a long job. The containers run continuously, so state survives between calls.
AgentCore Gateway: converts existing Lambda functions, OpenAPI definitions and other MCP servers into MCP tools without writing a server. It also handles inbound authentication and rate limits.
Parameters, errors and descriptions
Validate every parameter in the tool, for example against a JSON schema, before it touches a backend. Return short, structured errors the model can act on, such as “order ID must be 10 digits.” Do not return raw stack traces, and do not return a generic failure that makes the model retry blindly. Make write tools idempotent, so a retry does not create a second order.
Tool descriptions and schemas are part of the model’s input. The model picks a tool from its name, description and parameter types. Use clear names, specific descriptions, typed parameters and enums where values are fixed. A wrong tool choice is often a description problem, not a model problem.
Third-party OAuth with AgentCore Identity
AgentCore Identity stores and refreshes outbound OAuth tokens and API keys for third-party services, so the agent does not hold client secrets. It can act on behalf of a signed-in user, so each call uses that user’s permissions.
How to choose
Scenario wording
Choose
“Light, stateless tool with occasional calls”
MCP server on Lambda
“Tool keeps a connection or state, or runs long”
MCP server on ECS or Fargate
“Expose existing REST APIs or Lambda functions as tools”
AgentCore Gateway
“Agent calls a SaaS API using each user’s OAuth grant”
AgentCore Identity
“Model keeps choosing the wrong tool”
Clearer names, descriptions and schemas
Common traps
Stateful logic on Lambda, assuming memory persists between calls. Containers are recycled, so state is lost.
A hand-built MCP server on EC2 for a plain REST API that Gateway could expose directly.
Third-party API keys in prompts, in code or in plain environment variables when Identity handles them.
Generic 500 errors from tools, which cause the model to loop.
Retrying non-idempotent write tools, which duplicates side effects.
A retail analytics team wants its generative AI assistant to call internal tools through the Model Context Protocol (MCP). Four of the tools are light: each returns in about two seconds, keeps no state between calls, and is called only a few times an hour. The fifth tool runs a demand forecast that takes about 40 minutes and keeps a large model loaded in memory between calls.
The team does not want to patch servers for the light tools, and it wants them to cost almost nothing when nobody is using the assistant. The forecast tool must keep its model warm and must finish a 40-minute job.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Implement the four light tools as stateless AWS Lambda functions, and add them as Lambda targets in Amazon Bedrock AgentCore Gateway, which exposes them as MCP tools.
BB. Host the forecast tool on AWS Lambda with provisioned concurrency, so that the model stays loaded in the warm execution environments between calls.
CC. Run all five tools as one MCP server on a single Amazon EC2 instance in an Auto Scaling group with a minimum size of one, and patch the instance on a monthly schedule.
DD. Run the forecast tool as an MCP server in a long-running task on Amazon ECS with AWS Fargate, where the model stays loaded in the task's memory between calls.
EE. Place the four light tools in one Amazon ECS service with a minimum of two tasks, so that they stay available if one task fails.
Show the answer and explanation
Answers: A, D
A. Right: Stateless tools fit Lambda, which costs nothing while idle and has no servers to patch. AgentCore Gateway turns the Lambda functions into MCP tools that the assistant can discover and call. Learn more: Amazon Bedrock AgentCore Gateway (opens in a new tab)
B. Wrong: Provisioned concurrency keeps environments warm, but Lambda stops every invocation after 15 minutes, so a 40-minute job cannot finish. The design fails the forecast requirement.
C. Wrong: The instance runs and bills even when the assistant is idle, and the team must patch it. This fails both the idle cost requirement and the no-servers requirement for the light tools.
D. Right: A long-running container has no 15-minute limit, so a 40-minute forecast can finish, and the loaded model stays in memory between calls. Fargate removes the need to manage the underlying hosts.
E. Wrong: Two always-on tasks cost money every hour, even when no one is using the assistant. Availability is good, but it works against the idle-cost requirement for light tools.
Explanation
Lambda suits the light, stateless tools because it costs nothing while idle and needs no servers, and AgentCore Gateway presents those functions as MCP tools. The forecast needs a long-running container with its model in memory, since Lambda cannot run a job that lasts 40 minutes. Always-on servers, a provisioned Lambda forecast and always-on light tasks each miss one requirement.
A hotel group's AI concierge calls a room-service tool that runs as an AWS Lambda function. The tool places an order in the kitchen system. The model sometimes passes a room number with a stray suffix, or leaves out the required delivery time.
Today the Lambda function throws an unhandled exception on those inputs, and the whole conversation turn fails with an error. The team wants the guest to get a useful reply, and fixable inputs should be corrected and retried. Invalid orders must never reach the kitchen, and the tool's input contract must stay the same.
Which tool design meets these requirements?
Choose one answer.
AA. Remove the input checks from the Lambda function and rely on the kitchen system to reject incomplete orders, so the function stays as small as possible.
BB. Wrap the whole handler in a try block that returns an empty success response for any error, so the conversation continues without an error.
CC. Add a rule to the system prompt that the model must always send a valid room number and delivery time, and leave the Lambda function unchanged.
DD. Validate each input against the tool's JSON schema in the Lambda function before ordering, and return a structured error result that names the bad field.
Show the answer and explanation
Answer: D
A. Wrong: The kitchen system may accept an order with a stray suffix or a missing time, so an invalid order could be placed. The guest would also get no useful reply from the concierge.
B. Wrong: Reporting success for a failed order hides the problem, and the guest may believe food is on its way. The model also cannot correct an input it was told was accepted.
C. Wrong: A prompt instruction reduces errors but cannot guarantee valid input, so the function still needs its own checks. Without validation in the tool, an invalid order can still reach the kitchen.
D. Right: Checks before the kitchen call stop invalid orders, and the schema keeps the input contract the same. The model receives a readable error it can use to correct the room number or time and call the tool again. Learn more: Call a tool with the Converse API (opens in a new tab)
Explanation
Validating inputs in the Lambda function before any order is placed keeps invalid orders out of the kitchen, and the schema preserves the tool's contract. Returning a structured error result lets the model fix a fixable input and retry, so the guest gets a useful reply. Removing checks, faking success and relying on the prompt each fail a requirement.
Want more on Tool integration and MCP servers (Lambda, ECS, AgentCore Gateway)? The 5 full-length practice sets have 6 more Tool integration and MCP servers (Lambda, ECS, AgentCore Gateway) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Tool integration and MCP servers (Lambda, ECS, AgentCore Gateway)