Query AWS Application Signals change events to correlate infrastructure and application changes with service performance issues. This tool provides access to AWS Application Signals' change detection capabilities through two complementary APIs: - **ListEntityEvents**: Comprehensive change histor...
Admin/system-level operation
Part of the CloudWatch Application Signals MCP Server MCP server. Enforce policies on this tool with Intercept, the open-source MCP proxy.
AI agents call list_change_events to retrieve information from CloudWatch Application Signals MCP Server without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.
Even though list_change_events only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.
Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.
tools:
list_change_events:
rules:
- action: allowSee the full CloudWatch Application Signals MCP Server policy for all 22 tools.
Agents calling read-class tools like list_change_events have been implicated in these attack patterns. Read the full case and prevention policy for each:
Other tools in the Read risk category across the catalogue. The same policy patterns (rate-limit, allow) apply to each.
Query AWS Application Signals change events to correlate infrastructure and application changes with service performance issues. This tool provides access to AWS Application Signals' change detection capabilities through two complementary APIs: - **ListEntityEvents**: Comprehensive change history for incident investigation and root cause analysis - **ListServiceStates**: Current service state information for status monitoring **Key Capabilities:** - **Change Correlation**: Link deployments, configuration changes, and infrastructure modifications to performance issues - **Timeline Analysis**: Build accurate timelines of events leading to incidents, alarms, or SLO breaches - **Service-Specific Filtering**: Focus on changes to specific services using Application Signals service attributes - **Multi-Change Type Tracking**: Monitor deployment events, configuration updates, infrastructure scaling, and other modifications - **Incident Investigation**: Essential for root cause analysis when services experience performance degradation **API Selection Guide:** - **comprehensive_history=True (default)**: Uses ListEntityEvents API - **Question it answers**: "What are the changes in my service?" - Comprehensive change history - **Best for**: Incident investigation, change correlation, root cause analysis, timeline reconstruction - **Returns**: Complete chronological list of all change events (deployments, configurations, scaling) within time range - **Use when**: You need to see all changes that happened and correlate them with performance issues - **comprehensive_history=False**: Uses ListServiceStates API - **Question it answers**: "Has anything changed in my service?" - Current change status - **Best for**: Service status monitoring, checking if recent changes occurred, troubleshooting current state - **Returns**: Information about the last deployment and other change states of services, providing visibility into recent changes that may have affected service performance - **Use when**: You want to quickly check if there were recent changes without needing the full history **Common Use Cases:** 1. **Alarm-Triggered Investigation**: "My checkout-service alarm is firing. What changed recently?" 2. **Canary Failure Analysis**: "My checkout-canary is failing. Show me recent changes that might be related." 3. **Log-Based Error Investigation**: "I'm seeing errors in payment-service logs. What deployments happened before these errors?" 4. **Service Change History**: "Show me all changes to user-authentication-service in the last 24 hours." 5. **SLO Breach Timeline**: "I had an SLO breach at 3 PM. What changes led up to it?" 6. **Deployment Impact Analysis**: "Did the 2 PM deployment cause the performance degradation?" **Service Key Attributes (Required for ListEntityEvents):** When using comprehensive_history=True (ListEntityEvents API), service_key_attributes is REQUIRED. Get these attributes from get_service_detail() first: - **Type**: Usually "Service" for Application Signals monitored services - **Name**: Service name (e.g., "checkout-service", "payment-api", "hello-world-python") - **Environment**: Service environment (e.g., "ecs:production-cluster", "lambda:default", "eks:my-cluster") - **AwsAccountId**: AWS account ID for cross-account filtering (optional) Example service key attributes: ```json { "Type": "Service", "Name": "hello-world-python", "Environment": "lambda:default" } ``` When using comprehensive_history=False (ListServiceStates API), service_key_attributes is optional. **Integration with Other Tools:** - **Enhances audit_services()**: Provides change context for service health issues - **Correlates with audit_slos()**: Links changes to SLO breach analysis - **Supports audit_service_operations()**: Adds timeline context for operation performance investigations - **Complements analyze_canary_failures()**: Provides deployment correlation for canary issues **Response Format:** Returns JSON with comprehensive change event data including: - **change_events**: Array of change events with timestamps, event types, and entity information - **events_by_type**: Summary of change types (DEPLOYMENT, CONFIGURATION, etc.) - **affected_services**: List of services with change counts and latest change timestamps - **api_used**: Which AWS API was used (ListEntityEvents or ListServiceStates) Args: start_time: Start time for change event query (ISO 8601 datetime string or Unix timestamp) end_time: End time for change event query (ISO 8601 datetime string or Unix timestamp) service_key_attributes: Service attributes dictionary to filter events to specific services. REQUIRED when comprehensive_history=True (ListEntityEvents). Optional when comprehensive_history=False (ListServiceStates). Use get_service_detail() to retrieve these attributes. max_results: Maximum number of events to return (1-250, default: 100) region: AWS region to query (defaults to configured region) comprehensive_history: If True, uses ListEntityEvents for complete change history. If False, uses ListServiceStates for current service states. Returns: JSON string containing change events with timeline analysis and correlation insights for incident investigation. It is categorised as a Read tool in the CloudWatch Application Signals MCP Server MCP Server, which means it retrieves data without modifying state.
Add a rule in your Intercept YAML policy under the tools section for list_change_events. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the CloudWatch Application Signals MCP Server MCP server.
list_change_events is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the list_change_events rule in your Intercept policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the Intercept policy for list_change_events. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
list_change_events is provided by the CloudWatch Application Signals MCP Server MCP server (awslabs.cloudwatch-applicationsignals-mcp-server). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic policy on every MCP tool call. Per-identity grants. Full audit log.