Overview
The AWS DevOps Agent is an AI assistant for operating AWS workloads. By registering Bronto’s hosted MCP server as a Capability Provider, the DevOps Agent can search your Bronto logs and traces and call Bronto’s time-series and schema-discovery tools while it investigates issues — grounding its reasoning in your actual telemetry data instead of just AWS service state. This page walks through registering the Bronto MCP server in the AWS DevOps Agent console using API-key authentication. For the underlying AWS workflow, see the AWS documentation on connecting MCP servers.Prerequisites
- A Bronto account with data being ingested. If you haven’t sent data yet, set up an agent first.
- A Bronto API key with search permissions. See API Keys.
- Access to the AWS DevOps Agent in your AWS account, with permission to register Capability Providers.
- The Bronto hosted MCP endpoint for your region — see Hosted MCP Server.
| Region | Hosted MCP Endpoint URL |
|---|---|
| US | https://mcp.us.bronto.io/mcp |
| EU | https://mcp.eu.bronto.io/mcp |
Register the Bronto MCP server
Open the Register MCP Server wizard
In the AWS DevOps Agent console, open Capability Providers and start the Register MCP Server flow.
Step 1 — MCP server details
Enter the server details:
Bronto’s hosted MCP server implements the Streamable HTTP transport, which is what the DevOps Agent requires.
| Field | Value |
|---|---|
| Name | BrontoMCPServer (or any name you prefer) |
| Endpoint URL | The hosted MCP endpoint for your region (see above) |
| Description | Optional |
Step 2 — Authorization Flow
Select API Key as the authorization flow. The Bronto hosted MCP server authenticates incoming requests via a static API-key header, so this is the correct option — not OAuth or AWS SigV4.
Step 3 — Authorization Configuration
Enter the API-key configuration that Bronto expects:
| Field | Value |
|---|---|
| API Key Name | BrontoAPIKey (display name only) |
| API Key Header | X-BRONTO-API-KEY |
| API Key Value | Your Bronto API key |
Select MCP server tools
After registration, the DevOps Agent prompts you to choose which Bronto tools it is allowed to call. The Bronto hosted MCP server exposes a set of read-only tools that cover schema discovery, log and trace search, time-series analysis, and saved searches. Traces are stored alongside logs in Bronto datasets, so the samesearch_logs and timeseries tools work over both.
get_datasets and get_keys to discover the right dataset and schema before issuing a search_logs or timeseries query.
For full descriptions of each tool, see Hosted MCP Server — Capabilities.
As shown in the AWS UI, only enable MCP tools that are read-only. All Bronto tools listed here are read-only — they query log and trace data and metadata without modifying anything in your Bronto account.
Verify the connection
Open an Agent Space in the AWS DevOps Agent console and ask a question that requires Bronto data, for example:get_datasets against the Bronto MCP server and return the datasets in your account.
Example use cases
Once the Bronto Capability Provider is attached to an Agent Space, the DevOps Agent can combine AWS service state with Bronto telemetry in a single investigation. A few common workflows:Root-cause a service incident with log context
When a service is misbehaving — elevated errors, failing health checks, customer reports, or a triggered alert — the agent can identify the affected resource in AWS and then callsearch_logs against the Bronto dataset for that service to surface the errors driving the incident. That includes stack traces, request IDs, and downstream-dependency failures that aren’t visible from AWS service state alone.
Investigate latency regressions across services
Ask the agent to compare current latency to a baseline window usingtimeseries, then drill into the slowest traces via search_logs over your trace data. This is especially effective for spotting whether a regression is concentrated in one service, one endpoint, or one downstream dependency — without having to switch between the AWS console and Bronto.
Correlate deployments with error spikes
Point the agent at a recent ECS, EKS, or Lambda deployment and ask whether errors increased after the rollout. The agent uses AWS to identify the deploy window and Bronto to count and sample errors before and after — giving you a quick verdict on whether to roll back.Diagnose noisy or failing AWS Lambda functions
For a specific Lambda function, the agent can fetch recent invocations from AWS and then callsearch_logs with the function name as a filter to summarise the dominant error patterns. Useful when a function is silently retrying, timing out, or hitting a downstream rate limit.
Investigate elevated 5xx responses behind ALB or API Gateway
Combine AWS ALB or API Gateway metrics with Bronto access logs to find the host, path, and upstream service driving a 5xx spike. The agent can useget_keys to discover the right fields in your dataset before grouping and filtering — without you having to remember the schema.
Trace a request across services
When you have a request ID, trace ID, or user ID from an AWS support case, ask the agent to find every related event in Bronto. The agent searches across log and trace datasets to assemble a timeline of what happened to that request, including which services it touched and where it failed.Troubleshooting
Authentication errors when the agent calls Bronto. Double-check that the API Key Header is exactlyX-BRONTO-API-KEY and that the API key value is valid and has search permissions. Also confirm you registered the endpoint for the correct region (US vs EU) — a mismatched region returns an authentication error.
The agent does not call Bronto tools. Confirm the tools were enabled on the Select MCP server tools step, and that the Bronto Capability Provider is attached to the Agent Space where you are prompting from.