The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	May 14, 2026 6:49pm

PR Summary

Medium Risk
Adds new internal API endpoints that accept AWS credentials and can disable/enable CloudWatch alarm actions, which is operationally sensitive despite input validation and auth checks.

Overview
Adds new CloudWatch tool operations to mute and unmute alarms by calling AWS DisableAlarmActions/EnableAlarmActions via two new internal POST routes (/api/tools/cloudwatch/mute-alarm and /api/tools/cloudwatch/unmute-alarm) with Zod contracts validating region, credentials, and up to 100 alarm names.

Updates the CloudWatch block to expose the new operations, parse comma-separated alarmNames, and returns success plus affected alarmNames; registers the new tools in the CloudWatch tool index/registry and bumps the API validation baseline route count (736 → 738).

^{Reviewed by Cursor Bugbot for commit bdb02ae. Bugbot is set up for automated code reviews on this repo. Configure here.}

Greptile Summary

Adds mute_alarm and unmute_alarm operations to the CloudWatch block, wrapping the AWS DisableAlarmActions and EnableAlarmActions APIs respectively. Both operations share a single alarmNames subBlock (rendered for either operation via an array condition), parse comma-separated user input into an array before dispatch, and follow the established CloudWatch tool pattern end-to-end.

• Two new API routes (/api/tools/cloudwatch/mute-alarm and /api/tools/cloudwatch/unmute-alarm), each with Zod-validated contracts, internal auth checks, and proper AWS client lifecycle management (client.destroy() in finally).
• Two new tool definitions (cloudwatch_mute_alarm / cloudwatch_unmute_alarm) registered in the tool registry; credentials use user-only visibility and alarm names use user-or-llm as expected.
• The Mute and Unmute Zod schemas, TypeScript param/response types, and tool files are structurally identical pairs — a shared base type or schema would reduce future drift risk.

Confidence Score: 4/5

The change is safe to merge; it adds two new isolated operations with no modifications to existing logic.

All new code follows established patterns for auth, validation, AWS client lifecycle, and tool registration. The only findings are style-level: the Mute and Unmute contracts, TypeScript types, and tool files are structurally identical, creating maintenance surface that a shared base type/schema would eliminate.

The contract files (cloudwatch-mute-alarm.ts, cloudwatch-unmute-alarm.ts) and types.ts contain duplicated definitions worth consolidating before they diverge.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant UI as CloudWatch Block UI
    participant Block as cloudwatch.ts (params fn)
    participant Tool as mute_alarm / unmute_alarm tool
    participant Route as /api/tools/cloudwatch/mute-alarm (or unmute-alarm)
    participant AWS as AWS CloudWatch

    UI->>Block: "operation=mute_alarm, alarmNames="a,b""
    Block->>Block: split(",").map(trim).filter(Boolean) → ["a","b"]
    Block->>Tool: "{ awsRegion, awsAccessKeyId, awsSecretAccessKey, alarmNames: ["a","b"] }"
    Tool->>Route: "POST { region, accessKeyId, secretAccessKey, alarmNames }"
    Route->>Route: checkInternalAuth()
    Route->>Route: parseToolRequest (Zod validation)
    Route->>AWS: DisableAlarmActionsCommand (or EnableAlarmActionsCommand)
    AWS-->>Route: 200 OK (silent success even for unknown alarms)
    Route-->>Tool: "{ success: true, output: { success: true, alarmNames } }"
    Tool-->>Block: "{ success: true, output: { success: true, alarmNames } }"

_{Reviews (1): Last reviewed commit: "feat(cloudwatch): add mute and unmute al..." | Re-trigger Greptile}