Investigate CX incidents with AWS DevOps Agent

Your agents report choppy audio on inbound calls, and a CloudWatch alarm fires at the same time. AWS DevOps Agent investigates the AWS side on its own: metrics, logs, recent deployments, and your application topology. Connect it to the Operata MCP Server, and the same investigation can also see which calls degraded, on which network, for which agents, and what those agents reported. This page is for the AWS administrator who runs DevOps Agent for a contact center team. The job is to register the Operata MCP Server once at the account level, then allowlist its tools in the Agent Space that handles CX incidents. There’s no code to deploy.

Use cases

An alarm fires on Amazon Connect. The investigation checks your AWS resources, then queries Operata for the calls, queues, and sites that degraded in the same window.
A ticket names a bad call. You paste the contact ID into the investigation, and the agent pulls that call’s media quality, the agent’s device and network, and any issue the agent reported.
A change goes out and you want to know if CX moved. You ask in Chat whether mean opinion score (MOS), jitter, or round-trip time shifted after the deployment, and the agent compares before and after.

How it works

DevOps Agent reaches Operata over MCP as the Operata user who authorized the connection. It discovers Operata’s authorization server, registers its own OAuth client with Dynamic Client Registration (DCR), and stores the resulting token for you. Registration happens at the account level and is shared by every Agent Space in that account. Each Agent Space then chooses which Operata tools it may call.

Before you start

An AWS account with AWS DevOps Agent and an Agent Space. This recipe was configured in us-east-1.
Permission to register capability providers and edit the Agent Space.
An Operata user with the Admin or User role to authorize the connection. Viewer accounts and RBAC users can’t use the MCP Server.

The connection runs as whoever signs in to Operata during registration, and reaches only that user’s groups. To give DevOps Agent access to more than one Operata group, sign in with a service account that Operata creates for you, not a person’s own login. Contact your Customer Success Manager to have one set up before you register the server.

Why this recipe uses DCR

DCR is the recommended way to connect. DevOps Agent registers its own client with Operata, so there’s no client ID or secret to create, store, or rotate. Access follows the signed-in user’s role and groups, and every call is attributable to that user. An API key is the alternative for a single group. See API key alternative below.

Steps

1. Register the Operata MCP server

Sign in to the AWS Management Console and open the AWS DevOps Agent console.
Go to Capability Providers in the side navigation.
Find MCP Server under Available providers and choose Register.
On MCP server details, enter:
- Name — operata
- Endpoint URL — https://mcp.operata.io/mcp
- Description — see below
Select Enable Dynamic Client Registration, then choose Next.
Under Authorization flow, select OAuth 3LO, then choose Next.
Review the details and choose Submit.
The Operata sign-in page opens. Sign in with the account that should own the connection, and approve access. You return to the DevOps Agent console.

DevOps Agent validates the connection, and the server appears under Capability Providers with the authorization method oauth-3lo. The description helps the agent decide when Operata is the right source. Something like:

Example - server description

Operata CX observability for the contact center. Call quality (MOS, jitter,
packet loss, round-trip time), agent softphone, device, and network
diagnostics, agent-reported issues, and end-to-end customer journey traces.

2. Add the server to your Agent Space

In the DevOps Agent console, select your Agent Space.
Open the Capabilities tab.
In MCP Servers, choose Add, then select operata.
Choose Select specific tools and allowlist the tools below.
Choose Add.

Every Operata tool reads data. None of them changes anything in your Operata account, so allowlist them as read-only. Check switch_group in particular: if it’s classified as mutating, the agent needs operator approval every time it changes group.

Tool	What the agent uses it for
`list_groups`, `switch_group`	Find and select the Operata group to query.
`get_schema`	Learn valid services and field paths before querying.
`traces_list`, `traces_query`, `traces_get`	Find calls, aggregate quality metrics, and read a full trace.
`traces_insights`, `traces_span_logs`	Diagnose one trace and its spans.
`agent_logs`, `agent_status`, `agent_reported_issues`	Browser debug logs, presence changes, and issues agents reported.
`knowledge`	Search Operata documentation.

See the MCP tool reference for what each tool takes and returns.

3. Run an investigation

Open the Agent Space web app, go to Incident Response, and describe the incident. Name Operata and the window so the agent knows to reach for it:

Agents on the Sydney site reported choppy audio on inbound calls from
09:00 to 10:30 UTC today. Use Operata to find which calls degraded and
what they have in common, then check our AWS networking and Amazon
Connect metrics for the same window.

If the connection reaches more than one group, name the group too, for example: “Switch to the Operata group Contact Centre AU first.”

What you get

The investigation timeline shows each Operata tool call next to the AWS evidence the agent gathered. A good run starts with get_schema, narrows the calls with traces_query, and opens the worst of them with traces_get. The summary then names the cause, such as degraded calls sharing one internet service provider or one agent site, with the numbers behind it. You can steer a running or completed investigation with Chat with investigation, for example to ask the agent to compare against the previous week.

API key alternative

If you only need one Operata group and don’t want the connection tied to a user, register the API-key endpoint https://api.operata.io/v1/mcp instead. Create the key in Operata under Group Settings → API Management → Create New Key. The console’s OAuth 3LO flow can’t be scripted, but a bearer-token registration can:

aws devops-agent register-service --region us-east-1 \
  --service mcpserver \
  --service-details '{
    "mcpserver": {
      "name": "operata-api-key",
      "endpoint": "https://api.operata.io/v1/mcp",
      "authorizationConfig": {
        "bearerToken": {
          "tokenName": "operata-mcp",
          "tokenValue": "'"$OPERATA_API_KEY"'"
        }
      }
    }
  }'

The trade-offs are covered in Choose how to connect: the key is fixed to its own group, and activity is attributed to the key rather than a person.

Limits

An Agent Space can allowlist up to 500 MCP tools across all MCP servers.
A key-based connection shares 100 requests per minute across every investigation. See Rate limits.
An API key is fixed to its own group. switch_group to another group returns 403 "API key access is restricted to its own group".
To remove the server, take it out of every Agent Space first, then deregister it under Capability Providers.

Troubleshooting

Symptom	Cause and fix
Registration fails after the Operata sign-in	The signing-in user is a Viewer or an RBAC user. Sign in with an Admin or User account.
`list_groups` returns only one group	The connection runs as a user with access to one group. Ask your Customer Success Manager for a multi-group service account, then re-authorize.
Operata calls start failing with an authorization error	The stored token is no longer valid, for example because the user’s access changed. Select the server under Capability Providers, choose Actions → Update, and re-run the sign-in. Agent Space associations are kept.
The investigation never calls Operata	The prompt didn’t point at CX data, or the tools aren’t allowlisted in this Agent Space. Name Operata in the prompt and check Capabilities → MCP Servers.
`403 API key access is restricted to its own group`	The agent tried to switch groups on an API-key connection. Use the DCR connection, or keep to the key’s group.

More failure modes in MCP troubleshooting.

Operata MCP server — authentication, groups, and regions.
MCP tool reference — what each tool takes and returns.
Diagnose voice incidents with Amazon Bedrock — the same data from your own Lambda.
Connecting MCP servers — AWS documentation.
Autonomous incident response — AWS documentation.

​Use cases

​How it works

​Before you start

​Why this recipe uses DCR

​Steps

​1. Register the Operata MCP server

​2. Add the server to your Agent Space

​3. Run an investigation

​What you get

​API key alternative

​Limits

​Troubleshooting

​Related

Use cases

How it works

Before you start

Why this recipe uses DCR

Steps

1. Register the Operata MCP server

2. Add the server to your Agent Space

3. Run an investigation

What you get

API key alternative

Limits

Troubleshooting

Related