X-LightYear opened a new issue, #5014:
URL: https://github.com/apache/rocketmq-dashboard/issues/5014

   ## Problem / limitation
   
   RocketMQ Studio already stores and displays system alert events and 
notification delivery results, but the MCP tool surface cannot query either of 
them. An AI operator can list alert rules with `rmq.alert.rule.list`, yet 
cannot inspect the active/unacknowledged incidents or failed notification 
deliveries required to diagnose an operational alert.
   
   The existing AI health-check guidance explicitly asks operators to check 
unacknowledged system alerts and recent failed alert notifications, but those 
facts are only available through REST/UI paths.
   
   ## Existing capability
   
   The production backend already provides:
   
   - `SystemAlertController` / `AlertService.listAlerts(...)` with pagination 
and level, domain, instance, transition, label, time-window, and 
notification-suppression filters.
   - `SystemAlertController` / `NotificationOutboxService.listDeliveries(...)` 
with pagination and channel, status, and instance filters.
   - Existing frontend API/service wrappers and the System Alerts page consume 
these endpoints.
   - Existing alert and notification delivery models already expose the fields 
needed for read-only diagnosis.
   
   ## Proposed behavior
   
   Add two read-only MCP tools:
   
   - `rmq.alert.system.list`: page and filter persisted system alert events.
   - `rmq.alert.delivery.list`: page and filter notification delivery attempts, 
including failed-delivery diagnostics.
   
   The tools should reuse the existing services, preserve the existing 
platform-level scope, expose only persisted diagnostic fields, and use the 
existing MCP page/output and catalog conventions.
   
   No acknowledge, clear, retry, or other mutation is proposed in this scope.
   
   ## Architecture
   
   Current:
   
   `AlertService` / `NotificationOutboxService` -> REST controller -> frontend 
API/service -> System Alerts UI
   
   Missing:
   
   `AlertService` / `NotificationOutboxService` -> MCP input contract -> MCP 
handler -> tool catalog/output schema
   
   ## Compatibility
   
   This is additive. Existing REST endpoints, UI behavior, providers, 
permissions, persistence, and tool names remain unchanged. The proposed tools 
are read-only and should use the existing `alert:read` permission and 
platform-level semantics.
   
   ## Scope
   
   Expected changes are limited to MCP input/output contracts, handlers, tool 
catalog definitions, and focused handler/catalog/schema tests. No new table, 
dependency, provider protocol, or alerting semantics are required.
   
   ## Testing
   
   Deterministic tests should verify:
   
   - service delegation with exact filters and page arguments;
   - alert and delivery result projection without notification message secrets;
   - catalog schemas and handler registration;
   - empty pages and failed delivery statuses remain observable.
   
   Prepared with AI assistance. This proposal is based on the current upstream 
trunk `0228dad5b9c9460f3e18c5c3e2b56c6525856198`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to