Trigger.dev MCP for AI. Manage job runs and monitor failure status instantly.
Gemini Works with every AI agent you already use
…and any MCP-compatible client
Connect to your AI in seconds.
Trigger.dev gives your AI agent direct control over your background job infrastructure. You can list task runs, check for failures in specific environments, inspect full payloads, or even trigger a new job run—all conversationally, without opening the dashboard.
What your AI can do
List projects
Retrieves the names and IDs of every project connected to Trigger.dev, helping you narrow down the context.
List runs
Lists multiple task runs based on criteria like time frame or status (e.g., 'failed' or 'completed').
Get run
Retrieves comprehensive details for a single job run, including logs and input payloads.
The agent retrieves a list of job executions, showing status (success/fail) and duration.
You retrieve the full history for one run ID, including logs, input payloads, and error stacks.
The agent queries the available deployment scopes (e.g., dev, staging) so you can target your investigation.
You initiate an asynchronous background process immediately using the tool.
The agent runs a previously successful or failed job again to verify fixes without manual setup.
Ask an AI about this
Waiting for input…
Trigger.dev MCP Server: 8 Tools for Job Control & Monitoring
Use these tools with your AI client to manage the full lifecycle of background jobs—from triggering a task to getting deep failure logs.
Make your AI actually useful.
Add this MCP to Claude, Cursor, or Windsurf and your AI stops guessing. It gets real tools to look things up, take action, and handle the stuff you keep doing by hand.
Start using Trigger.dev on VinkiusList Projects
Retrieves the names and IDs of every project connected to Trigger.dev, helping you narrow down the context.
List Runs
Lists multiple task runs based on criteria like time frame or status (e.g., 'failed'...
Get Run
Retrieves comprehensive details for a single job run, including logs and input...
Trigger Task
Manually starts an asynchronous background task right now, simulating an incoming...
Cancel Run
Stops a currently running background task immediately using its unique ID.
Replay Run
Re-executes a specific job run using its previous input payload to test fixes without writing new code.
List Schedules
Retrieves a list of scheduled tasks, showing their cron schedule definitions.
List Environments
Returns a list of all configured deployment scopes (like 'dev' or 'prod') so you can...
Security and governance baked right in.
Pick your AI client below to get set up. Just create a Vinkius account, subscribe, and you're instantly up and running. We handle the entire backend infrastructure, delivering out-of-the-box support for HTTPS Streamable, SSE, and OAuth2—zero messy routing required.
Claude AI
Open Claude Settings
Go to claude.ai, click your profile icon, then navigate to Customize → Connectors.
Add Custom Connector
Click the "+" button and select Add custom connector. Paste your Vinkius endpoint URL:
https://edge.vinkius.com/[YOUR_TOKEN_HERE]/mcp
Replace [YOUR_TOKEN_HERE] with your token
from cloud.vinkius.com. For OAuth-protected servers, expand
Advanced settings to add credentials.
Start a conversation
Open a new chat. The Trigger.dev integration is available immediately — no restart needed.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with Trigger.dev, then connect any of our 5,100+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 5,100+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by Trigger.dev. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Works with Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This connection provides 8 powerful capabilities that interface natively with Claude, ChatGPT, Cursor, and other compatible AI platforms. No middleware. No custom integration required.
Checking job status shouldn't require switching between three tabs.
Right now, if a background process fails, you have to jump into the dashboard. You filter by date. Then you click on the project name. Next, you select 'Failed Runs.' Then, for every single failure, you open it up again just to read the error message. It's clicks, tabs, and copy-pasting errors across Slack.
With this MCP Server, you skip all that UI overhead. You just ask your agent: 'Show me any failed runs in production.' The agent handles the filtering, calling tools like `list_runs` and `get_run`. You get a clean, immediate summary of what went wrong—no dashboard clicking required.
Trigger.dev MCP Server: Get full visibility into task runs.
Before this, seeing the logs meant navigating through environments and projects manually, often missing context like which specific payload caused the failure. You had to check `list_environments` before checking the run status.
Now, your agent handles that orchestration for you. It lets you ask complex questions—'What were the failed runs in staging?'—and uses multiple tools (`list_projects`, `list_environments`, `list_runs`) to provide a single, unified answer. The process is instant and conversational.
What your AI can actually do with this
You don't gotta jump through a dozen dashboards just to check why some background job blew up. Trigger.dev gives your AI agent direct access to your entire job infrastructure, letting you manage everything with plain English commands. It’s like having the full admin console right in your chat window.
What You Can Control
Your agent can first scope your investigation by calling list_projects, which returns every project name and ID connected to Trigger.dev so you know exactly what context you're working in. It runs list_environments to give you a full list of deployment scopes—things like 'staging' or 'production'—letting you pinpoint where the failure happened.
You can also use list_schedules to retrieve all scheduled tasks, showing their specific cron schedule definitions so you know when things are supposed to run.
When you need to see what jobs have actually run, your agent calls list_runs. This tool lists multiple task runs based on criteria like a time window or status (say, 'failed' or 'completed'), giving you an immediate overview of execution times and statuses. If you find a specific job ID that needs deep inspection, the agent uses get_run to retrieve comprehensive details for that run.
That dump includes the full logs, the exact input payloads used, and any error stacks generated during the process.
If a job is running wild or doing something it shouldn't, you can instantly stop it by calling cancel_run, which kills a background task immediately using its unique ID. If you find a bug fix that needs testing without writing new code, the agent runs replay_run. This re-executes a specific past job run, using its original input payload so you can verify fixes safely.
Need to test something right now? You don't need an external webhook or manual setup. The agent calls trigger_task to manually start an asynchronous background process instantly, simulating exactly what an incoming event would do.
How Your Agent Handles It
You just tell your AI client what you want done—for example, 'Show me all failed inventory sync jobs in production that ran last week.' The agent handles the sequence: it first uses list_environments to confirm 'production' is a valid scope. Then, it combines list_runs with filtering logic for status and time range.
It presents you with the list of IDs, so you can then tell it, 'Get me the full logs for run ID 123.' The agent executes get_run, pulling back every log line and payload detail without you ever touching a dashboard. If you find something that looks good but needs to be validated against current data, you just ask it to replay the job using its previous settings via replay_run.
019d7615-ce9a-72dc-80e3-3df5d406c86c 
Here's how it actually works
The bottom line is: you get instant, conversational visibility into your entire background job pipeline without touching a UI dashboard.
Subscribe to the Trigger.dev integration on Vinkius and generate your Secret API Key.
Instruct your AI agent with a specific request (e.g., 'What failed jobs ran yesterday?').
The agent uses the appropriate tool (list_runs, get_run, etc.) to pull live data directly from Trigger.dev's API and reports it in plain text.
Who is this actually for?
Backend developers who are tired of context switching between their code editor and five different monitoring dashboards. DevOps engineers who need to track job failures across multiple environments instantly. Technical leads running incident response drills, needing real-time data without slowing down.
Uses the agent to check task outputs and debug failed runs for specific features, verifying logic flow immediately.
Tracks job execution status across dev, staging, and production environments, identifying bottlenecks in the deployment pipeline.
Gets instant visibility into production job queues during an incident. They use list_runs to quickly filter failures by time or status when the system is down.
What Changes When You Connect
See immediate failover status using list_runs. You don't have to click through dozens of logs; the agent gives you a summarized list of failures, showing which tasks need attention right now.
Debug complex issues by calling get_run with a specific run ID. This tool pulls up the full payload and error stack in one go, eliminating manual log hunting across different tabs.
Test fixes safely without touching production code. Use replay_run to re-execute a failed job against its original input data, confirming the fix works before deployment.
Scope your investigation instantly with list_environments. You can ask for 'failed runs in staging' and never accidentally look at live production data again.
Control the system when it breaks. If a process is stuck, you don't wait—you call cancel_run via your agent to halt the job immediately.
See it in action
A webhook failed overnight
The system reported an issue with order processing. Instead of logging into Trigger.dev, the developer asks their agent: 'Show me all failed runs for process-webhook in production.' The agent uses list_runs and reports two failure IDs immediately, allowing the dev to use get_run on the worst one.
Verifying a database fix
After updating connection credentials, the ops engineer wants to verify the job runs correctly. They ask their agent to 'replay the inventory sync run' using the old payload. The agent calls replay_run, confirming the job completes successfully without new errors.
Checking deployment safety
A feature is moving from staging to prod. Before promotion, a tech lead asks: 'What are the last 10 runs for this project in the staging environment?' The agent calls list_environments and then list_runs, providing a clear audit trail across environments.
Simulating an event trigger
You need to test a new payment flow without actually processing money. You ask your agent: 'Trigger the payment processor task now.' The agent executes trigger_task, giving you a run ID that you can monitor live using other tools.
The honest tradeoffs
Manually sifting through logs
The developer opens the dashboard, filters by date range, then has to click into 10 different failed runs one by one just to find the error code.
Ask your agent directly: 'List all job failures in the last hour.' The agent uses list_runs and presents a clean summary of the errors. Then use get_run on the specific ID if you need full details.
Guessing the environment scope
A user forgets which environments exist, so they try to view 'prod runs' but get an error because they didn't know the correct scope name.
Always start by asking your agent: 'What are my available deployment environments?' The agent calls list_environments first, ensuring you target the correct context before listing any tasks.
Over-relying on manual API calls
The developer writes a complex script to check run status across multiple projects and environments.
Keep it conversational. Ask your agent to combine the steps: 'List all failed runs for Project X in Staging.' The agent orchestrates list_projects, list_environments, and list_runs automatically.
When It Fits, When It Doesn't
Use this server if your primary pain point is visibility into asynchronous process failures or state tracking. You need to know why a job failed, not just that it failed. The tools excel when you need to combine listing (e.g., list_runs) with deep inspection (get_run). Don't use this if your only goal is simply scheduling—if that's all you need, Trigger.dev's native scheduler works fine. However, if the scheduling needs to trigger an AI-monitored event, this server is essential because it provides the immediate run status and history needed for debugging.
Don't use this if your core workflow involves complex data transformation that happens outside of a defined job run (e.g., batch processing massive CSV files). For those cases, you need different types of data pipelines. This tool manages execution state; it doesn't manage the input/output payload itself.
Questions you might have
How do I get my Trigger.dev API key? +
Log in to your Trigger.dev dashboard at cloud.trigger.dev. Open your project, then find the API Keys section in the project settings. Copy your Secret API Key (it starts with tr_dev_ for development or tr_prod_ for production). Paste it into the configuration field below. For Personal Access Tokens (used for admin operations), go to Profile → Personal Access Tokens tab instead.
Can my AI agent tell me why a background job failed in production? +
Yes. Ask your agent to list failed runs and it returns the task name, error message, stack trace, execution duration, and retry count for each failure. You can then drill into a specific run to see the exact input payload and which step failed — cutting your debugging time from minutes to seconds.
What if I'm on-call and need to check job health at 2 AM? +
Just ask your AI agent 'Are there any failed jobs in production?' and get an instant triage report — number of failures, which tasks are affected, when they started failing, and whether retries resolved them. No need to open a browser, log in, or navigate dashboards in the middle of the night.
Does it support multiple environments like dev, staging, and production? +
Yes. Each API key is scoped to a specific environment (dev or prod), just like in Trigger.dev itself. You can configure separate integrations for each environment, or switch between them by updating the API key — giving you full control over which environment your AI agent queries.
How do I use the `trigger_task` tool to run a job manually? +
Yes, your agent can trigger tasks instantly. You just specify the task name and any input payload it requires. This lets you test workflows on demand without having to wait for cron schedules.
When I use `get_run`, what details can my AI agent see about the task? +
The agent sees comprehensive run data, including input payloads, final outputs, and full execution logs. This means you get everything needed to debug an issue without manually scraping logs.
Can I use Trigger.dev to fix bad data by replaying a job using `replay_run`? +
Yep, you can use the replay_run tool to rerun completed tasks. This is useful for fixing bugs or testing fixes on historical data without affecting your live production environment.
How do I know which projects are available using `list_projects`? +
The agent will list all accessible projects and environments for you. This gives instant visibility into your entire job infrastructure, so you don't have to guess where a task belongs.
We've already built the connector for Trigger.dev. Just plug in your AI agents and start using Vinkius.
No hosting. No infrastructure. No complex setup.
All 8 tools are live and waiting.
You're up and running in seconds.
Gemini Vinkius gives your AI agents access to the full catalog of app connectors, all fully managed, secure, and enterprise-ready. One subscription, every tool you need.
Built, hosted, and secured by Vinkius. You just connect and go.