Connect AURA AI SRE Agent to MCP Servers and Scope Tools

See AURA in action → https://www.mezmo.com/aura

A walkthrough of connecting AURA to three MCP servers in one sitting,
starting from a fresh aura init with three default workers and no MCP
connection. Adds Mezmo with a service API key, GitHub over HTTP streamable
using Authorization Bearer and a personal access token, and Grafana over
stdio through the Docker Desktop MCP Toolkit. Each server gets a different
tool-scoping decision: Mezmo goes to the log and metrics analysts only,
GitHub to no workers yet, Grafana to all three. Ends with a read through
the generated config TOML and the three transports AURA supports.

AURA is built for SREs and platform engineers who need an agent that talks
to the tools they already run, with per-worker control over which tools
each one can reach.

0:00 Standalone mode and aura init
0:21 Default config: three workers, no MCP server
0:34 Adding Mezmo with a service API key
0:55 Scoping tools to individual workers
1:23 Adding GitHub over HTTP streamable
2:20 Adding Grafana over stdio with the Docker MCP Toolkit
3:23 Reading the generated config TOML
3:56 Transports and why any MCP server works
4:23 Workers and the Kubernetes SRE multi-model example

Get started on GitHub → https://github.com/mezmo/aura

#MCPServer #AISREAgent #PlatformEngineering

Transcript

Standalone mode and aura init

(0:00) Let's look at how AURA connects to different MCP servers. Today I'm going to use AURA in standalone mode on my laptop. Because it's a new project, I'm going to run aura init. This defines the initial LLM provider; I use Anthropic. I already have an API key in my environment, and we'll use the default model.

Default config: three workers, no MCP server

(0:21) This generates a configuration file with three basic workers defined: an incident responder, a log analyst, and a metrics analyst. But there's no MCP server connected.

Adding Mezmo with a service API key

(0:34) Let's use mcp add and set up Mezmo. All it requires is a service API key. I'll paste that here, and it gets written to a .env file in my local directory. Now we can see what's going to be added to the configuration.

Scoping tools to individual workers

(0:55) I'll say yes, and now we're going to scope the tools provided by the MCP server to the different workers in the environment. I don't want to scope any of these tools to my incident responder, but I do want to scope them to the log-analyst and the metrics-analyst. We'll do a quick restart of AURA, and now we can see the MCP server is connected.

Adding GitHub over HTTP streamable

(1:23) We're also going to add the GitHub MCP server, which requires some custom configuration. I want to name it, and we're going to use HTTP streamable. I'll add the server URL, and GitHub uses Authorization Bearer. I already have the personal access token set up in my environment, so I'll use that.

Once it connects with the token, it discovered 47 tools, and it gives me the configuration it's going to add. I'm going to write that configuration out. Because I don't have any workers defined that would make use of this MCP server yet, I'll say no to all three of my existing workers.

Adding Grafana over stdio with the Docker MCP Toolkit

(2:20) The last MCP server I'm going to add is another custom one, a Grafana instance, and I'm going to use the stdio transport, because I'm running this on Docker Desktop with the MCP Toolkit. All I do is copy-paste in the command provided, and it does its validation.

You can see 73 tools discovered, and I'm going to add this one to my configuration as well. With Grafana I'm going to give all my workers access to all the tools provided by the Grafana MCP. Let's restart AURA again. Now I have all three MCP servers configured.

My next steps here would be to describe the GitHub worker for use cases like identifying recent deployments or accessing a runbook repo, but we'll do that in another video.

Reading the generated config TOML

(3:23) Let's look at the config TOML that was generated. I can see my system prompts here, and our three MCP servers. Underneath that, each of our workers is defined: our incident responder, our metrics-analyst, and our log-analyst. Within each of these configs you can see each of the tools that were identified are now added to the different MCP filters for each of these workers.

Transports and why any MCP server works

(3:56) AURA has been tested with a number of different tools and platforms, but because you have full control over the prompt for every worker, any MCP server is going to work for you. If you go into our docs, you'll see details on each of the different transports. We have HTTP streamable, SSE, and stdio.

Workers and the Kubernetes SRE multi-model example

(4:23) Lastly, a little about workers. You can do a lot with them. If you look at the Kubernetes SRE orchestrated multi-model example, that's a great reference for understanding how you would connect different MCP servers up, how you would create custom workers to use those tools, and how to customize the prompt so the worker knows what its job is and what tools to add.

Ask about this page
Perplexity
Grok
Table of contents

    More videos

    Add a Human Breakpoint to Your AI SRE Agent Workflow
    Add a Human Breakpoint to Your AI SRE Agent Workflow
    AURA use cases
    Use GitHub as a Runbook Database for AI SRE Agents
    Use GitHub as a Runbook Database for AI SRE Agents
    AURA use cases