Trigger.dev MCP Server

The Trigger.dev MCP Server connects your AI assistant to your Trigger.dev projects. Trigger.dev is an open source platform where you write and run background jobs, workflows and AI agents in TypeScript. Such jobs are called tasks there; each single execution of a task is called a run. MCP, the Model Context Protocol, is an open standard that assistants such as Claude Code, Cursor or Codex use to call external tools. The server comes from Trigger.dev itself and ships as part of the official command-line interface (CLI). Its source code lives in the public triggerdotdev/trigger.dev repository under the Apache 2.0 licence. With more than 16,000 GitHub stars, the project is one of the better-known tools for long-running background jobs in the TypeScript world.

What is the Trigger.dev MCP Server useful for?

If you work with Trigger.dev, your day involves a lot of switching between editor, terminal and dashboard. A task fails, you open the dashboard, look for the run, read the logs and head back to the code. The MCP server pulls those steps into the assistant. You might ask why the last run of a task failed. The assistant fetches the run details including the logs, reads the relevant code and proposes a fix. It then triggers the task again as a test and waits for the result. So the real value is not a single lookup but the closed loop of finding a bug, fixing it and checking the fix without leaving the editor.

What can the server do?

According to the official tool list, the server covers several areas. It searches the Trigger.dev documentation, creates new projects and sets up Trigger.dev in an existing codebase. It shows the registered tasks along with their payload schemas, triggers tasks with options such as delay, tags, retries or machine size, and lists runs filtered by status, task or time range. Running jobs can be cancelled or replayed with changed values. On top come deployments to staging or production, the list of preview branches and starting and stopping the local dev server. Through TRQL, Trigger.dev's query language, the assistant analyses run, metric and LLM usage data, reads dashboards and creates its own. A health report returns an assessment with a recommended next step. Newer tools deal with chat agents, realtime session channels and incoming webhooks, whose deliveries the assistant can inspect and replay.

Read-only and dev-only modes

An assistant that is allowed to deploy and cancel runs can also do damage. Trigger.dev therefore offers two safety switches. With the --readonly option, the server hides every tool that writes, including deploy, trigger_task, cancel_run, replay_run and editing dashboards and webhook secrets. The assistant can then only read and analyse. With --dev-only, it stays confined to the development environment; deployments and preview branches disappear from the tool list. For a team just getting started, read-only mode is the sensible default.

Installation and sign-in

According to the documentation, the quickest route is the interactive installer npx trigger.dev@latest install-mcp. It detects installed clients and registers the server. Supported clients include Claude Code, Cursor, Windsurf, VS Code, Zed, Cline, Gemini CLI, Codex CLI and opencode. The server runs locally via npx. Documentation search and a few local tools work without signing in. Everything else requires a login through the Trigger.dev CLI, which the client asks for on first use. Several CLI profiles, for example for the cloud and your own instance, can be switched while the server is running.

Cost

The MCP server itself is free and open source. For the tools around runs and deployments you need a Trigger.dev account or a self-hosted instance. According to the pricing page, there is a free plan with no credit card and a monthly usage allowance, plus paid Hobby, Pro and Enterprise plans. Billing is usage-based, by compute time and number of runs. The official pricing page lists the current terms.

Who is the Trigger.dev MCP Server for?

It pays off for teams that already use Trigger.dev for background jobs, scheduled tasks or AI agents and want to track down failures faster. It also helps when you are just starting out, because the assistant can set up a project itself and search the documentation in a targeted way. If you only check a run now and then, the dashboard will serve you just as well.

Node.js with npx, a Trigger.dev account (the free plan is enough to get going) or a self-hosted instance, and an MCP client such as Claude Code, Cursor or Codex CLI.

With the Trigger.dev MCP Server, an AI assistant reads your tasks and runs, triggers tasks and helps with debugging. This guide takes you from installation to the first run you investigate.

Step 1: Prerequisites

You need Node.js with npx, an MCP client such as Claude Code, Cursor or Codex CLI, and a Trigger.dev account. According to the pricing page, the free plan is enough to get going. If you self-host Trigger.dev, you can use the server just as well and point it at your own API address.

Step 2: Install with the installer

Run npx trigger.dev@latest install-mcp in your project folder. The installer detects installed clients and asks where to register the server. For Claude Code alone, npx trigger.dev@latest install-mcp --client claude-code is enough. With --scope project, the configuration goes into the project's .mcp.json file and so applies to the whole team.

npx trigger.dev@latest install-mcp
npx trigger.dev@latest install-mcp --client claude-code

Step 3: Manual configuration

You can also add the server yourself. In Claude Code it goes into ~/.claude.json or .mcp.json with the command npx and the arguments trigger.dev@latest and mcp. VS Code expects the key servers instead of mcpServers. For Codex CLI, the documentation recommends a startup timeout of 30 seconds, because npx downloads the package on first start.

Step 4: Start safely in read-only mode

In the manual configuration, append --readonly to the arguments. Every tool that writes, such as deploy, trigger_task and cancel_run, is then missing, and the assistant can only read. If you want it to trigger tasks but never deploy, use --dev-only instead. That confines the server to the development environment.

Step 5: Sign in

Documentation search works right away. For everything else, the client asks you on first use to sign in through the Trigger.dev CLI. The whoami tool shows which account and profile are active. You switch between several profiles, for example the cloud and your own instance, with switch_profile.

Step 6: First real test

Ask the assistant something like: Show me the failed runs from the last 24 hours and explain the cause. It lists the runs, opens the details with logs and links them to your code. After a fix, it can start the local dev server, trigger the task again in the development environment and wait for the result. Review proposed changes like any other code change.

Sign-in through the Trigger.dev CLI (CLI profile), prompted by the client on first use. Documentation search and the local dev server tools work without signing in.

Read and create projects and organisations, trigger tasks, read, cancel and replay runs, deploy to staging/production, TRQL queries and dashboards, chat agents, session channels and webhook deliveries. Read-only with --readonly, development environment only with --dev-only.

The server runs locally and talks to the Trigger.dev API (cloud or your own instance). Run logs, payloads and query results it fetches enter the AI client context and therefore reach the model provider.

Without --readonly, the assistant can trigger tasks with real payloads, cancel runs, deploy to production and reset webhook secrets. Run logs and payloads may contain personal data or credentials.