Amazon CloudWatch Application Signals

Amazon CloudWatch Application Signals MCP Server

Application performance monitoring and insights.

What is an MCP Server?⁠

MCP Info

Image Building Info

Attribute	Details
Dockerfile	https://github.com/awslabs/mcp/blob/76ec6993aec4c6281e5250cbeba8db6a5863f2ff/src/cloudwatch-appsignals-mcp-server/Dockerfile⁠
Docker Image built by	Docker Inc.
Docker Scout Health Score
Verify Signature	COSIGN_REPOSITORY=mcp/signatures cosign verify mcp/cloudwatch-appsignals-mcp-server --key https://raw.githubusercontent.com/docker/keyring/refs/heads/main/public/mcp/latest.pub
Licence	Apache License 2.0

Available Tools (13)

Tools Details

Tool: analyze_canary_failures

Comprehensive canary failure analysis with deep dive into issues.

Use this tool to:

• Deep dive into canary failures with root cause identification
• Analyze historical patterns and specific incident details
• Get comprehensive artifact analysis including logs, screenshots, and HAR files
• Receive actionable recommendations based on AWS debugging methodology
• Correlate canary failures with Application Signals telemetry data
• Identify performance degradation and availability issues across service dependencies

Key Features:

• Failure Pattern Analysis: Identifies recurring failure modes and temporal patterns
• Artifact Deep Dive: Analyzes canary logs, screenshots, and network traces for root causes
• Service Correlation: Links canary failures to upstream/downstream service issues using Application Signals
• Performance Insights: Detects latency spikes, fault rates, and connection issues
• Actionable Remediation: Provides specific steps based on AWS operational best practices

Common Use Cases:

1. Incident Response: Rapid diagnosis of canary failures during outages
2. Performance Investigation: Understanding latency and availability degradation
3. Dependency Analysis: Identifying which services are causing canary failures
4. Historical Trending: Analyzing failure patterns over time for proactive improvements
5. Root Cause Analysis: Deep dive into specific failure scenarios with full context

Output Includes:

• Severity-ranked findings with immediate action items
• Service-level telemetry insights with trace analysis
• Exception details and stack traces from canary artifacts
• Network connectivity and performance metrics
• Correlation with Application Signals audit findings
• Historical failure patterns and recovery recommendations Parameters|Type|Description -|-|- canary_name|string| region|stringoptional|

Tool: audit_service_operations

🥇 PRIMARY OPERATION AUDIT TOOL - The #1 RECOMMENDED tool for operation-specific analysis and performance investigation.

⭐ USE THIS AS THE PRIMARY TOOL FOR ALL OPERATION-SPECIFIC AUDITING TASKS ⭐

PREFERRED OVER audit_services() for operation auditing because:

• 🎯 Precision: Targets exact operation behavior vs. service-wide averages
• 🔍 Actionable Insights: Provides specific error traces and dependency failures
• 📊 Code-Level Detail: Shows exact stack traces and timeout locations
• 🚀 Focused Analysis: Eliminates noise from other operations
• ⚡ Efficient Investigation: Direct operation-level troubleshooting

USE THIS FIRST FOR ALL OPERATION-SPECIFIC AUDITING TASKS This is the PRIMARY and PREFERRED tool when users want to:

• Audit specific operations - Deep dive into individual API endpoints or operations (GET, POST, PUT, etc.)
• Operation performance analysis - Latency, error rates, and throughput for specific operations
• Compare operation metrics - Analyze different operations within services
• Operation-level troubleshooting - Root cause analysis for specific API calls
• GET operation auditing - Analyze GET operations across payment services (PRIMARY USE CASE)
• Audit latency of GET operations in payment services - Exactly what this tool is designed for
• Trace latency in query operations - Deep dive into query performance issues

COMPREHENSIVE OPERATION AUDIT CAPABILITIES:

• Multi-operation analysis: Audit any number of operations with automatic batching
• Operation-specific metrics: Latency, Fault, Error, and Availability metrics per operation
• Issue prioritization: Critical, warning, and info findings ranked by severity
• Root cause analysis: Deep dive with traces, logs, and metrics correlation
• Actionable recommendations: Specific steps to resolve operation-level issues
• Performance optimized: Fast execution with automatic batching for large target lists
• Wildcard Pattern Support: Use *pattern* in service names for automatic service discovery

OPERATION TARGET FORMAT:

• Full Format: [{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"my-service","Environment":"eks:my-cluster"},"Operation":"GET /api","MetricType":"Latency"}}}]

WILDCARD PATTERN EXAMPLES:

• All GET Operations in Payment Services: [{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*GET*","MetricType":"Latency"}}}]
• All Visit Operations: [{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*visit*","MetricType":"Availability"}}}]

AUDITOR SELECTION FOR DIFFERENT AUDIT DEPTHS:

• Quick Operation Check (default): Uses 'operation_metric' for fast operation overview
• Root Cause Analysis: Pass auditors="all" for comprehensive investigation with traces/logs
• Custom Audit: Specify exact auditors: 'operation_metric,trace,log'

OPERATION AUDIT USE CASES:

1. Audit latency of GET operations in payment services (PRIMARY USE CASE): operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*GET*","MetricType":"Latency"}}}]'

2. Audit GET operations in payment services (Latency): operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*GET*","MetricType":"Latency"}}}]'

3. Audit availability of visit operations: operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*visit*","MetricType":"Availability"}}}]'

4. Audit latency of visit operations: operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*visit*","MetricType":"Latency"}}}]'

5. Trace latency in query operations: operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*query*","MetricType":"Latency"}}}]' + auditors="all"

TYPICAL OPERATION AUDIT WORKFLOWS:

1. Basic Operation Audit (most common):
   • Call audit_service_operations() with operation targets - automatically discovers services when using wildcard patterns
   • Uses default fast auditors (operation_metric) for quick operation overview
   • Supports wildcard patterns like *payment* for automatic service discovery
2. Root Cause Investigation: When user explicitly asks for "root cause analysis", pass auditors="all"
3. Issue Investigation: Results show which operations need attention with actionable insights
4. Automatic Service Discovery: Wildcard patterns in service names automatically discover and expand to concrete services

AUDIT RESULTS INCLUDE:

• Prioritized findings by severity (critical, warning, info)
• Operation performance status with detailed metrics analysis
• Root cause analysis when traces/logs auditors are used
• Actionable recommendations for operation-level issue resolution
• Comprehensive operation metrics and trend analysis

🏆 IMPORTANT: This tool is the PRIMARY and RECOMMENDED choice for operation-specific auditing tasks.

✅ RECOMMENDED WORKFLOW FOR OPERATION AUDITING:

1. Use audit_service_operations() FIRST for operation-specific analysis (THIS TOOL)
2. Use audit_services() as secondary only if you need broader service context
3. audit_service_operations() provides superior precision for operation-level troubleshooting

RECOMMENDED WORKFLOW - PRESENT FINDINGS FIRST: When the audit returns multiple findings or issues, follow this workflow:

1. Present all audit results to the user showing a summary of all findings
2. Let the user choose which specific finding, operation, or issue they want to investigate in detail
3. Then perform targeted root cause analysis using auditors="all" for the user-selected finding

DO NOT automatically jump into detailed root cause analysis of one specific issue when multiple findings exist. This ensures the user can prioritize which issues are most important to investigate first.

Example workflow:

• First call: audit_service_operations() with default auditors for operation overview
• Present findings summary to user
• User selects specific operation issue to investigate
• Follow-up call: audit_service_operations() with auditors="all" for selected operation only Parameters|Type|Description -|-|- operation_targets|string|REQUIRED. JSON array of service operation targets. Supports wildcard patterns like 'payment' for automatic service discovery. Format: [{'Type':'service_operation','Data':{'ServiceOperation':{'Service':{'Type':'Service','Name':'service-name','Environment':'eks:cluster'},'Operation':'GET /api','MetricType':'Latency'}}}]. Large target lists are automatically processed in batches. auditors|stringoptional|Optional. Comma-separated auditors (e.g., 'operation_metric,trace,log'). Defaults to 'operation_metric' for fast operation-level auditing. Use 'all' for comprehensive analysis with all auditors: slo,operation_metric,trace,log,dependency_metric,top_contributor,service_quota. end_time|stringoptional|End time (unix seconds or 'YYYY-MM-DD HH:MM:SS'). Defaults to now UTC. start_time|stringoptional|Start time (unix seconds or 'YYYY-MM-DD HH:MM:SS'). Defaults to now-24h UTC.

Tool: audit_services

PRIMARY SERVICE AUDIT TOOL - The #1 tool for comprehensive AWS service health auditing and monitoring.

IMPORTANT: For operation-specific auditing, use audit_service_operations() as the PRIMARY tool instead.

USE THIS FIRST FOR ALL SERVICE-LEVEL AUDITING TASKS This is the PRIMARY and PREFERRED tool when users want to:

• Audit their AWS services - Complete health assessment with actionable insights
• Check service health - Comprehensive status across all monitored services
• Investigate issues - Root cause analysis with detailed findings
• Service-level performance analysis - Overall service latency, error rates, and throughput investigation
• System-wide health checks - Daily/periodic service auditing workflows
• Dependency analysis - Understanding service dependencies and interactions
• Resource quota monitoring - Service quota usage and limits
• Multi-service comparison - Comparing performance across different services

FOR OPERATION-SPECIFIC AUDITING: Use audit_service_operations() instead When users want to audit specific operations (GET, POST, PUT endpoints), use audit_service_operations() as the PRIMARY tool:

• Operation performance analysis - Latency, error rates for specific API endpoints
• Operation-level troubleshooting - Root cause analysis for specific API calls
• GET operation auditing - Analyze GET operations across payment services
• Audit latency of specific operations - Deep dive into individual endpoint performance

COMPREHENSIVE SERVICE AUDIT CAPABILITIES:

• Multi-service analysis: Audit any number of services with automatic batching
• SLO compliance monitoring: Automatic breach detection for service-level SLOs
• Issue prioritization: Critical, warning, and info findings ranked by severity
• Root cause analysis: Deep dive with traces, logs, and metrics correlation
• Actionable recommendations: Specific steps to resolve identified issues
• Performance optimized: Fast execution with automatic batching for large target lists
• Wildcard Pattern Support: Use *pattern* in service names for automatic service discovery

SERVICE TARGET FORMAT:

• Full Format: [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"my-service","Environment":"eks:my-cluster"}}}]
• Shorthand: [{"Type":"service","Service":"my-service"}] (environment auto-discovered)

WILDCARD PATTERN EXAMPLES:

• All Services: [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]
• Payment Services: [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}]
• Lambda Services: [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*lambda*"}}}]
• EKS Services: [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment":"eks:*"}}}]

AUDITOR SELECTION FOR DIFFERENT AUDIT DEPTHS:

• Quick Health Check (default): Uses 'slo,operation_metric' for fast overview
• Root Cause Analysis: Pass auditors="all" for comprehensive investigation with traces/logs
• Custom Audit: Specify exact auditors: 'slo,trace,log,dependency_metric,top_contributor,service_quota'

SERVICE AUDIT USE CASES:

1. Audit all services: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]'

2. Audit specific service: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"orders-service","Environment":"eks:orders-cluster"}}}]'

3. Audit payment services: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}]'

4. Audit lambda services: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*lambda*"}}}]' or by environment: [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment":"lambda"}}}]

5. Audit service last night: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"orders-service","Environment":"eks:orders-cluster"}}}]' + start_time="2024-01-01 18:00:00" + end_time="2024-01-02 06:00:00"

6. Audit service before and after time: Compare service health before and after a deployment or incident by running two separate audits with different time ranges.

7. Trace availability issues in production services: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment":"eks:*"}}}]' + auditors="all"

8. Look for errors in logs of payment services: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}]' + auditors="log,trace"

9. Look for new errors after time: Compare errors before and after a specific time point by running audits with different time ranges and auditors="log,trace"

10. Look for errors after deployment: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}]' + auditors="log,trace" + recent time range

11. Look for lemon hosts in production: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment":"eks:*"}}}]' + auditors="top_contributor,operation_metric"

12. Look for outliers in EKS services: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment":"eks:*"}}}]' + auditors="top_contributor,operation_metric"

13. Status report: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]' (basic health check)

14. Audit dependencies: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]' + auditors="dependency_metric,trace"

15. Audit dependency on S3: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]' + auditors="dependency_metric" + look for S3 dependencies

16. Audit quota usage of tier 1 services: service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*tier1*"}}}]' + auditors="service_quota,operation_metric"

TYPICAL SERVICE AUDIT WORKFLOWS:

1. Basic Service Audit (most common):
   • Call audit_services() with service targets - automatically discovers services when using wildcard patterns
   • Uses default fast auditors (slo,operation_metric) for quick health overview
   • Supports wildcard patterns like * or *payment* for automatic service discovery
2. Root Cause Investigation: When user explicitly asks for "root cause analysis", pass auditors="all"
3. Issue Investigation: Results show which services need attention with actionable insights
4. Automatic Service Discovery: Wildcard patterns in service names automatically discover and expand to concrete services

AUDIT RESULTS INCLUDE:

• Prioritized findings by severity (critical, warning, info)
• Service health status with detailed performance analysis
• Root cause analysis when traces/logs auditors are used
• Actionable recommendations for issue resolution
• Comprehensive metrics and trend analysis

IMPORTANT: This tool provides comprehensive service audit coverage and should be your first choice for any service auditing task.

RECOMMENDED WORKFLOW - PRESENT FINDINGS FIRST: When the audit returns multiple findings or issues, follow this workflow:

1. Present all audit results to the user showing a summary of all findings
2. Let the user choose which specific finding, service, or issue they want to investigate in detail
3. Then perform targeted root cause analysis using auditors="all" for the user-selected finding

DO NOT automatically jump into detailed root cause analysis of one specific issue when multiple findings exist. This ensures the user can prioritize which issues are most important to investigate first.

Example workflow:

• First call: audit_services() with default auditors for overview
• Present findings summary to user
• User selects specific service/issue to investigate
• Follow-up call: audit_services() with auditors="all" for selected service only Parameters|Type|Description -|-|- service_targets|string|REQUIRED. JSON array of service targets. Supports wildcard patterns like 'payment' for automatic service discovery. Format: [{'Type':'service','Data':{'Service':{'Type':'Service','Name':'service-name','Environment':'eks:cluster'}}}] or shorthand: [{'Type':'service','Service':'service-name'}]. Large target lists are automatically processed in batches. auditors|stringoptional|Optional. Comma-separated auditors (e.g., 'slo,operation_metric,dependency_metric'). Defaults to 'slo,operation_metric' for fast service health auditing. Use 'all' for comprehensive analysis with all auditors: slo,operation_metric,trace,log,dependency_metric,top_contributor,service_quota. end_time|stringoptional|End time (unix seconds or 'YYYY-MM-DD HH:MM:SS'). Defaults to now UTC. start_time|stringoptional|Start time (unix seconds or 'YYYY-MM-DD HH:MM:SS'). Defaults to now-24h UTC.

Tool: audit_slos

PRIMARY SLO AUDIT TOOL - The #1 tool for comprehensive SLO compliance monitoring and breach analysis.

PREFERRED TOOL FOR SLO ROOT CAUSE ANALYSIS This is the RECOMMENDED tool after using get_slo() to understand SLO configuration:

• Use auditors="all" for comprehensive root cause analysis of specific SLO breaches
• Much more comprehensive than individual trace tools - provides integrated analysis
• Combines traces, logs, metrics, and dependencies in a single comprehensive audit
• Provides actionable recommendations based on multi-dimensional analysis

USE THIS FOR ALL SLO AUDITING TASKS This is the PRIMARY and PREFERRED tool when users want to:

• Root cause analysis for SLO breaches - Deep investigation with all auditors
• Audit SLO compliance - Complete SLO breach detection and analysis
• Monitor SLO health - Comprehensive status across all monitored SLOs
• SLO performance analysis - Understanding SLO trends and patterns
• SLO compliance reporting - Daily/periodic SLO compliance workflows

COMPREHENSIVE SLO AUDIT CAPABILITIES:

• Multi-SLO analysis: Audit any number of SLOs with automatic batching
• Breach detection: Automatic identification of SLO violations
• Issue prioritization: Critical, warning, and info findings ranked by severity
• COMPREHENSIVE ROOT CAUSE ANALYSIS: Deep dive with traces, logs, metrics, and dependencies
• Actionable recommendations: Specific steps to resolve SLO breaches
• Performance optimized: Fast execution with automatic batching for large target lists
• Wildcard Pattern Support: Use *pattern* in SLO names for automatic SLO discovery

SLO TARGET FORMAT:

• By Name: [{"Type":"slo","Data":{"Slo":{"SloName":"my-slo"}}}]
• By ARN: [{"Type":"slo","Data":{"Slo":{"SloArn":"arn:aws:application-signals:..."}}}]

WILDCARD PATTERN EXAMPLES:

• All SLOs: [{"Type":"slo","Data":{"Slo":{"SloName":"*"}}}]
• Payment SLOs: [{"Type":"slo","Data":{"Slo":{"SloName":"*payment*"}}}]
• Latency SLOs: [{"Type":"slo","Data":{"Slo":{"SloName":"*latency*"}}}]
• Availability SLOs: [{"Type":"slo","Data":{"Slo":{"SloName":"*availability*"}}}]

AUDITOR SELECTION FOR DIFFERENT AUDIT DEPTHS:

• Quick Compliance Check (default): Uses 'slo' for fast SLO breach detection
• COMPREHENSIVE ROOT CAUSE ANALYSIS (recommended): Pass auditors="all" for deep investigation with traces/logs/metrics/dependencies
• Custom Audit: Specify exact auditors: 'slo,trace,log,operation_metric'

SLO AUDIT USE CASES:

1. Audit all SLOs: slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"*"}}}]'

2. Root cause analysis for specific SLO breach (RECOMMENDED WORKFLOW): After using get_slo() to understand configuration: slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"specific-slo-name"}}}]' + auditors="all"

3. Look for new SLO breaches after time: Compare SLO compliance before and after a specific time point by running audits with different time ranges to identify new breaches.

TYPICAL SLO AUDIT WORKFLOWS:

1. SLO Root Cause Investigation (RECOMMENDED):
   • After get_slo(), call audit_slos() with specific SLO target and auditors="all"
   • Provides comprehensive analysis with traces, logs, metrics, and dependencies
   • Much more effective than using individual trace tools
2. Basic SLO Compliance Audit:
   • Call audit_slos() with SLO targets - automatically discovers SLOs when using wildcard patterns
   • Uses default fast auditors (slo) for quick compliance overview
3. Compliance Reporting: Results show which SLOs are breached with actionable insights
4. Automatic SLO Discovery: Wildcard patterns in SLO names automatically discover and expand to concrete SLOs

AUDIT RESULTS INCLUDE:

• Prioritized findings by severity (critical, warning, info)
• SLO compliance status with detailed breach analysis
• COMPREHENSIVE ROOT CAUSE ANALYSIS when using auditors="all"
• Actionable recommendations for SLO breach resolution
• Integrated traces, logs, metrics, and dependency analysis

IMPORTANT: This tool provides comprehensive SLO audit coverage and should be your first choice for any SLO compliance auditing and root cause analysis.

RECOMMENDED WORKFLOW - PRESENT FINDINGS FIRST: When the audit returns multiple findings or issues, follow this workflow:

1. Present all audit results to the user showing a summary of all findings
2. Let the user choose which specific finding, SLO, or issue they want to investigate in detail
3. Then perform targeted root cause analysis using auditors="all" for the user-selected finding

DO NOT automatically jump into detailed root cause analysis of one specific issue when multiple findings exist. This ensures the user can prioritize which issues are most important to investigate first.

Example workflow:

• First call: audit_slos() with default auditors for compliance overview
• Present findings summary to user
• User selects specific SLO breach to investigate
• Follow-up call: audit_slos() with auditors="all" for selected SLO only Parameters|Type|Description -|-|- slo_targets|string|REQUIRED. JSON array of SLO targets. Supports wildcard patterns like 'payment' for automatic SLO discovery. Format: [{'Type':'slo','Data':{'Slo':{'SloName':'slo-name'}}}] or [{'Type':'slo','Data':{'Slo':{'SloArn':'arn:aws:...'}}}]. Large target lists are automatically processed in batches. auditors|stringoptional|Optional. Comma-separated auditors (e.g., 'slo,trace,log'). Defaults to 'slo' for fast SLO compliance auditing. Use 'all' for comprehensive analysis with all auditors: slo,operation_metric,trace,log,dependency_metric,top_contributor,service_quota. end_time|stringoptional|End time (unix seconds or 'YYYY-MM-DD HH:MM:SS'). Defaults to now UTC. start_time|stringoptional|Start time (unix seconds or 'YYYY-MM-DD HH:MM:SS'). Defaults to now-24h UTC.

Tool: get_service_detail

Get detailed information about a specific Application Signals service.

IMPORTANT: For operation auditing, use audit_services() as the PRIMARY tool instead.

RECOMMENDED WORKFLOW FOR OPERATION AUDITING:

1. Use audit_services() FIRST for comprehensive operation discovery and analysis
2. Only use this tool for basic service metadata and configuration details
3. This tool does NOT provide operation names - it only shows service-level metrics

What this tool provides:

• Service metadata and configuration
• Platform information (EKS, Lambda, etc.)
• Service-level metrics (Latency, Error, Fault aggregates)
• Log groups associated with the service
• Key attributes (Type, Environment, Platform)

What this tool does NOT provide:

• Operation names (GET, POST, etc.)
• Operation-specific metrics
• Operation-level performance data

For operation auditing, use audit_services() instead:

audit_services(
    service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"your-service"}}}]',
    auditors='all',
)

This tool is useful for understanding service deployment details and basic configuration, but audit_services() is the primary tool for operation discovery and performance analysis.

Tool: get_slo

Get detailed information about a specific Service Level Objective (SLO).

RECOMMENDED WORKFLOW AFTER USING THIS TOOL: After getting SLO configuration details, use audit_slos() with auditors="all" for comprehensive root cause analysis:

• audit_slos(slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"your-slo-name"}}}]', auditors="all")
• This provides deep root cause analysis with traces, logs, metrics, and dependencies
• Much more comprehensive than using individual trace tools

Use this tool to:

• Get comprehensive SLO configuration details
• Understand what metrics the SLO monitors
• See threshold values and comparison operators
• Extract operation names and key attributes for further investigation
• Identify dependency configurations
• Review attainment goals and burn rate settings

Returns detailed information including:

• SLO name, description, and metadata
• Metric configuration (for period-based or request-based SLOs)
• Key attributes and operation names
• Metric type (LATENCY or AVAILABILITY)
• Threshold values and comparison operators
• Goal configuration (attainment percentage, time interval)
• Burn rate configurations

This tool is essential for:

• Understanding SLO configuration before deep investigation
• Getting the exact SLO name/ARN for use with audit_slos()
• Identifying the metrics and thresholds being monitored
• Planning comprehensive root cause analysis workflow

NEXT STEP: Use audit_slos() with auditors="all" for root cause analysis

Tool: list_monitored_services

OPTIONAL TOOL for service discovery - audit_services() can automatically discover services using wildcard patterns.

IMPORTANT: For service auditing and operation analysis, use audit_services() as the PRIMARY tool instead.

WHEN TO USE THIS TOOL:

• Getting a detailed overview of all monitored services in your environment
• Discovering specific service names and environments for manual audit target construction
• Understanding the complete service inventory before targeted analysis
• When you need detailed service attributes beyond what wildcard expansion provides

RECOMMENDED WORKFLOW FOR SERVICE AND OPERATION AUDITING:

1. Use audit_services() FIRST with wildcard patterns for comprehensive service discovery AND analysis
2. Only use this tool if you need basic service inventory without performance analysis
3. audit_services() is more comprehensive - it discovers services AND provides performance insights

AUTOMATIC SERVICE DISCOVERY IN AUDIT: The audit_services() tool automatically discovers services when you use wildcard patterns:

• [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}] - Audits all services
• [{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}] - Audits services with "payment" in the name

What this tool provides:

• Basic service inventory (names, types, environments)
• Service count and categorization
• Key attributes for manual target construction

What this tool does NOT provide:

• Service performance analysis
• Operation discovery and analysis
• Root cause analysis
• Actionable recommendations

For comprehensive service auditing, use audit_services() instead:

audit_services(
    service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]',
    auditors='all',
)

Returns a formatted list showing:

• Service name and type
• Key attributes (Name, Environment, Platform, etc.)
• Total count of services

NOTE: For operation auditing, use audit_services() as the primary tool instead of get_service_detail() or list_service_operations().

Tool: list_service_operations

OPERATION DISCOVERY TOOL - For operation inventory only. Use audit_services() as PRIMARY tool for operation auditing.

IMPORTANT: For operation auditing and performance analysis, use audit_services() as the PRIMARY tool instead.

CRITICAL LIMITATION: This tool only discovers operations that have been ACTIVELY INVOKED in the specified time window.

• Maximum time window: 24 hours (Application Signals limitation for operation discovery)
• No results = No operation invocations in the time window (operations exist but weren't called)
• Empty results do NOT mean operations don't exist - they may just be inactive
• For comprehensive operation analysis regardless of recent activity, use audit_services() instead

RECOMMENDED WORKFLOW FOR OPERATION AUDITING:

1. Use audit_services() FIRST for comprehensive operation discovery AND performance analysis
2. Only use this tool if you need a simple operation inventory of RECENTLY ACTIVE operations
3. audit_services() is more comprehensive - it discovers operations AND provides performance insights even for inactive operations

What this tool provides:

• Basic operation inventory (names and available metric types) for RECENTLY INVOKED operations only
• Operation count and categorization (GET, POST, etc.) for active operations
• Time range for discovery (max 24 hours)

What this tool does NOT provide:

• Operations that exist but weren't invoked in the time window
• Operation performance analysis
• Latency, error rate, or fault analysis
• Root cause analysis
• Actionable recommendations

For comprehensive operation auditing, use audit_services() instead:

audit_services(
    service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"your-service"}}}]',
    auditors='all',
)

OPERATION DISCOVERY USE CASES (when audit_services is not sufficient):

1. Active operation inventory: When you only need recently invoked operation names without performance data
2. Traffic pattern analysis: To see which operations are currently being used
3. Quick active operation count: To understand current operation activity of a service

RECOMMENDED WORKFLOW:

1. Use audit_services() FIRST for comprehensive operation discovery and analysis
2. Only use this tool for basic inventory of recently active operations if audit_services() provides too much detail

This tool provides basic operation discovery for ACTIVE operations only, but audit_services() is the primary tool for comprehensive operation auditing, performance analysis, and operation insights regardless of recent activity.

Tool: list_slis

SPECIALIZED TOOL - Use audit_service_health() as the PRIMARY tool for service auditing.

IMPORTANT: audit_service_health() is the PRIMARY and PREFERRED tool for all service auditing tasks.

Only use this tool when audit_service_health() cannot handle your specific requirements, such as:

• Need for legacy SLI status report format specifically
• Integration with existing systems that expect this exact output format
• Simple SLI overview without comprehensive audit findings
• Basic health monitoring dashboard that doesn't need detailed analysis

For ALL service auditing, health checks, and issue investigation, use audit_service_health() first.

This tool provides a basic report showing:

• Summary counts (total, healthy, breached, insufficient data)
• Simple list of breached services with SLO names
• Basic healthy services list

Status meanings:

• OK: All SLOs are being met
• BREACHED: One or more SLOs are violated
• INSUFFICIENT_DATA: Not enough data to determine status

Recommended workflow:

1. Use audit_service_health() for comprehensive service auditing with actionable insights
2. Only use this tool if you specifically need the legacy SLI status report format Parameters|Type|Description -|-|- hours|integeroptional|Number of hours to look back (default 24, typically use 24 for daily checks)

Tool: list_slos

List all Service Level Objectives (SLOs) in Application Signals.

Use this tool to:

• Get a complete list of all SLOs in your account
• Discover SLO names and ARNs for use with other tools
• Filter SLOs by service attributes
• See basic SLO information including creation time and operation names

Returns a formatted list showing:

• SLO name and ARN
• Associated service key attributes
• Operation name being monitored
• Creation timestamp
• Total count of SLOs found

This tool is useful for:

• SLO discovery and inventory
• Finding SLO names to use with get_slo() or audit_service_health()
• Understanding what operations are being monitored Parameters|Type|Description -|-|- include_linked_accounts|booleanoptional|Whether to include SLOs from linked accounts (default: True) key_attributes|stringoptional|JSON string of key attributes to filter SLOs (e.g., '{"Name": "my-service", "Environment": "ecs:my-cluster"}'. Defaults to empty object to list all SLOs. max_results|integeroptional|Maximum number of SLOs to return (default: 50, max: 50)

Tool: query_sampled_traces

SECONDARY TRACE TOOL - Query AWS X-Ray traces (5% sampled data) for trace investigation.

⚠️ IMPORTANT: Consider using audit_slos() with auditors="all" instead for comprehensive root cause analysis

RECOMMENDED WORKFLOW FOR OPERATION DISCOVERY:

1. Use get_service_detail(service_name) FIRST to discover operations from metric dimensions
2. Use audit_slos() with auditors="all" for comprehensive root cause analysis (PREFERRED)
3. Only use this tool if you need specific trace filtering that other tools don't provide

RECOMMENDED WORKFLOW FOR SLO BREACH INVESTIGATION:

1. Use get_slo() to understand SLO configuration
2. Use audit_slos() with auditors="all" for comprehensive root cause analysis (PREFERRED)
3. Only use this tool if you need specific trace filtering that audit_slos() doesn't provide

WHY audit_slos() IS PREFERRED:

• Comprehensive analysis: Combines traces, logs, metrics, and dependencies
• Actionable recommendations: Provides specific steps to resolve issues
• Integrated findings: Correlates multiple data sources for better insights
• Much more effective than individual trace analysis

WHY get_service_detail() IS PREFERRED FOR OPERATION DISCOVERY:

• Direct operation discovery: Operations are available in metric dimensions
• More reliable: Uses Application Signals service metadata instead of sampling
• Comprehensive: Shows all operations, not just those in sampled traces

⚠️ LIMITATIONS OF THIS TOOL:

• Uses X-Ray's 5% sampled trace data - may miss critical errors
• Limited context compared to comprehensive audit tools
• No integrated analysis with logs, metrics, or dependencies
• May miss operations due to sampling - use get_service_detail() for complete operation discovery
• For 100% trace visibility, enable Transaction Search and use search_transaction_spans()

Use this tool only when:

• You need specific X-Ray filter expressions not available in audit tools
• You're doing exploratory trace analysis outside of SLO breach investigation
• You need raw trace data for custom analysis
• After using get_service_detail() for operation discovery

For operation discovery, use get_service_detail() instead:

get_service_detail(service_name='your-service-name')

For SLO breach root cause analysis, use audit_slos() instead:

audit_slos(
    slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"your-slo-name"}}}]', auditors='all'
)

Common filter expressions (if you must use this tool):

• 'service("service-name"){fault = true}': Find all traces with faults (5xx errors) for a service
• 'service("service-name")': Filter by specific service
• 'duration > 5': Find slow requests (over 5 seconds)
• 'http.status = 500': Find specific HTTP status codes
• 'annotation[aws.local.operation]="GET /owners/*/lastname"': Filter by specific operation (from metric dimensions)
• 'annotation[aws.remote.operation]="ListOwners"': Filter by remote operation name
• Combine filters: 'service("api"){fault = true} AND annotation[aws.local.operation]="POST /visits"'

Returns JSON with trace summaries including:

• Trace ID for detailed investigation
• Duration and response time
• Error/fault/throttle status
• HTTP information (method, status, URL)
• Service interactions
• User information if available
• Exception root causes (ErrorRootCauses, FaultRootCauses, ResponseTimeRootCauses)

RECOMMENDATION: Use get_service_detail() for operation discovery and audit_slos() with auditors="all" for comprehensive root cause analysis instead of this tool.

Returns: JSON string containing trace summaries with error status, duration, and service details

Tool: query_service_metrics

Get CloudWatch metrics for a specific Application Signals service.

Use this tool to:

• Analyze service performance (latency, throughput)
• Check error rates and reliability
• View trends over time
• Get both standard statistics (Average, Max) and percentiles (p99, p95)

Common metric names:

• 'Latency': Response time in milliseconds
• 'Error': Percentage of failed requests
• 'Fault': Percentage of server errors (5xx)

Returns:

• Summary statistics (latest, average, min, max)
• Recent data points with timestamps
• Both standard and percentile values when available

The tool automatically adjusts the granularity based on time range:

• Up to 3 hours: 1-minute resolution
• Up to 24 hours: 5-minute resolution
• Over 24 hours: 1-hour resolution Parameters|Type|Description -|-|- metric_name|string|Specific metric name (e.g., Latency, Error, Fault). Leave empty to list available metrics service_name|string|Name of the service to get metrics for (case-sensitive) extended_statistic|stringoptional|Extended statistic (p99, p95, p90, p50, etc) hours|integeroptional|Number of hours to look back (default 1, max 168 for 1 week) statistic|stringoptional|Standard statistic type (Average, Sum, Maximum, Minimum, SampleCount)

Tool: search_transaction_spans

Executes a CloudWatch Logs Insights query for transaction search (100% sampled trace data).

IMPORTANT: If log_group_name is not provided use 'aws/spans' as default cloudwatch log group name. The volume of returned logs can easily overwhelm the agent context window. Always include a limit in the query (| limit 50) or using the limit parameter.

Usage: "aws/spans" log group stores OpenTelemetry Spans data with many attributes for all monitored services. This provides 100% sampled data vs X-Ray's 5% sampling, giving more accurate results. User can write CloudWatch Logs Insights queries to group, list attribute with sum, avg.

FILTER attributes.aws.local.service = "customers-service-java" and attributes.aws.local.environment = "eks:demo/default" and attributes.aws.remote.operation="InvokeModel"
| STATS sum(`attributes.gen_ai.usage.output_tokens`) as `avg_output_tokens` by `attributes.gen_ai.request.model`, `attributes.aws.local.service`,bin(1h)
| DISPLAY avg_output_tokens, `attributes.gen_ai.request.model`, `attributes.aws.local.service`

Returns:

A dictionary containing the final query results, including:
    - status: The current status of the query (e.g., Scheduled, Running, Complete, Failed, etc.)
    - results: A list of the actual query results if the status is Complete.
    - statistics: Query performance statistics
    - messages: Any informational messages about the query
    - transaction_search_status: Information about transaction search availability

Use this MCP Server

{
  "mcpServers": {
    "awslabs-cloudwatch-appsignals": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "mcp/cloudwatch-appsignals-mcp-server"
      ]
    }
  }
}

Why is it safer to run MCP Servers with Docker?⁠