Get enablement guide for AWS Application Signals. Use this tool when the user wants to: - Enable observability, monitoring, or Application Signals for their AWS service - Set up automatic instrumentation for their application on AWS - Instrument their service running on EC2, ECS, Lambda, or EKS ...
Single-target operation; 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 get_enablement_guide 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 get_enablement_guide 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:
get_enablement_guide:
rules:
- action: allowSee the full CloudWatch Application Signals MCP Server policy for all 22 tools.
Agents calling read-class tools like get_enablement_guide 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.
Get enablement guide for AWS Application Signals. Use this tool when the user wants to: - Enable observability, monitoring, or Application Signals for their AWS service - Set up automatic instrumentation for their application on AWS - Instrument their service running on EC2, ECS, Lambda, or EKS This tool returns step-by-step enablement instructions that guide you through modifying your infrastructure and application code to enable Application Signals, which is the preferred way to enable automatic instrumentation for services on AWS. Before calling this tool: 1. Ensure you know where the application code is located and that you have read/write permissions 2. Ensure you know where the IaC code is located and that you have read/write permissions 3. If the user provides relative paths or descriptions (e.g., "./infrastructure", "in the root"): - Use the Bash tool to run 'pwd' to get the current working directory - Use file exploration tools to locate the directories - Convert relative paths to absolute paths before calling this tool 4. This tool REQUIRES absolute paths for both iac_directory and app_directory parameters After calling this tool, you should: 1. Review the enablement guide and create a visible, trackable checklist of required changes - Use your system's task tracking mechanism (todo lists, markdown checklists, etc.) - Each item should be granular enough to complete in one step - Mark items as complete as you finish them to track progress - This allows you to resume work if the context window fills up 2. Work through the checklist systematically, one item at a time: - Identify the specific file(s) that need modification for this step - Read only the relevant file(s) (DO NOT load all IaC and app files at once) - Apply the changes as specified in the guide 3. Keep context focused: Only load files needed for the current checklist item Important guidelines: - Use ABSOLUTE PATHS when reading and writing files - Do NOT modify actual application logic files (.py, .js, .java source code), only modify IaC code, Dockerfiles, and dependency files (requirements.txt, pyproject.toml, package.json, pom.xml, build.gradle, *.csproj, etc.) as instructed by the guide. - Read application files if needed to understand the setup, but avoid modifying them Args: service_platform: The AWS platform where the service runs. MUST be one of: 'ec2', 'ecs', 'lambda', 'eks' (lowercase, exact match). To help user determine: check their IaC for ECS services, Lambda functions, EKS deployments, or EC2 instances. service_language: The service's programming language. MUST be one of: 'python', 'nodejs', 'java', 'dotnet' (lowercase, exact match). IMPORTANT: Use 'nodejs' (not 'js', 'node', or 'javascript'), 'dotnet' (not 'csharp' or 'c#'). To help user determine: check for package.json (nodejs), requirements.txt (python), pom.xml (java), or .csproj (dotnet). iac_directory: ABSOLUTE path to the Infrastructure as Code (IaC) directory (e.g., /home/user/project/infrastructure) app_directory: ABSOLUTE path to the application code directory (e.g., /home/user/project/app) Returns: Markdown-formatted enablement guide with step-by-step instructions. 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 get_enablement_guide. 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.
get_enablement_guide 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 get_enablement_guide 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 get_enablement_guide. 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.
get_enablement_guide 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.