Connect FireHydrant to ChatGPT: Manage Incidents and Health Metrics

If you need to connect FireHydrant to ChatGPT to automate incident response, page on-call engineers, or generate post-mortem reports, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and FireHydrant's REST API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses Claude, check out our guide on connecting FireHydrant to Claude or explore our broader architectural overview on connecting FireHydrant to AI Agents.

Giving a Large Language Model (LLM) read and write access to your critical incident management infrastructure is a serious engineering challenge. You have to handle complex relational data models, map massive JSON schemas to MCP tool definitions, and deal with strict rate limits during high-traffic outages. Every time an endpoint updates, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for FireHydrant, connect it natively to ChatGPT, and execute complex incident 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 FireHydrant's API is painful. You aren't just creating simple records - you are orchestrating complex, highly relational data models under the pressure of active incidents.

If you decide to build a custom MCP server for FireHydrant, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with FireHydrant:

Complex Relational Dependencies You cannot effectively manage a FireHydrant incident without understanding its web of dependencies. An incident links to Services, Environments, Functionalities, Roles, and Teams. If an LLM attempts to attach an impacted service to an incident, it cannot simply pass a string name - it must fetch the specific Service UUID, Environment UUID, and properly format the impact payload. Your MCP tools must cleanly separate these concerns while providing the LLM enough context to chain these lookups together dynamically.

Asynchronous State and Polling Several FireHydrant operations are asynchronous. For example, initiating a custom audience summary or triggering a catalog ingestion task does not return the result immediately. The API accepts the request and returns an ID. If your MCP server treats these as synchronous operations, the LLM will hallucinate the outcome. You must explicitly instruct the LLM via tool descriptions to poll the corresponding GET endpoints until the task completes.

Rate Limits and 429 Exhaustion During a major incident, API traffic spikes. FireHydrant strictly enforces rate limits across its endpoints. It is a common misconception that integration layers automatically absorb these limits. Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream FireHydrant API returns an HTTP 429, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit information into standardized IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). The caller - in this case, ChatGPT or your custom agent framework - is entirely responsible for reading these headers and implementing exponential backoff logic.

The Managed MCP Approach

Instead of forcing your engineering team to build a custom server that translates FireHydrant schemas into MCP tools, handles authentication states, and wraps execution logic, you can use a managed platform.

Truto's MCP functionality dynamically derives tools directly from the integration's resource definitions and schema documentation. When you connect a FireHydrant account, the system reads the underlying API structures and exposes them as a secure JSON-RPC 2.0 endpoint. Tools are never cached or hardcoded - they are generated at runtime, ensuring your AI agent always has an accurate, up-to-date map of your FireHydrant instance.

Step 1: Create the FireHydrant MCP Server

Before connecting to ChatGPT, you need to generate the MCP server URL. Each server is scoped to a specific integrated FireHydrant account and authenticated via a cryptographic token in the URL. You can create this server via the Truto UI or programmatically via the API.

Method A: Via the Truto UI

1. Navigate to the Integrated Accounts page in your Truto dashboard.
2. Select your connected FireHydrant account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Configure the server parameters (name, allowed methods, tags, and expiration).
6. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method B: Via the API

For platform teams provisioning AI access programmatically, you can generate the MCP server via a REST call. The API validates the configuration, generates the hashed token, stores it in a secure token store, and returns the endpoint.

// POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp
 
const response = await fetch(
  'https://api.truto.one/integrated-account/xyz-789/mcp', 
  {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${TRUTO_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      name: "FireHydrant ChatGPT On-Call Connector",
      config: {
        methods: ["read", "write"], // Allow both queries and actions
        require_api_token_auth: false
      },
      expires_at: null // Permanent server
    })
  }
);
 
const mcpServer = await response.json();
console.log(mcpServer.url); 
// Output: https://api.truto.one/mcp/a1b2c3d4...

Step 2: Connect the MCP Server to ChatGPT

Once you have the Truto MCP URL, you need to register it with your AI client. ChatGPT and other MCP-compliant agents communicate with this endpoint using standard JSON-RPC 2.0.

Method A: Via the ChatGPT UI (Custom Connectors)

If you are using ChatGPT Enterprise, Team, or Plus accounts with Developer Mode enabled, you can connect the server directly through the interface:

1. In ChatGPT, navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode.
3. Under MCP servers / Custom connectors, click Add a new server.
4. Name: "FireHydrant (Truto)"
5. Server URL: Paste the URL generated in Step 1.
6. Click Save. ChatGPT will immediately perform a handshake, call the tools/list protocol method, and discover your FireHydrant tools.

Method B: Via Server-Sent Events (SSE) Configuration

If you are running a custom LangChain agent, Cursor, or a local Claude Desktop instance, you connect using the Server-Sent Events (SSE) transport. Create a JSON configuration file specifying the server-sse command.

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

Hero Tools for Incident Management

When ChatGPT connects to the MCP server, it gains access to the fully typed proxy APIs for FireHydrant. Here are the highest-leverage tools available for orchestrating incident response.

create_a_fire_hydrant_incident

This is the core execution tool for declaring an outage. It accepts an incident name and allows you to establish the initial priority, severity, and impacted infrastructure right at the point of creation.

"ChatGPT, declare a SEV1 incident named 'Database Connection Exhaustion' in FireHydrant. Set the priority to High, and attach the Production-DB service to it. Return the incident ID to me."

update_a_fire_hydrant_incident_impact_by_id

Incident scopes evolve. This tool allows the LLM to update the impacted infrastructure (services, environments, functionalities) via a PATCH request without overwriting the existing impacts. It can also transition the current milestone and add a note to the timeline simultaneously.

"Update the impact for incident #402. Add the 'User Auth API' service to the impacted list and post a timeline note saying we suspect a bad deployment caused the cascading failure."

create_a_fire_hydrant_incident_note

Maintaining a clean timeline is critical for the post-mortem. This tool posts notes directly to the incident's timeline in FireHydrant. The visibility field allows the agent to control whether the note is internal or pushed to public status pages.

"Post an update to the timeline for incident #402. Note that the database team has rolled back the schema migration and latency is returning to normal. Keep this note private to the organization."

list_all_fire_hydrant_incidents

The primary situational awareness tool. It lists active and historical incidents, returning data on current milestones, priorities, active status, and involved services. The LLM handles pagination via cursors automatically.

"Fetch all currently active incidents in FireHydrant. Summarize their severities, current milestones, and tell me which services are currently degraded across the organization."

create_a_fire_hydrant_page

Bypass manual escalation paths by letting the AI trigger pages directly through FireHydrant Signals. This tool dispatches an alert to a specific on-call target (team or individual) based on defined escalation policies.

"Trigger an urgent page to the Core Infrastructure team regarding the active database incident. Use the summary 'URGENT: Auth API is down, DB connections maxed out'."

create_a_fire_hydrant_post_mortem_report

Once an incident resolves, the LLM can bootstrap the administrative work. This tool creates a retrospective report linked to the incident, setting the stage for the team to review timeline events and contributing factors.

"Incident #402 is now resolved. Please generate a new post-mortem retrospective report for it in FireHydrant and link it to the incident ID so the team can begin the review process."

To view the complete inventory of available endpoints and schema details, visit the FireHydrant integration page.

Workflows in Action

Giving ChatGPT access to these tools transforms it from a passive chat interface into an active Incident Commander assistant. Here is how specific personas use these tools in practice.

Scenario 1: Triaging a Signal and Declaring an Incident

An SRE gets an alert in Slack about spiking latency. Instead of context-switching into the FireHydrant UI to fill out forms, they prompt the AI.

"ChatGPT, we are seeing massive latency spikes on the payment gateway. Declare a SEV2 incident in FireHydrant called 'Payment Gateway Latency Spike'. Once created, trigger a page to the Payments team to get them online."

Execution Steps:

1. The agent calls create_a_fire_hydrant_incident, passing the name, severity (SEV2), and extracting the resulting incident_id.
2. The agent calls create_a_fire_hydrant_page, passing the target type, the Payments team ID, and a summary of the issue to wake up the on-call engineer.
3. The agent replies: "Incident #405 (Payment Gateway Latency Spike) has been created. The Payments team has been paged via FireHydrant Signals."

Scenario 2: Managing Timeline and Impact Scope

During a chaotic outage, the Incident Commander needs to broadcast updates and adjust the blast radius without slowing down their investigation.

"ChatGPT, the database latency issue is actually affecting the reporting service too. Update the incident impact to include the 'Reporting API' service, and post a timeline note saying we are investigating a bad query lock."

Execution Steps:

1. The agent searches for the active incident ID using list_all_fire_hydrant_incidents if it doesn't already have it in context.
2. The agent calls update_a_fire_hydrant_incident_impact_by_id, patching the infrastructure list to append the Reporting API service.
3. The agent calls create_a_fire_hydrant_incident_note, attaching the update message to the incident's timeline.
4. The agent replies: "The Reporting API has been added to the impacted services list, and your investigation note has been recorded on the timeline."

Security and Access Control

Exposing an incident management platform to an AI model requires strict governance. Truto MCP servers provide several layers of access control at the token level:

• Method Filtering: Restrict the server to specific operations. Setting methods: ["read"] ensures the LLM can query incidents and metrics but cannot accidentally trigger pages, update severities, or resolve outages.
• Tag Filtering: Limit the available tools to specific domains. For example, applying tags: ["incidents", "retrospectives"] exposes those resources while hiding administrative tools like user management or billing.
• Expiration (TTL): Use the expires_at property to create ephemeral servers. This is ideal for granting a contractor or temporary automated agent access to FireHydrant for exactly the duration of a shift or project.
• API Token Authentication: By setting require_api_token_auth: true, you force the client to provide a valid Truto API token in addition to the server URL, preventing unauthorized execution even if the MCP URL is leaked in a log file.

Moving Faster During Outages

Connecting FireHydrant to ChatGPT via a managed MCP server removes the friction between identifying a problem and orchestrating the response. By allowing an LLM to declare incidents, page engineers, update impact scopes, and draft retrospectives natively, your engineering team can focus entirely on mitigating the actual outage instead of wrangling administrative UI forms.

Current relatedPosts: ["what-is-mcp-and-mcp-servers-and-how-do-they-work","the-hands-on-guide-to-building-mcp-servers-for-ai-agents-2026","auto-generated-mcp-tools-for-ai-agents-a-2026-architecture-guide","managed-mcp-for-claude-full-saas-api-access-without-security-headaches"]