Feature request for product/service
API Keys
Describe the request
I’m missing the ability to list, start, and follow up automation agents using the API. This would be really useful to trigger and monitor automation agents programmatically.
Closing, as I found duplicate: Automations as Code or API
Opened again, as that thread took a different turn.
We have two use-cases we need.
1. Cadence agents, plus a fourth that improves them.
Daily / weekly / monthly Automations already run on a schedule. A fourth agent is meant to look at how the system is doing (it already reads deploy logs) and then improve the others. It cannot: there is no way to read automation runs, update a prompt, or follow up a failed job except in the web/app UI. That human paste step is exactly what breaks the self-improving loop.
2. We operate everything from LLMs over MCP.
Landing page, code, the rest — an agent can create/update/delete those. Automations cannot. Not being able to create, update, delete, or follow up agents from the same MCP session breaks the workflow.
Need: list/get automations (prompt, schedule, tools), list/get runs (including tool traces), create/update/delete, trigger-now on the existing id.
The gap is that scheduled agents are not addressable from API/MCP.
We’re running delivery as a graph of Cursor Automations (~15 nodes today, more planned): idea → spec → plan → implement → review → QA → deploy.
Each node is its own automation. Jira labels fire the next webhook. That part works. What doesn’t: we can’t see the graph from outside Cursor’s UI.
1. Operator tooling
When something is in flight, an operator needs “what is running right now?” and “what just ran?”.
We’ll put that in our own CLI and MCP tools. Today the only way in is a session id from the web UI or a Run: link in Jira. That’s not operable. We need to list active runs (automation name, status, started) and list recent history, then open one from that list.
2. A monitor for the graph
We want a small internal webapp: one ticket = one walk through the graph. Current node, last outcome, waiting on a human, scheduled loops.
We can POST webhooks. We cannot build a status view from fire-and-forget POSTs. Same API as (1): list / status / history, keyed by automation, joinable to a ticket.
Blockers: list automations; list active runs; list run history (filter by automation / time / status); a stable id we can store (and, if possible, the trigger payload / issue key so we don’t scrape Jira for the join).
Nice to have: follow/stream a live run; cancel or retry; create/update automations from git. We’d use those, but listing is the thing we cannot work around.
Happy to share more of the graph if useful.
Cheers.