Scaling MCP Across Your Organization Through AWS Lambda

As Large Language Models (LLMs) have evolved, there has been an increasing desire for organizations to bring their own data and systems to enrich the experience for end users.

This began with patterns like retrieval augmented generation (RAG) and fine-tuning which enabled teams to personalize the models to include their own data sets. From there launches such as Amazon Bedrock Agents allowed for dynamic data retrieval (such as from a relational database) and programatic inference to existing systems such as APIs.

In November 2024, Anthropic announced the launch of Model Context Protocol (MCP). This open standard was designed to create a common way for AI assistants to access tooling to these shared downstream dependencies. It's design is simple, an MCP Client connects to an MCP server to understand the available tools. The assistant can then choose to use one or more of these tools for the specified ask.

Since MCP was announced I continue to see increased interest in learning about it. As teams move from interest to ideation and finally to rollout teams will question on the best way to implement this.

As with any architecture design there will be many factors taking into approach both based on the way the team operates but also commonalities that every team will discuss. Common themes I would expect most organizations to talk about will be:

In this article I will be exploring how AWS Lambda can be used to address many of the concerns around the above questions. You will leave with understanding of how to use Lambda functions as MCP tools and even get some resources to accelerate your journey.

In the diagram above you can see how the MCP Server component of the architecture is able to directly interact with systems. Additionally business logic is performed through familiar programming languages. This logic is encapsulated in a tool, which is then registered for usage when an LLM is deciding on the path forward given a provided prompt.

Today an MCP server and tools can either be hosted locally or remote. The purpose of this article is not discuss the trade-offs but to imagine a third way. What if the MCP server was locally, but the tools were registered as Lambda functions?

As you can see in the diagram above, the initial workflow remains the same. But now rather than tooling being defined within the same codebase as the MCP Server, it is registered on start and invoked within AWS.

Within the remaining sections of the article I will address how this design can be used to address the questions posed in the introduction.

Whether you are a startup, large enterprise or public sector or organization, security is likely to be at the top of your mind as you begin the journey to MCP. And rightfully so, you are likely considering exposing an AI assistant to some of your downstream systems.

One of the top concerns is likely to be how do we prevent unauthorized users or workloads from accessing capabilities they should not be able to perform. When each tool is a Lambda function it automatically gains the benefit of AWS IAM, enforcing governance when it comes to which Lambda functions can be invoked.

As you can see in the above IAM policy, should this be attached to my user I will only be able to access two of the tools from our architecture diagram. This could even be enhanced by using pattern matching or the condition keys of a tag. Furthermore this policy can be attached to a collection of users or applications, allowing you to centrally govern tool usage to a set of users.

In addition to the authorization of which Lambda functions can be invoked, each function may also take a users identifier to make further decision making for logic. Examples of this may be passing a JWT token to the function, which can determine logic such as a user should only be able to modify their own booking or in a multi-tenanted system which Amazon DynamoDB table is needed to return back a result.

Another concern that is likely to come up is regarding the software lifecycle, specifically around addressing security vulnerabilities and patching dependencies. When tools are operating locally the cycle for upgrading code assets is likely to be slower as it is dependant on the consumer of the service to perform the upgrade. This is further complicated by constraints such as operating systems used, users level of technical experience and central communication that an upgrade is needed.

When each tool is deployed as a Lambda function the cycle for patching and rolling out can be reduced as the above constraints are removed from the management of the tool. This overhead is further reduced by features such as versions and aliases which allow for a consistent snapshot in time of the version of the tool and it's dependencies. By using these features rollout strategies can be more controlled by validating with a subset of users before promoting using a strategy such as a canary deployment.

Now that security concerns have been addressed, the next question is likely to be how can the operational overhead of having, tens, hundreds or maybe even more tools within your organization.

In the diagram during the introduction we saw three MCP servers, each of which will have a collection of tools. But consider how this looks if each teams within your organization had multiple tools. Even if each team had one server very quickly this could become challenging to manage which servers are needed by yourself or the application.

The alternative would be to have a single MCP server which each teams registers their own tools into, but again depending on the velocity of development and contributors this may eventually slow down the process.

Returning back to our Lambda function implementation, the number of MCP servers can be reduced substantially maybe even down to one. Instead tools are a separate resource which can still be managed by a single team, however there is no longer an explicit requirement that ties a MCP server to team ownership.

It is possible some organizations may adopt that the MCP server responsible is maintained by a central team such as a platform team. For others, a team may maintain ownership. In both of these cases the tooling capability is managed separately from the server by other teams.

When building an MCP server, an early consideration is likely to be which language should it be developed in. In an architecture where tools are embedded in the MCP server this creates a tight coupling between the server and tools implementation. If different team members have preferences for a specific tool this would create additional MCP servers.

As you might have guessed, by using a Lambda function to implement the tool the language is decoupled between the one the server is written in and the tool itself. In the same way that a microservice doesn't care about the underlying implementation details of its downstream dependencies, this approach allows server and tool to be rewritten without impacting the other.

When I build a tool I want others (both on my team and other teams) to be able to benefit from using it either directly or indirectly with little to no effort.

I discussed during the security section that governance of which tools we should be allowed to use is managed through IAM permissions. Further to this you can automatically register the tools you want to use without explicitly naming each function in turn. This is again possible in AWS through another capability, tags.

Tags allow metadata to be attached to resources in AWS in a key-value based format. This can help to understand collections of resources for use cases like cost analysis. In the case of MCP this can be used to filter the Lambda functions based on a set of values such as only those with "MCP_Support" being set to true. Furthermore particular tools can be exposed from being used such as from a specific owner or even a tool marked as experimental.

As teams continue to add tools, I would expect discoverability (influenced by similar projects such as Constructs Hub which enabled search for AWS CDK constructs). This is possible through the ability to automatically register tools programatically, and supports out the box metadata filtering via tags.

In addition I imagine that many teams will consider if tools should be externally facing to consumers of their services. Or perhaps an internal tool that is used to drive an external facing tools answer, in a similar way to which domain driven design operates (perhaps a topic for a future article).

In this article I have explored how using Lambda functions for tool usage can help address key concerns, whilst also increasing the agility for teams to expose these capabilities.

If you want to get started today, look no further than the AWS Lambda MCP Server created by Danilo Poccia. This resource will allow you to rapidly validate and test your own Lambda functions powered by a local MCP server.