# FireHydrant MCP > FireHydrant connects your incident management system to any AI agent, letting you handle complex outages through natural conversation. Instead of clicking through dashboards, you can ask your agent to list active incidents, declare new sev-2 alerts, check service dependencies, and update the timeline—all from your chat interface. ## Overview - **Category:** devops-cicd - **Price:** Free - **Tags:** incident-management, site-reliability, service-catalog, incident-response, on-call, post-mortem ## Description FireHydrant lets you manage major service disruptions without ever leaving your chat window. It connects directly to your existing incident management platform, giving your AI client a full view of what's broken, who needs to know, and why it happened. When an outage hits, time is critical. You can simply ask to list all currently active incidents or check the status of a specific service. Need to start a new response? Just tell your agent to create an incident, specifying severity levels, and get it logged immediately. The system keeps track of everything: who's on the team, what changes might have caused this mess, and every note added to the timeline. This kind of operational intelligence usually lives in separate dashboards, requiring you to switch between tabs just to understand dependencies or assign personnel. Using your AI client through Vinkius means all that data—service catalogs, responder teams, runbooks, even post-incident reviews—comes together conversationally. You talk to it like a teammate and get actionable operational steps back. ## Tools ### add_incident_note Adds a specific note directly to the timeline of an existing incident record. ### create_incident Initiates and logs a brand new service incident, setting its initial status and severity. ### get_incident Retrieves complete, detailed information on one specific incident by its ID. ### get_service Fetches detailed operational data for a single service from the catalog. ### get_team Pulls specific details about an assigned responder team. ### list_change_events Provides a list of infrastructure or code changes that occurred recently, useful for root cause analysis. ### list_incidents Retrieves a summary list of all current and historical incidents logged in the system. ### list_retrospectives Lists past post-incident reviews, helping you learn from previous outages. ### list_runbooks Shows a list of active runbooks available for use when responding to an incident type. ### list_services Lists every service defined in your catalog, allowing you to understand dependencies at a glance. ### list_teams Retrieves a list of all available responder teams and their current status. ### update_incident Modifies key fields or the overall status of an existing incident record. ## Prompt Examples **Prompt:** ``` List all currently active incidents in FireHydrant. ``` **Response:** ``` Checking for active incidents... I found 2 ongoing incidents: 'Database Latency Issue' (sev-2) and 'Payment Gateway Timeout' (sev-1). Would you like the details for any of these? ``` **Prompt:** ``` Declare a new sev-2 incident: 'Redis Connection Spikes'. ``` **Response:** ``` Incident declared! I've created a new sev-2 incident named 'Redis Connection Spikes'. The incident ID is 'inc_123'. Responder teams are being notified. ``` **Prompt:** ``` Add a note to incident 'inc_123': 'Investigating potential cache invalidation issue'. ``` **Response:** ``` Note added! Your update has been successfully posted to the timeline for incident 'inc_123'. Responders will see this investigation update immediately. ``` ## Capabilities ### Track active incidents Retrieve lists of current or past service outages using list_incidents. ### Declare new incidents Quickly log a new incident with create_incident, assigning severity levels and initial details. ### Check service status and dependencies Understand the impact of an outage by checking all defined services using list_services or getting specific data with get_service. ### Manage responder teams Find out which personnel are available and assigned to handle a given crisis using list_teams or get_team. ### Update incident records Add status notes or formal updates to the timeline of an existing incident with add_incident_note or update_incident. ### Review historical data and changes Gather context by listing change events, viewing runbooks, or retrieving past retrospectives using list_change_events, list_runbooks, or list_retrospectives. ## Use Cases ### The critical system is down, but I don't know what failed. An agent asks: 'What happened?' The MCP runs `list_change_events` and immediately provides a list of recent infrastructure changes that might have triggered the outage. This cuts hours off initial diagnosis. ### I need to start documenting this major incident right now. The Incident Commander asks: 'Start logging sev-1 for Payment Gateway.' The agent uses `create_incident` and automatically notifies the relevant responder teams, getting the process started in seconds. ### I need to update my team on the current status of the outage. The manager asks: 'What's the latest?' The agent runs `get_incident` and pulls all recorded notes and updates, summarizing them for a stakeholder meeting without needing to log into the platform. ### We need to find out if two services are related. The engineer asks: 'What depends on the authentication service?' The agent runs `get_service` and lists all downstream dependencies, preventing them from missing a critical link during recovery. ## Benefits - You stop hunting for data. Instead of manually checking multiple dashboards, you can use the `list_incidents` tool to get a comprehensive overview of every active outage instantly. - Team coordination becomes automatic. Need to know who's available? The MCP lets you call `list_teams` and confirm that the right people are assigned before calling for help. - Incident documentation is fast. Instead of copying status updates into separate tickets, use `add_incident_note` to post everything directly to the incident timeline. - Service impact analysis is immediate. By using `list_services`, you don't just see a service is down; you see what other systems depend on it. - Post-mortem learning gets easier. You can call `list_retrospectives` and retrieve historical deep dives, ensuring every incident leads to better procedures. ## How It Works The bottom line is you get access to complex incident management data using simple chat commands instead of jumping through multiple web forms and dashboards. 1. Subscribe to this MCP via Vinkius and plug in your FireHydrant API Key. 2. Start talking to it through any AI client; just ask it to perform an operational task, like listing all current incidents or getting service details. 3. Your agent uses the underlying tools to fetch accurate data and delivers a conversational summary of the findings. ## Frequently Asked Questions **Can FireHydrant MCP list all current outages?** Yes. You use `list_incidents` to fetch a summary of every active and historical incident in the system, giving you a quick operational overview. **How do I check what services are affected by an outage using FireHydrant MCP?** You call `list_services`. This tool gives you the full service catalog, allowing you to map out dependencies and understand the total scope of impact. **Does FireHydrant MCP help assign people during an incident?** Yes. Use `list_teams` or `get_team` to see which responder teams are available, ensuring you assign the right experts immediately when declaring an event with `create_incident`. **I need to record a finding from the investigation; can FireHydrant MCP do that?** Absolutely. Use `add_incident_note` to post your findings directly to the incident timeline, making sure every responder sees your update immediately. **Can I retrieve information about past outages with FireHydrant MCP?** Yes. You can use `list_retrospectives` to view previous post-incident reviews and lessons learned from similar system failures.