Connect FireHydrant to Claude: Automate On-Call and Service Tasks

If your team uses ChatGPT, check out our guide on connecting FireHydrant to ChatGPT or explore our broader architectural overview on connecting FireHydrant to AI Agents.

Incident response is fundamentally a data-gathering problem wrapped in a communication problem. When a critical service goes down at 2:00 AM, site reliability engineers (SREs) waste precious minutes bouncing between Datadog dashboards, GitHub deployment logs, and FireHydrant runbooks. Giving a Large Language Model (LLM) read and write access to your incident management platform changes this dynamic. By connecting Claude to FireHydrant, you can deploy AI agents to automatically triage alerts, attach suspect change events to incidents, execute predefined runbooks, and draft post-mortem reports.

To achieve this, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and FireHydrant's REST APIs. You can either build, host, and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for FireHydrant, connect it natively to Claude Desktop, and execute complex on-call workflows using natural language.

The Engineering Reality of the FireHydrant API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against vendor APIs is painful. You are not just integrating a simple database - you are integrating an incident management ecosystem with strict relational rules.

If you decide to build a custom MCP server for FireHydrant, you own the entire API lifecycle. Here are the specific challenges you will face when mapping FireHydrant to an LLM:

Complex Relational State and Chronological Validation FireHydrant incidents are not flat records. They are complex graphs containing milestones, role assignments, environmental impacts, and attached alerts. When updating an incident's state, FireHydrant enforces strict chronological validation. For example, if your agent attempts to perform a bulk update on milestone times (started, detected, resolved), and the provided timestamps are out of chronological order relative to any existing milestone on the incident, the API will reject the request with a 422 Unprocessable Entity error. You have to write specific validation logic in your MCP server to ensure the LLM doesn't hallucinate invalid timelines.

Specific Attachment Classifications When investigating an incident, an agent might find a recent deployment that caused the outage. To link this deployment (a Change Event) to the incident via the FireHydrant API, you cannot simply pass an ID. The create_a_fire_hydrant_incident_change_event endpoint strictly requires the agent to classify the relationship by supplying a type parameter with specific enumerated values: cause, fix, suspect, or dismissed. If you expose a generic "attach event" tool to Claude without strict JSON schema enforcement, the model will fail to provide the required classification taxonomy.

Rate Limits and 429 Handling During a major outage, an agent might attempt to rapidly pull hundreds of log entries, transcript records, or related change events. FireHydrant enforces rate limits on these requests. It is a critical architectural fact that Truto does not absorb, retry, or apply backoff to rate limit errors. If the upstream FireHydrant API returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. What Truto does handle is normalizing the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. This means your MCP server instantly communicates the rate limit state to Claude, and the agent framework itself is responsible for executing the backoff and retry logic.

Instead of building schemas, handling pagination tokens, and managing OAuth lifecycles from scratch, you can use Truto to expose FireHydrant's endpoints as ready-to-use MCP tools.

How to Generate a FireHydrant MCP Server with Truto

Truto dynamically generates MCP tools based on the active resources and documentation definitions of your connected FireHydrant instance. Rather than hand-coding tool definitions, Truto reads the integration's documented endpoints and derives the JSON Schema for query and body parameters. A tool only appears in your MCP server if it has a corresponding documentation entry, ensuring the LLM only accesses curated, well-described endpoints.

You can generate your FireHydrant MCP server in two ways: through the Truto UI for rapid prototyping, or via the API for programmatic, multi-tenant deployment.

Method 1: Via the Truto UI

If you are setting up a workspace for your internal SRE team, the UI is the fastest path.

1. Navigate to the integrated account page for your connected FireHydrant instance in the Truto dashboard.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can optionally filter the server to only expose read tools, or restrict it to specific tags like incidents or runbooks.
5. Copy the generated MCP server URL. This URL contains a cryptographic token that securely maps to this specific FireHydrant account.

Method 2: Via the Truto API

If you are building an AI product that provides incident management features to your own customers, you must generate MCP servers programmatically. Each server is scoped to a single tenant's integrated account.

Make a POST request to the Truto API to generate the server URL:

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "FireHydrant Triage Agent",
    "config": {
      "methods": ["read", "write"],
      "require_api_token_auth": false
    },
    "expires_at": null
  }'

The API validates that the FireHydrant integration is AI-ready, hashes the secure token for edge storage, and returns a ready-to-use URL:

{
  "id": "mcp_abc123",
  "name": "FireHydrant Triage Agent",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Connecting the MCP Server to Claude

With your FireHydrant MCP URL in hand, you can immediately connect it to Claude. The process differs slightly depending on whether you are using the desktop application or configuring a custom agent framework.

Method A: Via the Claude UI (Desktop/Web)

Anthropic natively supports adding remote MCP servers directly through the Claude interface.

1. Open Claude and navigate to Settings.
2. Select Integrations (or Connectors depending on your tier) and click Add MCP Server.
3. Paste the Truto MCP URL generated in the previous step.
4. Click Add.

Claude will perform a JSON-RPC handshake with Truto, validating the connection and downloading the FireHydrant tool schemas. The integration is now active.

(Note: If your team also uses ChatGPT, you can add the same URL there by going to Settings -> Apps -> Advanced settings -> Developer mode -> Custom connectors).

Method B: Via Manual Configuration File

If you are managing Claude Desktop via a configuration file, or running an agent via a terminal wrapper, you can manually inject the server configuration. Open your claude_desktop_config.json file (typically located in ~/Library/Application Support/Claude/ on macOS or %APPDATA%\\Claude\\ on Windows) and add the Server-Sent Events (SSE) transport command:

{
  "mcpServers": {
    "firehydrant-truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Restart Claude to apply the new configuration.

Core FireHydrant MCP Tools for Claude

When Claude connects to the Truto MCP server, it receives a flat input namespace of available tools. Truto automatically handles splitting Claude's arguments into the appropriate query parameters and JSON body payloads based on the derived schemas.

Here are the critical hero tools your agent will use to automate FireHydrant operations.

create_a_fire_hydrant_incident

This is the starting point for any reactive automation. This tool allows the agent to declare an incident, define its initial severity, and assign an active status.

Contextual Note: If your agent is creating a retroactive incident (an outage that was already resolved before being logged), it must supply an array of milestones containing specific occurred_at timestamps to bypass the active status timeline.

"A PagerDuty alert just fired for the checkout service throwing 500 errors. Create a new FireHydrant incident named 'Checkout Service Degraded'. Set the priority to P2 and severity to High."

update_a_fire_hydrant_incident_impact_by_id

Once an incident is declared, you need to map out the blast radius. This tool allows the agent to add or update the impacted infrastructure (services, environments, functionalities) without overriding the entire incident object.

Contextual Note: This is a PATCH operation. The agent can continuously add impacted services as the investigation unfolds without worrying about dropping previously recorded infrastructure.

"Update incident ID 1a2b3c. Add the 'payment-gateway' service to the impacted infrastructure list and mark the environment as 'production-us-east'."

list_all_fire_hydrant_changes

The first question in any outage is "what changed?" This tool allows the agent to query the FireHydrant organization for recent change events, filtering by summary text to find deployments that match the failing service.

Contextual Note: Because changes occur constantly in large environments, instruct the agent to use the query parameter to narrow down the search to specific deployment tags or service names to avoid context window bloat.

"List all recent change events in FireHydrant. Filter for any deployments or configuration changes containing the word 'checkout' or 'payments' in the last 4 hours."

create_a_fire_hydrant_incident_change_event

Once the agent identifies a suspicious deployment, it uses this tool to explicitly link the change event to the active incident.

Contextual Note: The agent must provide a type. It cannot just link the event; it must state whether the change is a suspect, the confirmed cause, or the actual fix being rolled out.

"I found a recent deployment that matches our issue. Attach change event ID 9x8y7z to incident ID 1a2b3c and mark its type as 'suspect'. Include a note saying 'Recent PR merged to checkout repo'."

create_a_fire_hydrant_runbook_execution

This tool transitions the agent from observation to remediation. By attaching a specific runbook to the incident and executing it, the agent can trigger automated Slack channels, Zoom bridges, or external webhooks.

Contextual Note: The execute_for parameter requires a specific string format linking back to the incident (e.g., incident/1a2b3c).

"We need to spin up the war room. Execute the 'Major Outage Comms' runbook (ID 554433) for incident ID 1a2b3c to automatically generate the incident Slack channel and notify the executive team."

create_a_fire_hydrant_incident_retrospective

After the incident is mitigated, the administrative work begins. This tool generates the official post-mortem report by applying a specific retrospective template to the resolved incident.

Contextual Note: The incident must actually be in a resolved state before this is typically useful. The agent must provide the retrospective_template_id to ensure the correct compliance questions are generated.

"The checkout issue has been mitigated. Generate a new incident retrospective for incident ID 1a2b3c using the 'Standard Sev-1 Post-Mortem' template (ID 998877)."

For the complete inventory of available operations - including Slack emoji actions, Signals alert grouping, and SCIM directory syncing - view the FireHydrant integration page.

Workflows in Action

Exposing these tools to Claude enables complex, multi-step SRE operations. Here is how specific personas use this setup in the real world.

Scenario 1: The Midnight Triage Automator

An on-call engineer gets paged at 3:00 AM and needs to immediately establish the incident framework before logging into AWS.

User Prompt:

"I just got a PagerDuty alert that the user authentication service is failing. Declare a Sev-1 incident in FireHydrant for this. Tag the 'auth-service' as impacted in the 'production' environment. Once that's done, execute our standard 'Sev-1 Initial Response' runbook so the Slack channels get built."

Execution Steps:

1. Claude calls create_a_fire_hydrant_incident with the name "User Authentication Service Failing" and severity "Sev-1". It captures the returned id.
2. Claude calls update_a_fire_hydrant_incident_impact_by_id using the captured ID, adding 'auth-service' to the infrastructure list.
3. Claude searches for the runbook, then calls create_a_fire_hydrant_runbook_execution using the incident ID to trigger the comms pipeline.

Result: Before the engineer has even opened their laptop, the incident is logged, the blast radius is documented, and the cross-functional team has been paged into a dedicated Slack channel.

Scenario 2: The Root Cause Investigator

An incident commander needs to figure out why an internal tool suddenly started throwing 500 errors.

User Prompt:

"We have an active incident (ID 445566) regarding the internal admin dashboard. Check FireHydrant for any recent change events or deployments related to 'admin' or 'internal-tools'. If you find one from the last two hours, attach it to the incident as a suspect cause."

Execution Steps:

1. Claude calls list_all_fire_hydrant_changes, passing "admin" in the query parameter to filter the results.
2. Claude analyzes the returned JSON array, identifying a change event with a starts_at timestamp within the two-hour window.
3. Claude calls create_a_fire_hydrant_incident_change_event, passing the incident ID, the change event ID, and setting the type parameter strictly to suspect.

Result: The incident timeline is automatically updated with the exact deployment that likely broke the system, giving the engineering team an immediate target for rollback.

Scenario 3: The Post-Mortem Compiler

The incident is over, but the SOC 2 compliance paperwork still needs to be filed.

User Prompt:

"Incident 445566 is fully resolved. Generate the post-mortem using our standard template. Then, add a note to the incident timeline stating that the retrospective has been initiated and the compliance team will review it on Monday."

Execution Steps:

1. Claude calls create_a_fire_hydrant_incident_retrospective using the required incident and template IDs.
2. Claude calls create_a_fire_hydrant_incident_note with the incident ID, passing the visibility settings and the required text string.

Result: The bureaucratic overhead of incident management is handled automatically, ensuring compliance workflows are triggered without manual data entry.

Security and Access Control

Giving an AI agent write access to your incident management system requires strict governance. Truto provides four distinct security levers at the MCP token level to limit the blast radius of your AI integrations:

• Method Filtering: You can configure the MCP server to restrict access by operation type. Setting config.methods to ["read"] ensures the agent can query incidents and change events, but fundamentally cannot trigger runbooks or create new incidents.
• Tag Filtering: Resources in Truto are tagged logically. By passing tags: ["incidents", "read_only"] during server generation, you enforce that the MCP server only exposes endpoints matching those exact tags, hiding sensitive administrative endpoints.
• Additional API Authentication: By default, possession of the MCP URL grants access. For enterprise environments, setting require_api_token_auth: true forces the client to pass a valid Truto API token in the Authorization header, meaning the URL alone is useless without valid secondary credentials.
• Ephemeral Servers: You can set an expires_at timestamp when generating the server. Once the timestamp is reached, the distributed storage layer automatically invalidates the token, instantly severing the LLM's connection to FireHydrant - ideal for granting temporary access during an active war room scenario.

Moving from Triage to Autonomous Remediation

Connecting FireHydrant to Claude using an MCP server does more than just save time on data entry. It transforms your incident management platform from a passive ledger of outages into an active participant in the remediation process.

By offloading the boilerplate of tool generation, API schema mapping, and rate limit normalization to Truto, your engineering team can focus on writing better agent prompts and designing more robust runbooks. The days of hunting through logs while the system burns are ending; the future of SRE is agentic orchestration.