An operations agent is only useful when it can see the system it is being asked to investigate.
AWS DevOps Agent gives teams a natural-language entry point for cloud operations tasks. TrueWatch MCP Server gives that agent a governed way to query observability data: logs, metrics, traces, RUM data, dashboards, monitors, and related investigation context. Together, they let an engineer start from a production question such as "what changed around this error spike?" and let the agent gather evidence through scoped tools instead of guessing from prompt context.
This guide walks through a practical connection flow. Treat it as an integration pattern, not a permission model. MCP answers the interface question: can the agent call the right observability tools? A production deployment still needs workspace scope, least-privilege keys, read-only defaults, approval for side-effect actions, and tool-call audit records.
What AWS DevOps Agent Adds
AWS DevOps Agent is an AI operations assistant from AWS — an AI DevOps agent designed to help users work with cloud resources, troubleshoot issues, and generate infrastructure-related output through natural-language interaction.
For observability work, the important point is not the chat interface itself. The value comes from connecting the agent to fresh production signals and keeping that access bounded. Without that connection, the agent can explain a likely failure pattern. With a scoped MCP connection, it can inspect current telemetry and cite the evidence it used.
What TrueWatch MCP Server Adds
TrueWatch is an observability platform for engineers operating modern production systems. It brings infrastructure monitoring, application performance monitoring (APM), log management, distributed traces, RUM, dashboards, alerts, and cloud resource data into a shared investigation context.
TrueWatch MCP Server exposes selected TrueWatch capabilities to MCP-compatible clients. In this article, AWS DevOps Agent connects to TrueWatch MCP Server and receives a set of read-oriented tools, such as:
- list_checkers
- list_logging_query_rules
- list_dashboards
- query_log_data
- query_metric_data
- query_trace_data
- query_rum_data
Start with read-only tools. Let the agent retrieve evidence, summarize it, and propose next steps before expanding access to workflows that change production systems.
Integration Path
The integration flow is:
AWS DevOps Agent -> MCP Server registration -> TrueWatch MCP Server -> TrueWatch observability dataThe exact AWS UI may change. The operational shape should remain familiar: register an MCP server, add the endpoint and authentication details, attach the server to an Agent Space, select allowed tools, and run a read-only investigation to verify the path.
1. Open the MCP Server Registration Entry
Open the AWS DevOps Agent console. In the function menu, go to Setting, then choose Register. The registration page lists third-party integration entries such as GitLab, ServiceNow, Slack, and MCP Server. Choose MCP Server to start the TrueWatch MCP Server registration flow.
When the association flow starts successfully, the page should display a message similar to:
AWS DevOps Agent MCP Server associated successfully2. Configure the TrueWatch MCP Server Endpoint
In the MCP server details page, complete the core configuration.
Confirm the Transport Protocol
The MCP server must support Streamable HTTP transport. Confirm this before adding the endpoint.
Select the Authorization Flow
Open Authorization configuration and select the authorization method that matches your TrueWatch MCP Server setup.
Name the Server
In Name, use a clear name such as:
TrueWatch MCP ServerUse names that describe the environment if you operate multiple workspaces, for example TrueWatch MCP Server - Production Read Only.
Add the Endpoint URL
In Endpoint URL, add the TrueWatch MCP Server endpoint for your workspace.
Example target format:
https://toby-ai.truewatch.com/toby_ai_mcp/mcpConfirm the final endpoint in the current TrueWatch documentation before publishing or sharing this guide. This URL may also appear in AWS CloudTrail logs, so avoid embedding secrets in the endpoint itself.
If the page provides Description, add a short operational note such as:
Read-only observability tools for production investigation.Enable Dynamic Client Registration only if it matches your security policy. It allows DevOps Agent to register with the MCP authorization server during the setup flow.
Click Next after the endpoint is configured.
3. Use API Key Authorization
AWS DevOps Agent supports authorization flows such as OAuth Client Credentials, OAuth 3LO, and API Key. The source setup uses API Key authorization for TrueWatch MCP Server.
This flow avoids browser redirect steps and gives the calling application a direct authentication path. In production, use a dedicated key for this agent connection and scope it to the minimum data and tools required.
Configure the Header
Set the fixed header name to:
AuthorizationConfigure the API Key Value
Use the API key and site key format defined by your TrueWatch MCP Server documentation. The source setup uses a combined value:
<TRUEWATCH_API_KEY>-<SITE_KEY>Where:
- <TRUEWATCH_API_KEY> is the API key created in the TrueWatch workspace.
- <SITE_KEY> identifies the TrueWatch deployment region or site.
Create or Review the API Key
In the TrueWatch console, open System Settings and go to API Keys. Create a key for this integration or review an existing one.
For an operations agent, the safer starting point is:
- read-only access
- workspace-scoped permissions
- no broad administrator role
- separate keys for development, staging, and production
- rotation policy and owner information
Map the Site Key
TrueWatch deployment regions map to different OpenAPI endpoints. Confirm the active map before production use. An English blog version can show the pattern without exposing internal deployment details:
const SITE_KEY_MAP = { us1: 'https://us1-openapi.truewatch.com', eu1: 'https://eu1-openapi.truewatch.com', ap1: 'https://ap1-openapi.truewatch.com',};After reviewing the configuration, click Previous if you need to check earlier settings. Then click Next to submit. A successful setup should show the MCP server association message.
4. Attach the MCP Server to an Agent Space
Return to the AWS DevOps Agent main page and open Agent Spaces.
Agent Spaces control the access range, capability boundary, and operational scope for DevOps Agent. Use separate spaces when teams, environments, or risk levels should be isolated.
Open the target Agent Space, click View details, then find MCP Server.
5. Add MCP Tools and Save the Configuration
In the MCP server tools page, select the tools AWS DevOps Agent is allowed to call.
The source setup adds seven TrueWatch MCP tools:
- list_checkers
- list_logging_query_rules
- list_dashboards
- query_log_data
- query_metric_data
- query_trace_data
- query_rum_data
Do not give the agent every tool by default. For production systems, begin with tools that only read data. Avoid tools that modify, delete, write, roll back, scale, or silence production behavior unless a separate approval path is in place.
Click Save after selecting the allowed tools.
6. Start a Read-Only Investigation
After the MCP Server and tool permissions are configured, open the Agent Space details page and choose Operator access.
This area includes operational views such as topology, capabilities, and web application access. For the first test, keep the task narrow and read-only.
Click Start investigation. In Investigation starting point, enter a specific investigation request. Good first tests include:
Analyze error logs from the last 15 minutes and group them by service and error type.or:
Find services with recent trace errors and summarize the evidence behind each finding.The prompt should tell the agent what evidence to retrieve and how to summarize it.
If the page shows statuses such as Fetching data or Investigating, and the output includes results from the MCP tools, the connection path is working.
Demo: Analyze Error Logs From the Last 15 Minutes
The source demo uses a simple request:
Analyze error logs from the last 15 minutes.AWS DevOps Agent interprets the request, prepares an investigation plan, calls TrueWatch MCP tools, and summarizes the returned data.
In the source flow, the agent:
- queried recent error data
- grouped errors by type
- identified affected services
- included raw log samples
- summarized key findings
Three services, three different failure modes — this is what microservices monitoring looks like in practice: errors tied to a specific service and time window, not folded into one generic incident.
Example Result Shape
In the demo time window, the investigation identified three categories of errors.
Configuration Not Found
- Error type: forethought.utils.exceptions.APIException
- Error code: ftLogackupCfgNoExists
- Service: inner-api
- Description: a data forwarding configuration was not found
Query Timeout
- Error type: errors.errorString
- Service: kodo-inner
- Description: internal server error caused by query timeout
Unknown API Error
- Error type: forethought.utils.exceptions.APIException
- Error code: ft.CloudCareApiError
- Service: front-api
- Description: unknown API error
The useful part is not that the agent produced a paragraph. The useful part is that the answer can be traced back to tool calls, time windows, services, log samples, and query results.
Frequently Asked Questions
Q: Should AWS DevOps Agent have write access to TrueWatch data? A: No, not initially. Start with read-only tools only. Expand to tools that modify, delete, or roll back production behavior only after you have a separate human-approval path in place.
Q: What's the safest way to set up API keys for this integration? A: Use a dedicated key scoped to this agent connection only — not a shared or admin-level key. Best practice is workspace-scoped permissions, no broad administrator role, separate keys per environment (dev/staging/production), and a rotation policy with a named owner.
Q: How do I know the integration is actually safe to run against production? A: Check three things after your first investigation: data scope (did the agent only query the intended workspace/environment/time range?), tool scope (was every enabled tool actually used — remove any that weren't), and evidence quality (can an engineer trace the answer back to a specific service, time window, error type, and query path?).
Q: What's the difference between TrueWatch MCP Server and Toby AI Agents? A: MCP Server is the interface layer — it lets an AI client call TrueWatch's observability tools. Toby AI Agents is the full operating model built on top: troubleshooting methodology, permission boundaries, evidence trails, approval flows, role-based behavior, and post-action verification. MCP answers "can the agent see the data?" — Toby AI Agents answers "should the agent act, and how do we govern that?" That's what production-ready AI agent observability actually requires.
Q: What should I avoid doing with this setup? A: Don't give the agent every available tool by default. Don't embed secrets in the endpoint URL (it may surface in AWS CloudTrail logs). Don't skip human approval for any action that changes production state. Don't run your first test in a production Agent Space — use a non-production workspace first.

