Connect Inngest to Claude: Manage events, experiments, and webhooks

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

To connect Inngest to Claude for automating event-driven workflows, managing function runs, and debugging experiments, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude'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.

Giving a Large Language Model (LLM) read and write access to a distributed event engine like Inngest is an engineering challenge. You have to map highly nested JSON schemas to MCP tool definitions, handle dynamic event payloads, and deal with strict rate limits on historical run queries. Every time you want to expose a new endpoint, 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 Claude, 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 Inngest's APIs is painful. You are not just integrating "Inngest" - you are integrating an event-streaming platform, a step-function orchestrator, and an observability layer.

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

Schema-Less Event Payloads Inngest events are inherently dynamic. The data, user, and v fields within an event payload do not follow a strict global schema - they are defined by your application. When exposing an MCP tool to invoke a function or send an event, the LLM needs to understand exactly how to construct this nested JSON structure. If you just pass a generic object type to Claude, the model will hallucinate property names or nest fields incorrectly, causing function runs to fail validation upstream.

Complex State Transitions in Function Runs Inngest functions are stateful. They do not just return "success" or "failure". A run can be queued, started, sleeping, waiting for a signal, or cancelled. If an AI agent attempts to debug a stalled run, it must understand these state transitions. Extracting step-level outputs from a trace requires parsing a deeply nested root span array, mapping stepOp metadata, and resolving asynchronous execution branches.

Strict Rate Limits on Polling Inngest enforces strict rate limits on querying observability data. For example, the list_all_inngest_run_jobs endpoint is heavily rate-limited and cached for 5 seconds. If an AI agent gets stuck in a loop polling for a run status, it will hit a 429 Too Many Requests error.

It is critical to note how this is handled in a managed environment: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Inngest API returns 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 spec. The caller - in this case, the Claude agent loop - is responsible for reading these headers and executing appropriate retry/backoff logic.

Instead of building custom middleware to expose Inngest endpoints and parse pagination cursors, you can use Truto to auto-generate the necessary tool schemas directly from API documentation.

How to Generate an Inngest MCP Server with Truto

Truto dynamically generates MCP tools based on integration documentation and configuration. There is no pre-compiled SDK or hard-coded tool logic. When you create an MCP server, Truto packages the requested Inngest operations into a JSON-RPC 2.0 endpoint.

You can generate an MCP server for Inngest in two ways: through the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

If you are setting this up for your own internal team, the easiest path is the dashboard.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Inngest account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can optionally filter by methods (e.g., only allow read operations) or tags.
5. Click Create and copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3....

Method 2: Via the API

If you are provisioning MCP servers dynamically for your customers or automating your infrastructure, you can generate the server via a simple API call. The API securely generates a token, stores it in edge storage, and returns a ready-to-use URL.

Make a POST request to /integrated-account/:id/mcp:

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": "Inngest DevOps Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The response contains the secure URL you will provide to Claude:

{
  "id": "abc-123",
  "name": "Inngest DevOps Agent",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

How to Connect the MCP Server to Claude

Once you have your Truto MCP server URL, you must connect it to your LLM client.

Method A: Via the Claude UI

If you are using Claude Desktop or Claude for Enterprise, you can add the server directly in the interface.

1. In Claude Desktop, go to Settings -> Integrations -> Add MCP Server.
2. Paste the Truto MCP URL into the URL field.
3. Click Add.

(Note: If you are using ChatGPT instead, the process is similar: go to Settings -> Connectors -> Add, paste the URL, and save).

Claude will immediately ping the endpoint, perform a handshake, and ingest the tool descriptions for Inngest.

Method B: Via Manual Config File

For headless deployments or local AI agent frameworks, you can configure the MCP connection using the Claude Desktop config file (claude_desktop_config.json).

Because Truto exposes a remote HTTP endpoint but standard MCP clients often expect a standard input/output (stdio) transport, you use the official MCP Server SSE proxy to bridge the connection.

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

Restart Claude Desktop. The agent will now have full access to the Inngest tools you provisioned.

Hero Tools for Inngest

Truto normalizes dozens of Inngest endpoints into structured MCP tools. Here are the highest-leverage tools your AI agent can use to orchestrate and debug event-driven architectures.

List All Inngest Events

Retrieves recent events from your Inngest environment. This is essential for debugging whether an upstream system successfully fired an event and verifying the shape of the payload.

"Fetch the last 10 events from our production Inngest environment to see if the user.signup event is passing the correct team_id in the data payload."

Get Single Inngest Run by ID

Fetches the complete summary of a specific function run, including its status, timestamps, and final output. Agents use this to diagnose failed step functions.

"Check the status of Inngest run 01HQJ4X9. If it failed, show me the error output and the duration it ran before failing."

Create an Inngest Function Invoke

Manually triggers an Inngest function by its app and function ID. This allows Claude to act as an orchestration engine, deciding when to trigger background jobs based on natural language logic.

"Invoke the 'generate-monthly-report' function in the 'analytics-app' and pass {'month': 'October', 'user_id': '884'} as the input arguments."

Create an Inngest Signal

Resumes a sleeping Inngest function that is awaiting a signal via step.waitForSignal(). This is incredibly powerful for building human-in-the-loop approval workflows directly through a chat interface.

"Send an approval signal to the paused workflow run 01HXY9Z with the data payload {'approved': true, 'reviewer': 'claude'}."

List All Inngest Function Experiments

Retrieves observed experiments for an Inngest function, including variant counts and run statistics. Agents can analyze this data to monitor the health of an active rollout.

"List all active function experiments for the 'checkout-flow' app. Are there any significant differences in the total run counts between variant A and variant B?"

List All Inngest Webhooks

Lists the webhook endpoints configured in the current Inngest environment. Useful for auditing infrastructure and ensuring third-party providers are correctly routed to Inngest event streams.

"Audit the active webhooks in our Inngest environment. List their URLs and let me know if any are missing a transform definition."

For the complete schema definitions and the full inventory of available tools, view the Inngest integration page.

Workflows in Action

Giving Claude access to Inngest tools transforms it from a passive query engine into an active DevOps assistant. Here are concrete examples of multi-step workflows.

Scenario 1: Debugging a Stalled Onboarding Run

When a critical background job fails, developers waste time digging through observability dashboards. An agent can diagnose the issue instantly.

"Check the status of the user onboarding run ID 01HQJ8B. If it failed, find out which step caused the issue and check if the original event payload was missing data."

How the agent executes this:

1. Calls get_single_inngest_run_by_id with the provided ID to retrieve the status, startedAt, and overall output.
2. Sees the run is marked as Failed.
3. Calls list_all_inngest_run_traces to get the granular trace tree and identifies the exact step that threw the error (e.g., step.run("create-stripe-customer")).
4. Calls get_single_inngest_event_by_id using the event ID attached to the run to inspect the original payload, discovering that the email field was null.

The user receives a concise summary of the failure, the exact step that broke, and the missing data from the source event.

sequenceDiagram
  participant User
  participant Claude
  participant Truto as Truto MCP
  participant Inngest as Inngest API

  User->>Claude: "Check the status of run 01HQJ8B..."
  Claude->>Truto: get_single_inngest_run_by_id
  Truto->>Inngest: GET /runs/01HQJ8B
  Inngest-->>Truto: 200 OK (Status: Failed)
  Truto-->>Claude: JSON run data
  Claude->>Truto: list_all_inngest_run_traces
  Truto->>Inngest: GET /runs/01HQJ8B/traces
  Inngest-->>Truto: 200 OK (Trace tree)
  Truto-->>Claude: JSON trace data
  Claude-->>User: "The run failed at step 'create-stripe-customer' because 'email' was null in the event."

Scenario 2: Orchestrating a Human-in-the-Loop Approval

Inngest excels at long-running workflows that pause for human input. You can use Claude as the interface to review data and send the continuation signal.

"Find the pending refund workflow for user 9982. The refund amount looks correct, so please send the approval signal to resume the function."

How the agent executes this:

1. Calls list_all_inngest_runs with a filter for the specific event name or session key associated with user 9982 to find the active run ID.
2. Verifies the run status is currently sleeping/waiting for a signal.
3. Calls create_a_inngest_signal passing the run_id and the approval payload.

The workflow resumes instantly upstream without the developer needing to log into the Inngest dashboard or write a manual cURL request.

Security and Access Control

When exposing infrastructure like Inngest to an LLM, least-privilege access is critical. Truto provides several mechanisms to lock down your MCP servers at the protocol level:

• Method Filtering: You can restrict a server to specific operations via config.methods. Passing ["read"] ensures the agent can only fetch data (like listing runs or events) and strictly prevents it from invoking functions, sending signals, or modifying webhooks.
• Tag Filtering: By passing config.tags, you can scope the server to specific resource groups, ensuring the model only sees tools relevant to its specific domain.
• Secondary Authentication: By default, the MCP token in the URL handles authentication. For higher-security environments, you can set require_api_token_auth: true. This forces the client connecting to the MCP server to also pass a valid Truto API token in the Authorization header.
• Time-to-Live (TTL): You can set an expires_at timestamp when creating the server. Once the timestamp passes, the server and its KV edge storage records are automatically destroyed, making it perfect for temporary debugging sessions.

Move Faster with Managed Integrations

Building a custom integration layer for Claude to talk to Inngest requires deep knowledge of both the MCP specification and Inngest's stateful API quirks. You have to maintain schemas, handle nested cursor pagination, and figure out how to pass HTTP 429 rate limit headers back to the agent loop safely.

Truto abstracts this away entirely. By generating documented, validated, and normalized tools directly from the integration definition, you get production-ready MCP endpoints in seconds. You dictate the permissions, generate the URL, and let Claude handle the orchestration.