Connect Inngest to ChatGPT: Control Functions & Runs via MCP

If you need to connect Inngest to ChatGPT to control function executions, observe event runs, debug traces, or orchestrate durable workflows, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and Inngest's REST APIs. 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 Inngest to Claude or explore our broader architectural overview on connecting Inngest to AI Agents.

Giving a Large Language Model (LLM) read and write access to an event-driven orchestration platform like Inngest is an engineering challenge. You have to handle deeply nested trace tree schemas, map asynchronous signal payloads to MCP tool definitions, and deal with strict pagination cursors. Every time Inngest updates a beta endpoint or introduces a new experiment metric, 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 Inngest, connect it natively to ChatGPT, and execute complex workflows using natural language.

The Engineering Reality of the Inngest 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 an event-driven platform's API is painful. You aren't just integrating a standard CRM - you are integrating with durable execution functions, asynchronous event streams, and complex trace trees.

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

Deeply Nested Trace Trees and Volatile Beta Endpoints

Inngest's architecture relies on durable execution, meaning functions sleep, wake up on signals, and emit complex trace graphs. Endpoints like the run traces API return highly nested JSON structures containing root spans, step operations, inputs, outputs, and metadata. Many of the most valuable observability endpoints (like experiment aggregates and session metrics) are in Beta, meaning their shape and behavior can change. If your custom MCP server relies on static, hand-coded JSON schemas, any upstream change by Inngest will cause your tool calls to fail, leaving the LLM blind to the actual state of the trace.

Strict Cursor Management for Event Streams

When an LLM requests a list of function runs triggered by a specific event, it cannot ingest thousands of historical runs at once. Inngest uses cursor-based pagination. You have to write the logic to handle pagination cursors and explicitly instruct the LLM in your tool descriptions to pass cursor values back unchanged to fetch the next set of records. If your server decodes or modifies the cursor, the request will fail.

Rate Limits and 429 Errors

When querying aggressive event pipelines or attempting bulk cancellations, you will hit Inngest's API rate limits. Truto's proxy architecture does not automatically retry, throttle, or apply backoff on rate limit errors. When an upstream API returns an HTTP 429, Truto passes that error directly to the caller. Truto normalizes upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. Your LLM agent or client is entirely responsible for implementing exponential backoff. If your custom server attempts to absorb these errors and fails gracefully, the LLM will assume the function invocation succeeded and hallucinate the response.

The Managed MCP Approach

Instead of forcing your engineering team to build, host, and maintain a custom Node.js or Python server to handle these quirks, you can use Truto. Truto derives tool definitions dynamically from documentation records and integration schemas.

flowchart LR
    ChatGPT["ChatGPT (Client)"] -->|"JSON-RPC 2.0<br>over HTTPS"| TrutoMCP["Truto MCP Server<br>(/mcp/:token)"]
    TrutoMCP -->|"Authenticated<br>REST Calls"| InngestAPI["Inngest API"]
    
    subgraph Auth ["Dynamic Tool Generation"]
    Docs["Documentation<br>Records"]
    Resources["Integration<br>Resources"]
    Docs -.-> TrutoMCP
    Resources -.-> TrutoMCP
    end

When you create an MCP server in Truto, you get a single URL. This URL contains a cryptographic token that securely identifies the exact Inngest account to interact with. There are no client-side dependencies, no OAuth flows to manage in ChatGPT, and no schema updates to deploy when Inngest releases new endpoints.

Step 1: Generating the Inngest MCP Server

Truto allows you to generate a secure MCP server URL for any connected Inngest account. You can do this visually through the dashboard or programmatically via the API.

Method A: Via the Truto UI

1. Navigate to the integrated account page for your active Inngest connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can optionally filter by specific methods (e.g., only allow read operations) or apply tags.
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method B: Via the API

For teams building automated onboarding flows, you can generate the MCP server programmatically. Make a POST request to the /integrated-account/:id/mcp endpoint.

curl -X POST https://api.truto.one/integrated-account/{account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Inngest Ops Server",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The Truto API will validate that tools are available, provision the server, and return the secure URL:

{
  "id": "mcp_8f7e6d5c",
  "name": "Inngest Ops Server",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

Step 2: Connecting the Server to ChatGPT

Once you have the Truto MCP URL, connecting it to ChatGPT takes less than a minute. You can add it directly via the ChatGPT interface or integrate it locally using a configuration file if you are running custom desktop agents.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings.
2. Go to Apps and select Advanced settings.
3. Enable the Developer mode toggle (MCP custom connectors require this flag to be active).
4. Under the MCP servers / Custom connectors section, click to add a new server.
5. Provide a memorable name (e.g., "Inngest Control").
6. Paste the Truto MCP URL into the Server URL field and click Save.

ChatGPT will immediately perform the protocol handshake, request the tools/list endpoint, and ingest all available Inngest capabilities.

Method B: Via Manual Config File (SSE Transport)

If you are using a localized agent, a custom LangChain implementation, or Claude Desktop, you can connect to the remote Truto server using Server-Sent Events (SSE).

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

Hero Tools for Inngest

When connected, ChatGPT gains access to the fully mapped Inngest API. Rather than just generic CRUD operations, Truto exposes high-leverage tools specific to Inngest's durable execution model. Here are the core hero tools your AI agent can leverage.

list_all_inngest_app_functions

This tool retrieves all deployed functions for a specific Inngest app, including configuration, failure handlers, and trigger conditions. It is the primary discovery mechanism for the LLM to understand what functions are available to invoke.

Contextual usage: Always call this first when tasked with executing a workflow to ensure you have the correct function_id and app_id.

"List all the functions deployed to our production app. I need to find the exact ID for the nightly billing sync job."

create_a_inngest_function_invoke

Invokes an Inngest function dynamically by passing the app and function ID. This executes the function either asynchronously or synchronously depending on the configuration.

Contextual usage: Because arguments are passed as a single flat namespace, the LLM will map the request data into the body schema required by the function.

"Trigger the 'generate_monthly_invoice' function in the billing app for user ID 88392. Send the request payload asynchronously."

get_single_inngest_run_by_id

Retrieves the complete summary of a single function run, including status, duration, queued time, started time, and final output. This is vital for state checking.

Contextual usage: Use this to poll the status of a long-running function or to determine exactly why a run failed.

"Check the status of run ID 'run_01HJ...'. If it failed, show me the error output and the duration it ran before failing."

list_all_inngest_event_runs

Lists all function runs that were triggered by a specific event. This enables the agent to trace back from an event to see every downstream function that reacted to it.

Contextual usage: Requires strict adherence to cursor parsing. The LLM must pass back the exact cursor value to paginate through highly active event streams.

"Find all the function runs triggered by the 'user.signup' event over the last 2 hours. Paginate through the results if there are more than 40."

create_a_inngest_signal

Resumes an Inngest function that is currently sleeping or awaiting a signal via step.waitForSignal. It sends specific payload data directly to the waiting run.

Contextual usage: Critical for human-in-the-loop workflows. The AI agent can evaluate a condition, and then fire a signal to unblock the suspended durable function.

"The manual review for the transaction is complete and approved. Send a signal to run ID 'run_99X...' to resume the workflow with the status set to approved."

list_all_inngest_run_traces

Fetches the complete trace tree for a single function run. Returns the root span, child step operations, individual step IDs, and detailed input/output metadata for every distinct step.

Contextual usage: This is a beta endpoint with deeply nested output. The AI should use this when tasked with deep debugging of a multi-step durable function.

"Pull the full trace tree for run ID 'run_44A...'. Tell me exactly which child step took the longest, and what the input payload was for that specific step."

For the complete inventory of Inngest tools, required parameters, and schema definitions, visit the Inngest integration page.

Workflows in Action

Giving ChatGPT access to these tools fundamentally changes how you interact with your orchestration infrastructure. Instead of clicking through dashboards or writing custom API scripts, you can execute complex observability and operational workflows conversationally.

Workflow 1: Debugging a Failed Function Run

When an alert fires for a failed durable function, an IT admin needs to immediately trace the error, understand the payload, and identify the failing step.

"A user reported their account provisioning failed. Find the provisioning function in the core app, list the recent runs for the 'user.created' event, find the run that failed, and analyze its trace tree to tell me exactly which step caused the crash."

Execution Steps:

1. list_all_inngest_app_functions: The agent lists functions to grab the ID for the provisioning function.
2. list_all_inngest_event_runs: The agent queries runs triggered by user.created, filtering for status: failed.
3. list_all_inngest_run_traces: Using the failed run ID, the agent pulls the complete trace tree.

Result: ChatGPT responds with a concise summary of the failure, identifying that Step 3 (create_stripe_customer) failed due to a missing email in the input payload, bypassing the need for a developer to dig through raw JSON logs.

Workflow 2: Orchestrating an Asynchronous Approval Workflow

Durable functions often pause execution to wait for a manual approval signal. ChatGPT can act as the human-in-the-loop interface to resume these workflows.

"Look up the currently paused runs for the 'process_refund' function. I have verified the transaction for run ID 'run_77B2'. Send the approval signal to resume the refund processing."

Execution Steps:

1. list_all_inngest_app_functions: The agent verifies the refund function ID.
2. get_single_inngest_run_by_id: The agent checks run_77B2 to ensure it is currently in a waiting or sleeping state.
3. create_a_inngest_signal: The agent formats the required signal payload and dispatches it to unblock the function.

Result: The LLM successfully orchestrates the state change, providing a confirmation that the signal was accepted and the function is now resuming execution.

sequenceDiagram
    participant User as User
    participant ChatGPT as ChatGPT
    participant Truto as Truto MCP
    participant Inngest as Inngest API
    
    User->>ChatGPT: "Send approval signal to run_77B2"
    ChatGPT->>Truto: Call tool: create_a_inngest_signal<br>{"run_id": "run_77B2", "data": {"approved": true}}
    Truto->>Inngest: POST /runs/run_77B2/signals
    Inngest-->>Truto: 200 OK
    Truto-->>ChatGPT: Tool Result: Success
    ChatGPT-->>User: "Signal sent. The refund function is resuming."

Security and Access Control

Exposing an orchestration platform like Inngest to an AI model requires strict governance. If an LLM hallucinates, you do not want it arbitrarily cancelling bulk runs or modifying webhooks. Truto provides multiple layers of security at the MCP server level:

• Method Filtering: Configure the server using methods: ["read"]. This drops all create, update, and delete tools (like create_a_inngest_function_invoke), transforming the LLM into a safe, read-only observability assistant.
• Tag Filtering: Restrict tools to specific operational boundaries. By filtering on tags, you can expose only event-reading tools without exposing infrastructure controls.
• Dual-Layer Authentication: Enable require_api_token_auth. By default, anyone with the MCP URL can invoke tools. With this flag active, the client must also pass a valid Truto API token in the Authorization header.
• Automatic Expiration: Set an expires_at datetime. Truto will automatically destroy the MCP server and clean up the underlying KV storage via a scheduled durable object alarm when the time expires - perfect for temporary contractor access or limited-time debugging sessions.

Automate Inngest with Truto

Connecting Inngest to ChatGPT using a managed MCP server removes the friction of building custom APIs, managing pagination logic, and maintaining schemas. By passing raw API requests through a secure tokenized endpoint, your AI agents can observe traces, invoke durable functions, and dispatch signals seamlessly. The infrastructure is entirely managed, allowing your engineering team to focus on building workflows rather than maintaining integration boilerplate.