Making AWS EKS MCP Simple: How Agentgateway Improves the Interaction Process

It's no secret that LLMs sometimes give you the wrong information. It's also no secret that they're changing how we work, and more of that is for the better. However, as you use LLMs, you may want them to have access to files, tools, and data in a secure fashion that they don't already have access to (think internal tooling).

This is where MCP Servers come into play.

In this blog post, you'll learn about what MCP is, how to interact with it programmatically, and how to use Agentgateway, an open-source tool, to interact with MCP Servers in a more streamlined fashion.

Prerequisites

If you'd like to follow along in a hands-on fashion, you'll need an AWS EKS server running. If you don't have one, that's totally fine! You'll gain a ton of information that you may be able to use later once you have an EKS server running.

Quick MCP Recap

Model Context Protocol (MCP) is a server (more on the definition of a "server" later) that allows LLMs to access tools, data, and services. The goal is to do this in a secure fashion.

It functions as a "bridge" of sorts. It almost reminds people of a RAG in a sense because it's pulling in data that the LLM didn't already have, but the key difference is it's not programmatically implemented into your software like a RAG and it has a set of tooling to call out to. The concept (extending the knowledge base of an LLM) is how they are similar.

Something important to keep in mind: when you hear "server" within the "MCP Server" naming convention, it could be an actual "virtual server" running the set of tools somewhere or a package. For example, as you'll see in the next section, the EKS MCP Server has a command parameter within the JSON configuration that uses uvx, which is a Rust-based CLI part of the uv family, and it's used to programmatically interact with the EKS MCP Server package.

A Programmatic MCP Server Interaction

With anything that's implemented in a programmatic fashion, there's always a client/server architecture. The "server" is where the piece of the application stack that you're reaching out to is running and the "client" is how you interact with it. For example, when you use kubectl, that's the "client" to interact with the Kuberentes API Server.

When working with MCP servers, it's no different. The "server" is the MCP tooling that you're interacting with. In this case, it's for EKS, but there are a ton of other MCP servers available.

In the configuration below, you'll see three main pieces:

1. The libraries that you'll use to interact with MCP, JSON (to clean up the output) and async.
2. The command, arguments (to interact with the EKS MCP Server), and the env configurations.
3. The tooling itself

Take a look at the variable result. It's to make a session call to the list_k8s_resources tool, which is one of many tools available within the EKS MCP Server. It then allows you to specify the cluster name, the object/kind you want to call upon, and the API version.

import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
import json

async def main():
    server_params = StdioServerParameters(
        command="uvx",
        args=["awslabs.eks-mcp-server", "--allow-write"],
        env={
            "AWS_PROFILE": "default",
            "AWS_REGION": "us-east-1",
            "FASTMCP_LOG_LEVEL": "INFO"
        }
    )

    # Connect to EKS MCP server
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()

            result = await session.call_tool("list_k8s_resources", arguments={
                'cluster_name': 'k8squickstart-cluster',
                'kind': 'Pod',
                'api_version': 'v1',
            })
            
            for c in result.content:
                data = json.loads(c.text)
                print(json.dumps(data, indent=2))

if __name__ == "__main__":
    asyncio.run(main())

1. Save the above to a file called main.py, change the env block info if you need to, and change the cluster_name parameter to your EKS cluster name.
2. Run the following command to install the third-party package needs:

pip install mcp

You may need to use pip3 depending on how your Python environment is set up. You could also create a requirements.txt file, put mcp in that file, and run:

pip install -r requirements.txt

3. Run the file:

python main.py

You should see an output on the terminal similar to the screenshot below.

Another piece of the puzzle to note is the async library used, which is a library for concurrency in Python. Interacting with an MCP client is designed to involve:

• Non-blocking operations like fetching data
• Handling network communication
• Processing large amounts of information without stalling the application.

So using a concurrency-based library is necessary.

If you don't want to "hard-code" the MCP server, you can also use a JSON configuration to interact directly with the EKS MCP Server.

{
	"mcpServers": {
		"awslabs.eks-mcp-server": {
			"command": "uvx",
			"args": [
                "awslabs.eks-mcp-server",
                "--allow-write"
            ],
			"env": {
				"AWS_PROFILE": "default",
                "AWS_REGION": "us-west-2",
                "FASTMCP_LOG_LEVEL": "INFO"
			}
		}
	}
}

This is a great approach if you want to write a client yourself, but in certain circumstances (like day-to-day operations) you may not want to.

A Simpler Approach

As tools are either built, implemented, or used, a primary question comes up (or at least should come up): "Who's using this tool?". If it's an engineer, something that's CLI based or UI based works. If it's a technical team that may not be developers/programmers, they may feel more comfortable in a GUI.

There's another truth to this; regardless of whether you're a developer or not, based on the work you need to do, sometimes a UI or GUI is a more straightforward process.

1. Install Agentgateway.

curl https://raw.githubusercontent.com/agentgateway/agentgateway/refs/heads/main/common/scripts/get-agentgateway | bash

2. Confirm that Agentgateway was installed and is set on your path.

agentgateway --version

3. Save the following configuration to a file called eks.yaml

binds:
- port: 3000
  listeners:
  - name: eks-mcp-listener
    routes:
    - backends:
      - mcp:
          targets:
          - name: eksMCP
            stdio:
              cmd: uvx
              args:
              - awslabs.eks-mcp-server@latest
              - --allow-write
              - --allow-sensitive-data-access
              env:
                AWS_REGION: us-east-1
                FASTMCP_LOG_LEVEL: INFO
      policies:
        cors:
          allowOrigins:
          - '*'
          allowHeaders:
          - mcp-protocol-version
          - content-type
          - cache-control
          - accept
          allowMethods:
          - GET
          - POST
          - OPTIONS

You'll notice that the eks.json contains policies on how you'll interact with the MCP server, the routes that will be available to access the MCP server, and the backend which in this case is the EKS MCP Server.

4. Run the following comamnd to run Agentgateway with the config above.

agentgateway -f eks.yaml

You should see an output similar to the below:

5. Access the MCP server by going to the following address:

http://localhost:15000/ui

You can now see Agentgateway running.

6. Click the Playground tab within the UI.
7. Click the blue Connect button.

You'll now see all of the available tools within the EKS MCP Server.

To use the tools, choose one of the tools and type in the information about the resources you want to access. In the case below, you can see:

1. The cluster name to access.
2. The object/kind
3. The API version

It's no different in terms of the configurations needed than what you saw in the Python client; it's just way more straightforward to do it in a UI for quick MCP access.

Conclusion

What you saw above is just a quick glimpse into Agentgateway. The real power behind it is within the security aspects. For example, as you saw above, a route was created to interact with the EKS MCP Server. You can set up mTLS for that route to access the MCP Server securely. Within Policies via Agentgateway, you can set up Agent-to-Agent (A2A) policies, backend authentication policies, TLS, JWT, rate limiting, and more.

There's a lot of talk and buzz around MCP and why people should use it, but there isn't a lot about securing MCP. That's where Agentgateway comes into play.