# Better Stack MCP for AI Agents AI Agent Connect > Better Stack. Automate incident management and monitor uptime. Let your AI agent handle alerts, manage on-call shifts, and audit monitoring configs from your chat window. ## Overview - **Category:** ship-it - **Price:** Free - **Endpoint:** https://edge.vinkius.com/vk_preview_xq7kQqt3rPeZjz6W7YzsnYg5qqlmUHoAnFRvYBQj/ai-agent-connect - **Tags:** incident-management, on-call-scheduling, downtime-alerts, escalation-chains, sre-automation ## Description When a production alert hits at 3 AM, the last thing you want to do is hunt through three different browser tabs to figure out what's actually broken. You need to know the status of your endpoints, who's currently on the clock, and what the technical payload looks like before you can start the fix. This Connector puts that information directly into your chat window. It turns your AI agent into a high-level Site Reliability Engineer that can handle the first line of triage. Instead of manual clicking, you can just ask your agent to summarize the current firing incidents or check the heartbeat status of your background workers. It can pull the exact downtime data, acknowledge the alerts to stop the paging, and even tell you who's officially on call for the current shift. You'll find this in the Vinkius catalog as a way to bridge your infrastructure data with your daily workflow. It's about getting the facts you need to make decisions without the context switching that slows down your response time. You can audit your monitoring configs or check your public status pages just by talking to your agent. It takes the manual labor out of incident response so you can focus on the actual engineering. You won't have to keep a dashboard open on a second monitor just to see if your cron jobs are still running or if your latency constraints are being met. Everything you need to know about your uptime and on-call rotations is now available in a single conversation. ## Tools ### list_incidents List all explicit incidents on Better Stack. This helps you see what is currently firing or has resolved recently. ### get_incident Retrieve the native timeline payload of an explicit incident. This provides the raw data needed for deep debugging. ### list_monitors List every uptime monitor you have active on Better Stack. This gives you a bird's eye view of your entire monitoring fleet. ### get_monitor Get the full configuration and status for a specific monitor. Use this to see exact latency constraints and ping targets. ### acknowledge_incident Acknowledge an ongoing explicit incident. This action halts the paging sequence so your team knows you're on it. ### resolve_incident Force resolve a specific incident. Use this to clear the dashboard once you've confirmed the fix is live. ### list_heartbeats List all configured cron heartbeats securely. This helps you track the health of your background workers. ### get_heartbeat Get explicit details of a passive heartbeat node. Use this to check the last successful run of a specific task. ### list_status_pages List all explicit Status Pages. This lets you see what your customers see on your public dashboards. ### list_on_call List exact On-Call routing calendars. This tells you exactly who is responsible for the current shift. ## Prompt Examples **Prompt:** ``` What's going on with our production API right now? ``` **Response:** ``` I've checked your active incidents. There is currently **1 active incident**: * **ID #88291** (High Latency in US-East) * **Status:** Firing * **Started:** 8 minutes ago * **Payload:** `{"error": "Timeout exceeded", "latency": "4500ms"}` Would you like me to acknowledge this so the paging stops? ``` **Prompt:** ``` Who's supposed to be handling the backend rotation tonight? ``` **Response:** ``` According to the current on-call calendar: | Rotation | Primary | Backup | | :--- | :--- | :--- | | Core Backend | **Sarah Chen** | Marcus Wright | Sarah Chen is currently the primary contact for all backend escalations. ``` **Prompt:** ``` Can you show me the technical details for the last error we had? ``` **Response:** ``` Fetching details for Incident #88291... **Technical Payload:** ```json { "region": "us-east-1", "endpoint": "/v1/api/data", "status": 504, "message": "Gateway Timeout", "trace_id": "abc-123-xyz" } ``` The logs indicate a structural failure in the Nginx gateway. ``` ## Capabilities ### Acknowledge firing alerts Stop active paging by telling the system you're investigating the issue. ### Pull technical downtime payloads Get the raw data and logs from an incident to see what went wrong. ### Check on-call rotations Identify exactly who is on duty for a specific shift or rotation. ### List active monitors View your entire fleet of HTTP, DNS, and latency probes in one list. ### View public status pages Read the public-facing dashboards that show your infrastructure health. ## Use Cases ### Triage a 3 AM production page An SRE gets paged and asks the agent to list_incidents and list_on_call to see what's wrong and who's on duty. ### Audit cron job health A developer uses list_heartbeats to check if all background workers are reporting correctly during a migration. ### Review public status A product manager asks the agent to read the status pages to see if the current outage is visible to customers. ### Rapidly clear resolved alerts Once a bug is patched, an engineer tells the agent to use resolve_incident to clear the dashboard and stop the alerts. ## Benefits - Stop the paging noise by using acknowledge_incident to signal you're investigating an alert. - Reduce context switching by using get_incident to pull technical payloads directly into your chat. - Verify background worker health instantly with list_heartbeats and get_heartbeat without opening a browser. - Know exactly who to contact during an outage by checking on-call schedules with list_on_call. - Audit your entire infrastructure footprint quickly by listing all monitors with list_monitors. - Keep stakeholders informed by reading public dashboards via list_status_pages for a quick summary. ## How It Works The bottom line is you get an AI teammate that handles the heavy lifting of monitoring and incident triage. 1. Subscribe to this Connector in your AI client 2. Enter your Better Stack API Token 3. Ask your agent to list incidents, check on-call shifts, or audit monitors ## Frequently Asked Questions **Can the Better Stack MCP help me during a production outage?** Yes, it allows your AI agent to pull incident details, check on-call schedules, and acknowledge alerts directly from your chat interface, which helps you triage faster. **How does the Better Stack MCP handle on-call schedules?** It exposes your on-call routing calendars so you can ask your agent exactly who is on duty for any given shift or team rotation. **Can I use the Better Stack MCP to see my heartbeat status?** Yes, your agent can check the status of your cron heartbeats and background workers to ensure your passive tracking endpoints are running. **Does the Better Stack MCP support public status pages?** It can read your public-facing status dashboards, allowing you to quickly check what information is being shared with your customers. **Can my AI agent acknowledge alerts with the Better Stack MCP?** Yes, your agent can acknowledge ongoing incidents to halt the paging sequence while you work on a resolution. **Is the Better Stack MCP good for checking DNS probes?** It can retrieve the definitions and current status of all your active monitors, including DNS probes and HTTP endpoint pings. **Can my AI automatically acknowledge an incident so my phone stops ringing?** Yes! Running the `acknowledge_incident` capability pushes a verified API command halting escalation cycles (like SMS and phone calls) natively while you debug. **Is it possible to see the exact HTTP response body or headers that caused a monitor to fail?** Yes, pulling details via `get_incident` exposes the raw nested trace containing the root cause payloads and server errors Better Stack historically received when the check failed. **Can the agent create new monitors automatically?** No. The integration focuses safely on observation, alerting resolution, and tracking currently. Creation endpoints represent mutation vectors decoupled to ensure you preserve billing and account structure intentionally.