First-party cursor-subscriptions MCP fails live tool discovery on Cloud Agent Automation runs

Support Bug Reports
, ,
1

Product: Cursor Automations / Cloud Agents
When: 2026-09-10, ~15:15–16:10 UTC (still failing on retries in the same run)

Summary

A Cloud Agent started from a team Automation is expected to use the first-party cursor-subscriptions MCP (subscribe_github_ci, subscribe_github_pr, Slack thread subscriptions, timers). On this run the namespace appears in the catalog but never becomes usable: live tool discovery fails, the tool list is empty, and invoking a subscribe tool returns MCP server does not exist. Other MCP servers on the same run work. This is not an auth error: the run dashboard recorded 0 events (no mcp_auth_error).

Lookup

  • Cloud Agent run: https://cursor.com/agents/bc-59f16b72-1dd9-4e19-b165-17d095d36c78
  • bcId: bc-59f16b72-1dd9-4e19-b165-17d095d36c78
  • Source: automations
  • Visibility: team
  • Principal: team service account (not an interactive user)
  • Model: cursor-grok-4.6-high
  • Worker: hosted (not self-hosted)
  • Egress: unrestricted
  • Boot: prebuilt environment snapshot, reuse_then_checkout + warm_fork
  • Trigger: GitHub PR comment on an Automation (event-triggered Cloud Agent)

Expected

Automation Cloud Agents can list cursor-subscriptions tools, subscribe to GitHub CI/PR (and Slack), then resume via follow-up notifications. This is the documented babysitting mechanism for Automations.

Actual

  1. Tool catalog for namespace cursor-subscriptions (start of run and again ~1 hour later):
    • namespaceStatus: "error"
    • namespaceError: "This MCP server failed during live tool discovery. Its tools are unavailable until the connection is fixed."
    • tools: []
  2. Invoking subscribe_github_pr on that namespace:
    • Error: MCP server does not exist: cursor-subscriptions. Use GetDynamicTools to discover available servers.
  3. get-events for this run: 0 events. The discovery failure is not visible on the run dashboard.

What still works on the same run

  • Built-in Cursor Automation Tools (GitHub review, Slack, memory)
  • cursor-cloud diagnostics (run-info, environment-info, get-events, get-automation)
  • First-party cursor tools
  • Normal git/gh in the VM

Repro

  1. Enable a team Automation whose prompt uses cursor-subscriptions.
  2. Start a Cloud Agent run from that Automation (PR comment trigger is enough).
  3. List tools for namespace cursor-subscriptions.
  4. Observe namespaceStatus: "error" and empty tools.
  5. Call subscribe_github_pr anyway; observe MCP server does not exist.
2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

7

Hey @secondhandcomputer, thanks for the detailed report, and for the run ID.

This is expected today, though the error message is misleading and we are tracking that. Cloud Agent event subscriptions (the cursor-subscriptions tools such as subscribe_github_ci and subscribe_github_pr) currently only work for runs owned by a user. Your Automation is set to run as the team service account, so the subscription tools are not available to it, and the catalog reports that as a discovery error instead of saying so plainly. It is not an auth problem, which is why you saw no auth events on the run.

Two ways to work around it right now:

  1. If your workflow allows it, change the Automation so it runs as a user (the owner) instead of the team service account. Runs will then have the full cursor-subscriptions tool set. The trade-off is that those runs use that user’s identity and integrations.

  2. Keep it on the service account and rely on triggers instead of in-run subscriptions: let the run finish after it pushes, and have the Automation re-trigger on the GitHub events you care about (PR comments, reviews, check results). Each event starts a fresh run with the context of that event.

We have this on our list to make service-account runs either support subscriptions or clearly say they are unavailable!

9

Thanks @Colin, we are starting to use automations a lot in our company, but for this usecases the triggers wouldn’t work well at all, since we want to trigger only on PRs opened by renovate, but then we want to react on almost all events for that specific pr. Using triggers would mean that we would have to trigger for those events for basically all PRs meaning 99% of all invocations would be out of scope for the automation.

Subscriptions seemed like an incredibly good solution here and an incredible value add over building our own automation infra or using a different harness. So take this as a very strong +1 from us that subscriptions for automations are not easy to replace with triggers, and very important.

We might also resort to using a fake user account to still enable the capability for ourselves.

12

Hey @secondhandcomputer,

Quick update on this one. We’ve changed how Automations that run as a team service account handle subscriptions: those runs are no longer offered the cursor-subscriptions tools or the /subscribe skill, so the agent won’t try to use them and run into the misleading “failed during live tool discovery” / “MCP server does not exist” errors anymore. This is rolling out on our side and should be live soon if it isn’t already.

To be clear, this doesn’t add subscription support for service-account runs. For now, subscriptions still need the Automation to run as a user.