DEV Community: Lovee Jain

Extending MCP Agents with the AWS MCP Server: Why Python ADK Shines?!

Lovee Jain — Tue, 27 Jan 2026 03:55:16 +0000

So if you have read Part 1: Chaining MCP Servers with Gemini ADK — The TypeScript Story!, you already know the pain I had when trying to use AWS MCP Server with ADK in Typescript — the type conversions that ADK does when listing the tools from AWS MCP server have type mismatches, due to which it is unable to register the tool we need for our next step.

But fear not, I have submitted a PR for the fix and until is approved and merged🤞🏻, let’s continue with the Python version.

For those who missed the context, here’s a TLDR;

We are creating the standard local MCP server that gives us weather of any US location.
However, for this work it really needs the latitude/longitude of the place, which we will get from Google Maps MCP Server.
Finally for this part, we will publish the weather update to an AWS SNS Topic which is subscribed by our email — so we get the direct weather update!

And we call all these MCP servers from Google’s Agent Development Kit (ADK).

Are you ready?

Prerequisites:

We are using the same weather MCP server that we created in Part 1: Chaining MCP Servers with Gemini ADK — The TypeScript Story! Find highlighted Create the weather MCP server in the post for instructions.
MCP Inspector — for checking out tools offered by different MCP servers.
Finally ADK — this time with Python, so you need to have Python 3.10 or later and pip for installing packages. Just install ADK by running the following command:

pip install google-adk

Create ADK Project and use it as an MCP Client:

It is super easy to get started with ADK when you are using Python. You can find the documentation here or follow the steps below:

Let’s create the a ADK project:

adk create weather_adk_python

This will create a basic agent that you can chat with. Feel free to test and play.

But for now we will move on and start creating MCP toolsets so that we can use our local weather MCP server and remote Google Maps MCP server! You can replace all the code with the following sections.

First, let’s add some imports:

import os
from google.adk.agents.llm_agent import LlmAgent
from google.adk.tools.mcp_tool import McpToolset
from google.adk.tools.mcp_tool.mcp_session_manager import StdioConnectionParams
from mcp import StdioServerParameters

Next, let’s define the weather MCP toolset:

get_weather = McpToolset(
    connection_params=StdioConnectionParams(
        server_params=StdioServerParameters(
            command="node",
            args=["local/path/to/weather_mcp_adk_python/weather_mcp_server/build/index.js"], # Add the correct local path to your MCP server build
        ),
    )
)

Next, let’s define Google Maps MCP toolset. Please note: You can find the instructions to get the Google Maps API Key from Part 1.

google_maps_api_key = os.environ.get("GOOGLE_MAPS_API_KEY")
if not google_maps_api_key:
    raise ValueError("GOOGLE_MAPS_API_KEY environment variable is not set")

get_coordinates = McpToolset(
    connection_params=StdioConnectionParams(
        server_params=StdioServerParameters(
            command='npx',
            args=[
                "-y",
                "@modelcontextprotocol/server-google-maps",
            ],
            env={
                "GOOGLE_MAPS_API_KEY": google_maps_api_key
            },
        ),
    ), tool_filter=["maps_geocode"]
)

Finally, define the root_agent:

root_agent = LlmAgent(
    model='gemini-2.5-flash',
    name='root_agent',
    description='A helpful assistant for finding the coordinates and telling weather in a US city/place.' ,
    instruction=(
        "You can use 'get_coordinates' tool to get the coordinates of a US location. " 
        "Once you have the coordinates, you can pass it to 'get_weather' tool to get the weather of that US location."
    ),
    tools=[get_weather, get_coordinates]
)

Now, this brings you to parity with the TS version we created in Part 1. That means it will chain your MCP calls and give you the weather update for any US location without you having to look for lat/long of that place. Let’s try it — with UI:

adk web

It works like cake! Let’s add some icing to it — let’s send this weather update to your email! How do we do that? Well, first we create an AWS SNS Topic and subscribe to it. And then use the AWS MCP server to publish the weather updates to the topic.

Create AWS Topic and Subscription:

I want to mention something important before we go ahead into some clickops. Here’s the documentation on AWS MCP servers and I highly recommend inspecting the AWS SNS-SQS MCP Server first so that we know the capabilities. You can do so by running:

npx @modelcontextprotocol/inspector

Please Note: The authorization between the MCP server and your AWS accounts are performed with AWS profile you setup on the host. If you have multiple AWS profiles in your system and you would like to use a different profile than the default one, you will need to set AWS_PROFILE in the Environment Variables before connecting to the server or you can run the inspector with the profile set:

AWS_PROFILE=myprofile npx @modelcontextprotocol/inspector

This will open the inspector where you can then list tools and explore more:

You’d find it interesting that the AWS SNS-SQS MCP Server offers tools to create SNS Topics, subscriptions and even confirm the subscription via MCP too! However, for our example we will do these steps manually and regardless, you cannot confirm the email subscription directly using the tool because it requires a token that is only available to the user.

But, we will use the publish tool within ADK to publish the weather updates to the topic that we have subscribed.

So let’s create the topic and subscribe using clickops.

Once you have logged in, navigate to SNS and create a new standard topic: weather.

Please Note: You need to tag this topic with mcp_server_version because only mcp_server_version tagged resources can be accessed by the MCP Server as a security measure. FYI, it’s value is not validated, it works as long as the tag is set to some value.

Create a new Subscription: Select the right topic, type as Email and put down your email in the enpoint.
Soon, you will get an email to confirm the subscription, confirm it.

And done ✅. Copy the Topic ARN as you will need it in the next steps.

Use AWS MCP Server in ADK:

Let’s get back to our ADK and modify it. First, we will define some variables:

TOPIC_ARN = "arn:aws:sns:ap-southeast-2:123456789:weather"
AWS_REGION = "ap-southeast-2"
AWS_PROFILE = "myprofile"

Next, we create an MCP toolset for AWS SNS and just expose the publish tool:

publish_sns = McpToolset(
    connection_params=StdioConnectionParams(
        server_params=StdioServerParameters(
            command="uvx",
            args=["awslabs.amazon-sns-sqs-mcp-server@latest"],
            env={
                "AWS_PROFILE": AWS_PROFILE
            }
        ),
    ),
    tool_filter=["publish"],
)

Now, if you inspected this tool earlier, you will find that you need to pass in the Topic ARN and the AWS Region as arguments, it cannot pick them up from the environment variables. And hence we will use the power of instructions and description in our root agent so that it picks up the right ARN and region without asking user to put those in.

Replace the root_agent part with the following:

root_agent = LlmAgent(
    model='gemini-2.5-flash',
    name='root_agent',
    description='A helpful assistant for finding the coordinates, telling weather in a US city/place and publishing the weather summary to SNS topic.',
    instruction=(
        "You can use 'get_coordinates' tool to get the coordinates of a US location. " 
        "Once you have the coordinates, you can pass it to 'get_weather' tool to get the weather of that US location. " 
        "Once prompted, you can use 'publish_sns' tool to send the weather summary as message or if the user can do any outdoor activities based on the weather to SNS topic. "
        f"Use {TOPIC_ARN} as topic ARN and {AWS_REGION} as region. Do not ask the user for it." 
    ),
    tools=[get_weather, get_coordinates, publish_sns],
)

And that’s it — let’s give it a go!

adk web

Hoorayyy!!! It works! We can now get some weather summaries and whether we can do some outdoor activities as per the weather in a particular US city — right into our inbox!

Save Yourself the Headache:

While implementing this was so much fun, it did come with a bit of a headache. So let me help you save it!

Do not forget to use the right Topic ARN and AWS Region — they are key or else you will get stuck in this infinite loop of not being able to publish to your Topic without a proper error message.
It is also the power of writing good instructions and descriptions of your agent that can yield different results, after all, it is an LLM and it is non-deterministic and can never give you the same response.
Do not forget to tag your AWS Topic — else you cannot publish!
If you have multiple AWS Profiles, I have found it really hard to get consistent results — sometimes it somehow picks the wrong or the default profile even after we are setting the right one in the environment variables. So I actually have also tried setting it up before calling adk web like this: export AWS_PROFILE=<profile_name>. It is also recommended in the ADK docs to set environment variables before running adk web.
Last, but not the least, if your toolsets also timeout when initialising, you can optionally set a higher timeout in your connection_params to prevent it.

Here’s the Github repo with all the code you need!

And if you are thinking what I am thinking, yes I potentially want to deploy all this and create something production-ready! So there’s a chance of next part to this series.

Meanwhile happy experimenting!! 🔍

API Destinations for Private Endpoints: From Oversight to Insight!

Lovee Jain — Sun, 13 Apr 2025 12:24:00 +0000

I made a mistake! I was tasked to do a discovery on how we can sync some data from a monolith to a new micro-service and I came up with 3 main solutions and a fallback:

Monolith → Event Bridge → API Destination → Exposed endpoint in the microservice

Monolith → Event Bridge → SQS ← Polling from microservice

Monolith → Event Bridge → SNS Topic → Exposed endpoint in the microservice

(Fallback) Microservice → Event Bridge → SQS → Lambda → Exposed Endpoint in the service or directly update the database

Justification and Rationale

Now I have 2 main reasons on how and why I came up with these solutions:

The monolith was already configured to send events to an event bridge
One of the requirements was to keep the monolith and microservice loosely coupled

Now if you look at the options, the choice is obvious, API Destination!! But let’s still dig a bit deeper as to why?

With API Destination, all I need to do is deploy some IaaS, expose an endpoint in the service and done!
With SQS, even easier, but polling means the service is always looking for an event. The data to be synced was not something that was changed frequently, but when it did, it was important to reflect the change and the service behaviour quickly. Furthermore even though the setup was easy, it had the complexity of batch processing, deleting messages after they were processed (yes, you need to do that manually with SQS), and the risk of the same message being delivered more than once, so service needs to be idempotent. This was all just too much for a little sync, 😕 .
With SNS topics, confirming message subscription was tricky! Furthermore, event structure was not JSON but plain text and that also meant that we get tightly coupled with AWS message structure, if that changed, we will have to adjust on our end too.

I know what you are thinking, why did I keep SQS + Lambda as a fallback? To be honest, I regret it too, I came to a point where we half-implemented this with tears in my eyes. The fact that I need to maintain another lambda, just to pass on some event payload to a service that already has an exposed endpoint was a major deterrent. The infrastructure, the code — seemed just to much effort for a little sync task. Besides, how many Lambda functions do you have sitting around, forgotten and unmaintained? We often spin up Lambdas for various tasks because they’re so easy to create — but that also means many of them linger, unused and unmanaged.

And don’t forget, because I didn’t, we also needed a dead letter queue (DLQ) in this — just in case the service is unavailable to process the data. With lambda, the re-drive solution would have become even more painful!

And hence, with all these considerations, API destination looked the most viable option!

The Pratfall

With discovery done, solution finalised, initiative created and stories refined, we went into implementation phase in the next quarter and had a, guess what??

A pratfall!!

I made a mistake, I forgot my service was internal and API destinations back then didn’t support private endpoints. This was a disaster, as it meant we couldn’t use API Destinations and mid-quarter we had to pivot, putting the initiative at risk. The advice was to use SQS + Lambda, something I really didn’t want to do, but finally had to.

And then suddenly, with a flash of lightning and a rumble of thunder, the team at AWS:ReInvent 2024 unveiled an exciting new feature for EventBridge — private API integrations! This announcement brought the whole initiative back on track, and we lived happily ever after…😁 Let’s learn more about how this feature saved the day!

How did API destinations for private endpoints save the day?

If you look at this now, you’d feel overwhelmed, but trust me even though it looks a lot, you literally just create a couple of infra resources once and you’ll be sorted for the lifetime!

Let’s understand each of these resources in detail.

Internal service and security group: We know that our internal service could be in a private subnet and not accessible to the public. But it should always have a security group attached to its load balancer. Now we need to make sure that the security group ingress allows traffic from within the VPC or the VPC in which the API destination will exist. Once we open that route, we need to create a resource gateway.

Resource Gateway: The resource gateway provides a point of ingress into a VPC (and subnets) so that clients can access resources in that VPC. The resources that will become accessible are actually defined in a Resource Configuration that is associated with the gateway. One Resource Gateway can make multiple resources available.

Resource Configuration: This is where you provide the set of resources which will be accessible through a particular resource gateway. Now your resource could either be referenced by an IP Address, or DNS Name or an AWS ARN.

In our case, let’s say the internal service has a domain name, then we can provide that domain name in the configuration. We can also provide port ranges, port 80 for HTTP and port 443 for HTTPS. There is also an optional Share resource configuration setting that you can create to share resources across AWS accounts or through AWS organisations. You can read more about it here.

API Destination and connection: Like any other AWS services, there’s a connection wrapper around the actual resource which is API destination. And if you look at the console, you’ll find Connections have updated! Yes, because that is where we will now configure connection to our private API.

We configure the invocation type as Private and attach the above resource configuration. Next we specify the authorisation type and that’s it! ✅. Once created, this will also establish a Service Network Association.

Next, we create the API destination, specify the destination endpoint and method, configure any rate limiting and use the above existing connection.

Service Network Association: Now, a service network is a logical grouping of services that can communicate with each other securely and efficiently without requiring complex networking setups. However, when you configure your API Destination connection for a Private API and specify the resource configuration, it automatically creates a service network association for the event bridge service in your resource configuration. This Service Network Association is created and managed by AWS, so there’s no extra effort required on your part!

Event Rule: Now I am assuming you already have an event bus setup, so we are going to skip that part and focus on creating the event rule that will publish events to your API destination.

So let’s define the event rule detail, we first specify the name, description and the event bus. Next if you specify the rule type as a Rule with an event pattern, then, this rule will be triggered when an event matching the pattern occurs.

Next, we need to define the pattern. We can either choose a predefined pattern that matches a certain type of event from a certain service, or you can create a custom pattern that is suited to your service. When creating a pattern only specify the fields that you are using for matching. You can read more about Event Patterns in the AWS EvenBridge Patterns User Guide. But here’s a sample event for your reference:

{
  "detail": {
    "event_type": ["SomeDataUpdate"]
  }
}

Furthermore, there are multiple comparison operators that you can choose from to compare your event pattern, we can simply use Prefix matching for our example.

Once happy with the event pattern, we can then configure the target as our API destination and specify the existing API destination that we created above. You can also pass additional headers or query parameters to your target. And finally just like any other resource, you also need to create an IAM role that will allow EventBridge to send events to your target, in this case the API Destination.

Although it is optional, it is highly recommended that you add a DLQ to your event rule so that if your service is unavailable to consume events they can be later on replayed or re-drived to your service when it is back online.

Review the rule and hit Save!

Now is the time to sit back and relax, your sync from the monolith to your internal micro-service is now active!

Extra Nugget:

If you want to make this experience even better, you can leverage an Input Transformer at the Event Bridge. Input transformers can help transform the input event from the event bridge before it gets to the target so that it is received in a certain expected format! Pretty easy to set up, and AWS provides a comprehensive guide to using them: Amazon EventBridge input transformation.

Final Treat:

Here’s the final treat for you that might save you some time! Github Repo to CloudFormation Templates for deploying API Destination resources for private endpoints.