Trigger.dev MCP for AI. Manage background jobs and monitor runs from your chat client.
Gemini Works with every AI agent you already use
…and any MCP-compatible client
How this MCP server connects to your AI agent
Trigger.dev manages and controls complex background workflows directly through your AI agent. This MCP server lets you trigger tasks instantly, schedule recurring cron jobs, monitor job history, and manage environment variables—all without leaving your IDE or chat client.
What AI agents can do with Trigger.dev (Background Tasks & Jobs) Automation
Batch trigger tasks
Triggers many tasks simultaneously in one API call.
Cancel run
Stops a background job that is currently running.
Complete waitpoint
Signals the completion of an intermediate step in a workflow.
You send a command to trigger one or more background jobs by calling tools like trigger_task or batch_trigger_tasks.
Use get_run or list_runs to retrieve detailed status, payloads, and output logs for specific job executions.
Set up recurring tasks using cron syntax via create_schedule, which automatically manages the task lifecycle.
Control active jobs by canceling them (cancel_run), replaying failures (replay_run), or updating their metadata.
Create, read, update, and delete environment variables using tools like create_env_var to ensure tasks run with the right configuration.
Ask an AI about this
Waiting for input…
What AI agents can do with Trigger.dev (Background Tasks & Jobs) MCP Server: 19 Tools
Use these tools to programmatically trigger tasks, monitor job lifecycles, set up recurring schedules, and manage environment variables via your AI agent.
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 (Background Tasks & Jobs) on VinkiusBatch Trigger Tasks
Triggers many tasks simultaneously in one API call.
Cancel Run
Stops a background job that is currently running.
Complete Waitpoint
Signals the completion of an intermediate step in a workflow.
Create Batch
Starts a new batch job container (Phase 1).
Create Env Var
Adds or sets an environment variable for future jobs.
Create Schedule
Sets up a recurring job using cron syntax.
Create Waitpoint Token
Generates a temporary token needed to resume an interrupted process.
Delete Env Var
Removes an existing environment variable setting.
Get Batch Results
Retrieves the final output and results for a completed batch job.
Get Run
Fetches all details, status, and logs for one specific job run ID.
List Env Vars
Shows a list of every environment variable currently configured.
List Runs
Lists multiple completed or failed job runs in an environment using filters.
List Schedules
Shows all currently active and defined scheduled jobs.
Override Queue Concurrency
Changes how many jobs can run at the same time for a given queue.
Pause Resume Queue
Stops or restarts job processing on an entire queue.
Replay Run
Forces the system to run a specific, failed job attempt again.
Trigger Task
Starts a single task immediately by its unique identifier.
Update Env Var
Changes the value of an existing environment variable without deleting it.
Update Run Metadata
Adds or changes descriptive data about a completed job run.
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 (Background Tasks & Jobs), 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
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
Built on the Model Context Protocol (MCP) for 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 19 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 opening three different dashboards., Solved with Vinkius AI Gateway
Today, if your data pipeline fails, you open the main dashboard to see the failure flag. Then you click into the run details panel, copy the Run ID, and paste it into a separate log viewer just to find out *why* it failed. It’s slow, and you're always hunting across tabs.
With this MCP server, you tell your agent: 'What happened with the user profile sync?' The agent handles all that complexity—it calls `list_runs` to narrow down the time window, then uses `get_run` to pull the detailed logs. You get the answer in chat, period.
Create Schedule: Automate recurring jobs without writing cron syntax.
Writing a crontab entry is pain. It's easy to mix up the minute/hour format (`0 0 * * *` vs `* * * * 0`). You have to remember where your system expects the job to run, and if it needs specific environment variables set first.
Now you just tell your agent: 'Run the cleanup script every day at midnight.' The agent uses `create_schedule`, handles the correct cron syntax internally, and confirms the schedule. It’s simple, safe, and immediately actionable.
What your AI can actually do with this
You gotta manage complex workflows without leaving your chat client or IDE. The Trigger.dev MCP Server lets your AI agent handle all of it—from kicking off a single task to running massive data batches and setting up recurring cron jobs. You're not just calling an API; you're controlling the entire lifecycle of background processes.
Starting Jobs, Big or Small
Need to run something? You start with simple commands. Use trigger_task to fire off a single job instantly using its unique ID. If you gotta process a huge chunk of data—say, sending out thousands of reports—you use batch_trigger_tasks to send up to 1,000 tasks in one go. For more structured, multi-step processing, call create_batch first; this sets up a new batch container for you.
Once that batch finishes, you grab the final output and results using get_batch_results. You can also manage intermediate steps with workflows by calling complete_waitpoint, which signals that one part of a process is done and ready to move on.
Keeping Things Running Smoothly
Things break. Jobs fail, or they just get interrupted. We got ways to fix that. If a job stalls, you can generate a temporary token with create_waitpoint_token to resume the exact process where it stopped. You also control jobs in progress; use cancel_run to kill any running background task immediately.
If something fails and you gotta try again, call replay_run to force that specific job attempt to run through the system again. For fine-tuning a finished job's history, you update its metadata using update_run_metadata.
Checking the Scoreboard: Status and History
You need proof it worked, or at least an idea why it didn't. Use get_run to pull every detail, status code, and log for one specific job run ID. If you wanna see what happened across multiple environments—maybe checking runs from last week versus yesterday—you use list_runs. This tool lets you filter those results by date or status so you only see the junk you care about.
Need to know how many jobs are running right now? You can list all active and defined schedules using list_schedules.
Governing the System Environment
Every job needs its proper settings, or it'll crap out. This server lets you manage environment variables like a pro. Use create_env_var to set up new variables for future jobs, or use update_env_var if the value changes but the variable name stays put. Don't forget delete_env_var when you’re done with a setting.
You can see everything configured by running list_env_vars. If you need to change how many tasks run concurrently in a specific queue, use override_queue_concurrency. For bigger changes, you can completely halt or restart processing across an entire job queue using pause_resume_queue.
Advanced Automation and Scheduling
Setting stuff up to run on its own is where this thing shines. You set recurring tasks with create_schedule, which accepts full cron syntax so you don't have to mess with a crontab file manually. If the job gets too popular, slowing it down might be smart. You can change how many jobs are allowed to run at the same time for any given queue by calling override_queue_concurrency.
019e5d62-7fee-703c-b413-6943127c3ce3 
Here's how it actually works
The bottom line is this: you manage your entire asynchronous job lifecycle—from scheduling to debugging—by talking to your AI agent instead of hitting multiple web dashboards.
First, subscribe to this server on Vinkius and provide your Trigger.dev Secret Key.
Next, tell your AI agent what job needs running (e.g., 'Trigger the nightly data sync task').
The agent translates that into specific tool calls (like trigger_task or create_schedule), runs them against the server, and returns the status ID.
Who is this actually for?
This is for the DevOps SRE who gets tired of clicking through three different dashboards just to see if a data pipeline finished. It’s for the backend engineer debugging a production failure at 2 AM, and any developer who needs to trigger complex jobs without leaving their IDE.
Runs list_runs or uses cancel_run to check the status of failing pipelines across multiple environments.
Uses trigger_task or batch_trigger_tasks to test a new API feature by kicking off background jobs directly from their chat client.
Manages the lifecycle of data processing jobs, using replay_run when an ML model update causes a batch failure.
What Changes When You Connect
Fixing failed data pipelines is instant. Instead of digging through logs, you tell your agent to list_runs or use get_run to pull the exact payload and error message for a specific run ID.
Automate recurring tasks with create_schedule. You define cron syntax in natural language, so you don't have to remember if it's '0 0 * * *' or something else. The system handles the boilerplate.
Test massive data jobs instantly using batch_trigger_tasks. Kick off a thousand records processing job with one prompt instead of writing complex looping code.
Control your infrastructure state directly. Use create_env_var to set up credentials for testing, and then use delete_env_var when the test is done. It keeps your environment clean.
Respond to failures immediately. If a job fails, you can tell your agent to replay_run, forcing it to re-execute that specific run without manual intervention.
See it in action
Debugging a data sync failure
The ML Ops Engineer sees the nightly user profile sync failed. Instead of jumping into a dashboard, they ask their agent: 'What happened with the last run for sync-data?'. The agent calls list_runs, finds the ID, and uses get_run to report that the failure was due to an invalid key format in the payload. They then use replay_run after updating the necessary environment variables.
Setting up a daily cleanup job
The Backend Engineer needs old log files deleted every midnight, but doesn't want to mess with crontab. They ask their agent: 'Schedule a task to delete logs daily at midnight.' The agent uses create_schedule and returns the necessary cron key, automating the setup instantly.
Validating bulk API writes
The Product Manager needs to test writing 500 new records. They ask their agent: 'Trigger a batch task for these 500 IDs.' The agent uses batch_trigger_tasks, and the PM monitors progress using get_batch_results until all are confirmed successful.
Handling queue overload
The DevOps team notices that peak traffic is causing job failures. They tell their agent: 'Slow down the image processing queue.' The agent calls pause_resume_queue to halt jobs, giving the underlying service time to catch up.
The honest tradeoffs
Hardcoding run IDs
Writing a script that assumes job ID 'run_123' will always exist and try to call get_run directly. This breaks if the ID changes or the job failed.
Always use list_runs first to find the most recent run IDs, then pass those dynamic IDs into get_run. Use your agent to handle this lookup sequence automatically.
Forgetting environment variables
A job fails because it can't connect to Stripe. A developer assumes the variable is set and manually tries to debug the code, wasting time.
Use list_env_vars first to check if the required key exists, then use create_env_var or update_env_var before triggering the task.
Ignoring queue state
Triggering a job when the queue is already overloaded, causing cascading failures and confusing logs.
Check the queue status first. Use list_runs or check documentation to see if you need to call pause_resume_queue before triggering high-volume tasks.
When It Fits, When It Doesn't
Use this MCP Server when your primary goal is interacting with a robust, existing background job system via an AI agent. You should use it if you need granular control over the lifecycle—specifically needing to replay_run a failure or create_schedule without writing boilerplate cron code.
Don't use this if your workflow logic requires complex conditional branching (e.g., 'If Task A succeeds, and the user is premium, then run Task B'). This server provides the primitives; you still need an external orchestration layer to manage that dependency graph. If all you need is simple API calls wrapped in a single method, consider using a dedicated workflow engine's SDK instead of this tool library.
Questions you might have
How do I check if a background job finished successfully using get_run? +
You use get_run to pull all details for the specific run ID. You'll look at the 'status' field in the payload; it should read 'COMPLETED' or similar successful state.
Can I run a task multiple times if it failed? Which tool do I use? +
Yes, you can force a retry using replay_run. This sends the exact same job parameters back into the queue, ignoring the initial failure.
I need to trigger 100 tasks at once. Should I use trigger_task or batch_trigger_tasks? +
Use batch_trigger_tasks. It's designed to send multiple job IDs or payloads in one single request, which is much more efficient than calling the individual trigger_task 100 times.
How do I make sure my jobs use the correct API key? +
Before triggering anything, you should check or set your credentials using list_env_vars, and if necessary, call create_env_var to ensure the right variable is active for that job run.
How do I see what scheduled jobs are set up to run automatically using list_schedules? +
You use list_schedules to view all existing cron-based triggers. This tool shows the schedule's unique key, its next run time, and whether it is active or paused.
What if I need to adjust the resources available for my background tasks? Can I use override_queue_concurrency? +
override_queue_concurrency lets you control how many jobs run at once. If your system is overloaded, lower this number; if it's underutilized, raise it.
How can I find specific failed runs or filter a large volume of job history using list_runs? +
list_runs allows advanced filtering. You can narrow down results by date range, status (like 'failed'), or even by the task ID to pinpoint exactly what went wrong.
I need to ensure my tasks use the right configuration values; how do I manage environment variables with list_env_vars? +
Use list_env_vars to check all currently defined environment variables for your project. You then use other tools like create_env_var or update_env_var when changes are needed.
Can I trigger multiple background tasks at once? +
Yes! You can use the batch_trigger_tasks tool to trigger up to 1,000 tasks in a single batch request, which is highly efficient for high-volume workflows.
How do I check the output or error of a specific job run? +
Use the get_run tool with the specific Run ID. It will return the full status, payload, output, and any attempt details or error logs associated with that run.
Can I schedule a task to run automatically using a cron expression? +
Absolutely. Use the create_schedule tool to define a task identifier, a cron expression (e.g., '0 0 * * *'), and a deduplication key to automate recurring background jobs.
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 19 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.