Running MCP-Based Agents (Clients & Servers) on AWS

There are many exciting things happening in developer’s worlds right now but likely the most exciting is that it is becoming easier to integrate AI into many different parts of our systems and development tools. At the heart of this are AI Agents which enable new paradigms for users of our systems. Agents and Agentic systems have already become common in AI code assistant tools like Q Developer and Q CLI. In these systems you can give a task to the AI and it figures out how to accomplish it. But one of the biggest challenges with Agents has been integration.

For Agents to be successful accomplishing a task like “schedule an appointment to adopt a dog” or “add a feature to my code so that users can schedule dog adoption” they need access to things outside of the AI. There have been ways to wire these integrations into Agents (tools, function calling, etc) but for developers there was often tedious work involved in creating those integrations.

In November 2024 Anthropic announced a new open-source standard to address these challenges called “Model Context Protocol” (MCP). The protocol covers a number of ways to integrate external data & systems into Agents and AI applications, ultimately making it easy for developers to create and consume the integrations. Here is a quick example... Suppose you want to enable an Agent to do that "dog adoption scheduling" thing. With Spring AI in Java you’d just define a new tool:

The text descriptions are then used to indicate to the Agent when to call this tool and what parameters are needed to make the call. If the dog adoption service has a way for a user to say “I’d like to adopt Prancer” then the agent will call the tool and indicate the available times. In some ways MCP defines the “metadata” needed for Agents to integrate with external systems and data.

While this example uses Java, MCP support has moved quickly with many languages and frameworks already having support. MCP has official support for Python, TypeScript, Java, Kotlin, and C# but many other languages already have unofficial support. To see an end-to-end, live coded Agent with MCP support in Java and Spring AI, check out this video with Spring expert Josh Long:
Building Agents with AWS - Complete Tutorial (Java, Spring AI, Amazon Bedrock, & MCP)

But how does this all actually work? AI Models don’t have the ability to perform integrations / call external services so this functionality usually exists in the Agent or Agentic system. To enable the integrations, when a call is made to a model it can include a list of “tools” including those descriptions which MCP conveniently provides. If the model determines that it needs to use the tool, it responds to the Agent with instructions to do so. The Agent is then responsible for actually calling those tools and providing the results back to the model in a subsequent call.

MCP provides the ways to wire together the Agent with the backing services, like product databases, CRM systems, and other customer data. To do so, an Agent needs to act as an MCP client. MCP clients are provided (usually through configuration or code) with the list of MCP servers it will interact with. But how does an MCP client “call” an MCP server? For this there are “transports” which are outlined in the MCP specification. Initially there were two transports: STDIO for local forked processes and Server-Sent Events (SSE) for networked servers. Most MCP servers (of which there are already thousands) have focused on uses in AI code assistant agents so they primarily utilize the STDIO transport and run locally so they have access to a developer’s local resources. As Agents become more integral to not just code assistants, they will need to have access to business data and systems. For these use cases the networking protocol for MCP becomes more necessary.

The initial MCP specification utilized a stateful network protocol (SSE) for a variety of reasons, including the need for some integrations to send various updates to the client / Agent like when the list of tools changes. Managing state is hard and may not work well with serverless architectures. Given the challenges around a stateful protocol, there was an update to the MCP specification on March 26, 2025. The new specification enables a simpler network communication called “Streamable HTTP” which can still “upgrade” to the SSE protocol when clients & servers both support it. At the time of writing, none of the official MCP SDKs yet support this new protocol so this post will focus on the SSE protocol. We will provide followup posts as the MCP SDKs add support for the new “Streamable HTTP” protocol.

For a variety of AWS-related MCP samples see the aws-samples/Sample-Model-Context-Protocol-Demos repo on GitHub.

AWS provides ways to run SSE-based MCP servers, including Amazon EC2, Amazon Elastic Kubernetes Service (EKS), and Amazon Elastic Container Service (ECS). When the new Streamable HTTP MCP protocol is available in MCP SDKs, we will investigate the potential to run MCP servers on Lambda. If you have existing Lambda functions that you want to expose as MCP servers, you can use the open source MCP2Lambda project as an MCP server proxy. This Python tool allows generative AI models to access and run Lambda functions as tools.

For now, let’s walk through how to run an MCP server on Amazon ECS and then integrate that with an Agent running on Amazon ECS. The Agent will use Amazon Bedrock and the Nova Pro model.

Let’s start with the architecture. For this example we are going to provide a REST endpoint that enables users to request an appointment to adopt a dog. That REST service will contain the Agent and MCP client which will then call our MCP scheduling service. Here’s what it looks like:

First we will need an SSE-transport based MCP server running in a VPC. As mentioned earlier there are many programming languages and libraries you can use for this, but let’s define a basic Java / Spring AI one:

The only dependencies you need for this are a Spring AI MCP server:

This MCP server could use typical HTTP authentication methods to obtain a user’s identity. In this example the the service is inaccessible from the outside world. We configured security groups in a way that only the MCP client in the VPC can communicate with it.

An example of deploying this MCP server on Amazon ECS are in the CloudFormation template of the spring-ai-agent-ecs example. Overall there isn’t anything unique about deploying an MCP server on AWS. It is deployed and operated similar to any other backend service.

If you choose to make an MCP server public or define a route to it from your machine, you can then access it from any MCP client, including the MCP Inspector used for debugging MCP servers.

We are now ready to use our MCP server in an Agent / MCP client. One option for this would be Amazon Bedrock inline agents. This option now supports connecting to MCP servers. Check out details: Harness the power of MCP servers with Amazon Bedrock Agents. Another option is to build the Agent with high-level libraries like Spring AI or directly on the Amazon Bedrock Converse API using AWS SDKs or REST APIs. For this example let’s use Spring AI and Java and expose our Agent via a REST API.

First we will need to add a few dependencies to our project (using Maven in this example):

We will also need to provide some configuration to Spring AI (for example in an application.properties file):

With that we can now write our REST server that will run the Agent including the MCP client which will connect to the MCP server:

The controller’s constructor gets a URL to the MCP server and creates and initializes the MCP client. Then a chat client (for making requests to Amazon Bedrock via the Converse API) is created with tools set to include those available through the MCP client. Then the inquire REST method provides the interface to an Agent which sends a question to Amazon Bedrock. Since the chatClient has the tools from MCP, if needed a response from Amazon Bedrock will indicate a tool call is needed and Spring AI will do the MCP server call and feed the results back to Amazon Bedrock.

Deploying this on Amazon ECS enables a easy way to connect it to the MCP server and optionally expose the REST API publicly, potentially utilizing services like API Gateway and Cognito for authentication. For an example of using CloudFormation to deploy this MCP client / REST API, see the template in the spring-ai-agent-ecs example.

The MCP server and MCP client (utilizing Amazon Bedrock) are now running on Amazon ECS. A load balancer provides access to the REST service which uses the MCP client. We can now make a natural language request to find out about when I can adopt a dog named Prancer:

And that’s it! We have an MCP server and MCP client running on AWS, utilizing Amazon Bedrock Agents. We are really excited to see the potential MCP brings to integrating Agents with data and systems. We will be building more examples of this over time, so let us know how your Agent development goes and what else you’d like to see.

To continue learning see these resources:

Note: Special thanks to Mike Chambers for helping ideate, write, and review this blog and the associated samples and to Josh Long for teaching me all about Spring AI.