Describe the feature.
Summary
Expose ServiceControl / ServicePulse actions through an MCP (Model Context Protocol) server, so that AI agents and agentic tooling (Claude, Copilot, custom LLM agents, etc.) can query and act on message-processing health data directly — without a human manually clicking through the ServicePulse UI or writing bespoke HTTP client code against the ServiceControl REST API.
Motivation
ServiceControl already exposes a rich HTTP API (and SignalR notifications) that ServicePulse and ServiceInsight consume to show:
- Failed messages (Error Queue) and retry/archive actions
- Endpoint heartbeats and instance health
- Custom checks and their pass/fail state
- Saga audit data and message flow
As agentic/AI-assisted operations become more common (on-call copilots, chatops bots, autonomous remediation agents), teams want to let an LLM-based agent answer questions like "are there any failing endpoints right now?" or "retry all failed messages from the Billing endpoint from the last hour" directly, using natural language, instead of building a one-off integration per team.
MCP is becoming the de-facto standard for exposing tools/actions to LLM agents in a discoverable, structured way (tool schemas + typed inputs/outputs), so agent clients (Claude Desktop/Code, Copilot, custom agents) can connect to a single MCP server and immediately understand what actions and data are available, instead of every team hand-rolling wrappers around the ServiceControl REST API.
Proposed feature
Provide an official MCP server (or an MCP adapter layer on top of the existing ServiceControl HTTP API) that exposes, at minimum:
Read/query tools
- List failed messages (with filtering by endpoint, time range, exception type)
- Get message details / stack trace for a specific failed message
- List endpoint heartbeat status (healthy / unhealthy / not seen)
- List custom check results and their current status
- Get saga audit trail for a given message/saga id
Action tools
- Retry a single failed message
- Retry a group of failed messages (by endpoint, by failure reason, or by custom query)
- Archive a failed message or group
- Acknowledge/dismiss a custom check failure (mirroring what ServicePulse's UI allows today)
Ideally each tool would map closely to an existing ServiceControl REST endpoint so the MCP layer is mostly a thin, well-typed wrapper with clear input/output schemas and descriptions, rather than new business logic.
Example use case
An on-call engineer asks an AI agent (connected to the ServiceControl MCP server): "Which endpoints have failing heartbeats or custom checks right now, and are there any related failed messages I should retry?" The agent calls the relevant read tools, summarizes the health picture, and — after explicit confirmation from the engineer — calls the retry tool for the affected messages. This turns a multi-tab ServicePulse investigation into a single conversational workflow.
Additional Context
No response
Describe the feature.
Summary
Expose ServiceControl / ServicePulse actions through an MCP (Model Context Protocol) server, so that AI agents and agentic tooling (Claude, Copilot, custom LLM agents, etc.) can query and act on message-processing health data directly — without a human manually clicking through the ServicePulse UI or writing bespoke HTTP client code against the ServiceControl REST API.
Motivation
ServiceControl already exposes a rich HTTP API (and SignalR notifications) that ServicePulse and ServiceInsight consume to show:
As agentic/AI-assisted operations become more common (on-call copilots, chatops bots, autonomous remediation agents), teams want to let an LLM-based agent answer questions like "are there any failing endpoints right now?" or "retry all failed messages from the Billing endpoint from the last hour" directly, using natural language, instead of building a one-off integration per team.
MCP is becoming the de-facto standard for exposing tools/actions to LLM agents in a discoverable, structured way (tool schemas + typed inputs/outputs), so agent clients (Claude Desktop/Code, Copilot, custom agents) can connect to a single MCP server and immediately understand what actions and data are available, instead of every team hand-rolling wrappers around the ServiceControl REST API.
Proposed feature
Provide an official MCP server (or an MCP adapter layer on top of the existing ServiceControl HTTP API) that exposes, at minimum:
Read/query tools
Action tools
Ideally each tool would map closely to an existing ServiceControl REST endpoint so the MCP layer is mostly a thin, well-typed wrapper with clear input/output schemas and descriptions, rather than new business logic.
Example use case
An on-call engineer asks an AI agent (connected to the ServiceControl MCP server): "Which endpoints have failing heartbeats or custom checks right now, and are there any related failed messages I should retry?" The agent calls the relevant read tools, summarizes the health picture, and — after explicit confirmation from the engineer — calls the retry tool for the affected messages. This turns a multi-tab ServicePulse investigation into a single conversational workflow.
Additional Context
No response