[Chipagosfinest]

Summary

Fixes #1845 by adding a create_monitor catalog tool, so agents can create cron monitors directly instead of sending users to the UI. The tool is gated by the project-management skill, like the other monitor write tools.

Key Changes

• Added create_monitor (tools/catalog/create-monitor.ts). It takes a required schedule, which must be either { type: 'crontab', crontab } or { type: 'interval', value, unit }, plus optional timezone, checkInMargin, maxRuntime, failureIssueThreshold, recoveryThreshold, slug, status and owner. It returns a structured summary that includes the monitor's web URL.
• Added SentryApiService.createMonitor, which calls POST /organizations/{org}/monitors/.
• Applies the active project constraint before the write, and tells agents to check find_monitors before retrying, because the create isn't idempotent (same as create_metric_monitor).
• find_monitors now points at create_monitor, and the project-management skill description mentions cron monitors. Definitions are regenerated.

API notes (checked against getsentry/sentry@e39c07b)

• Endpoint and response: OrganizationMonitorIndexEndpoint.post returns 201 with a MonitorSerializerResponse, or 400 with validator.errors.
• Body: MonitorValidator takes project, name, slug, status and owner. ConfigValidator is a plain Serializer, so config keys stay snake_case: schedule_type, schedule (a crontab string or [n, unit]), checkin_margin, max_runtime, timezone, failure_issue_threshold and recovery_threshold. The input limits use the values in constants.py.
• Scopes: the endpoint uses OrganizationAlertRulePermission. Its POST scope_map accepts any of org:read, org:write, org:admin or alerts:write. After that, check_can_create_monitor requires alerts:write, org:write or org:admin, or project-level alerts:write. So alerts:write is enough, and org write/admin isn't needed. The tool declares org:read, project:read and alerts:write, the same as create_metric_monitor.

Testing

• Ran locally on Node 22: pnpm run tsc, pnpm run lint (oxlint, oxfmt, ast-grep scan and tests, workspace deps), pnpm run check:generated and pnpm --filter @sentry/mcp-core test (1950 passed, 6 skipped).
• The full pnpm run test run on macOS has 21 failures, all in packages/cli (zip-writer, time-range, car-extract, install-script). The same 21 also fail on main at 462bc50, so they aren't related to this PR. They depend on the environment: zip-writer and time-range pass with TZ=UTC, car-extract needs Xcode actool, and the install-script musl case is Linux-specific.
• New unit tests use MSW mocks to cover the crontab and interval request bodies, schedule exclusivity in the input schema, checkInMargin: 0, owner format, input limits, forwarding of slug/status/owner, a nested 400 validation error reaching the agent, and project-constraint rejection with no POST sent.
• Not tested against a live Sentry instance.

Review

Before opening this PR, I had Claude Opus 5.5, Codex GPT-6.1 Sol and Gemini 4 Argon review the diff against the API notes above. Changes made from that review: tighter owner validation (user:ID or team:ID with a numeric ID), removal of an unused isMuted client parameter, the extra tests listed above, retry guidance, a note about the five-field crontab rule and an updated skill description. Not changed: dropping org:read, to stay consistent with the other alert-write tools, and local timezone validation, since Sentry already validates it.

I also ran an OpenRouter council (Grok 4.7, Kimi K3.1 Pro, DeepSeek V4 Pro) on the diff. All three said approve with nits and found no bugs. I applied two of their nits in a follow-up commit. First, the crontab-or-interval rule now lives in the input schema as a discriminated union with strict variants, so the generated tool schema shows it as a oneOf. Second, checkInMargin now accepts 0, which Sentry's MissedMarginField accepts and coerces to 1. Codex GPT-6.1 Sol reviewed that change and approved with one test nit, which is now covered. Left for the maintainers: including owner and isMuted in the output, and dropping org:read (kept for consistency).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Nov 3, 2026 5:59am UTC

[sentry-junior]

Thanks for checking the API so carefully. The validator, limit, and scope work is solid. One design problem needs fixing before this lands, plus a smaller follow-up:

• Create through the detectors endpoint, not the legacy monitors endpoint. createMonitor posts to POST /organizations/{org}/monitors/. On that path, MonitorValidator.create calls ensure_cron_detector (monitors/utils.py), which creates the Detector without created_by_id. That means every cron monitor an agent creates would have no creator. #1837 fixes this exact gap for create_uptime_monitor. The current cron UI posts to the detectors API instead (cronFormDataToEndpointPayload in static/app/views/detectors/components/forms/cron/fields.tsx: type: 'monitor_check_in_failure', with the monitor fields in dataSources[0], plus workflowIds). That path goes through MonitorIncidentDetectorValidator, and the base detector create sets created_by_id=acting_user_id(request.user) and connects workflows. create_metric_monitor already uses POST /organizations/{org}/projects/{project}/detectors/ with workflowIds, so following that pattern also lets agents attach existing Alerts, the same way they can for metric monitors. To keep the current Monitor output shape, re-read the monitor after the create, the same way #1837 does for uptime. Since #1839, cron reads go through the shared getMonitor in toolkit-core api-client/endpoints/monitors.ts, so rebase onto main and use that instead of adding another cron method to SentryApiService.
• Tell the agent when the monitor was created disabled. On both create paths, if quotas.backend.assign_seat doesn't accept the monitor, Sentry still returns success but disables the monitor (monitor.status = DISABLED, detector.enabled = False). The output includes status, but the description gives the agent no reason to look at it, so it will probably report a working monitor. Add one line saying that if status is disabled and the caller didn't ask for that, there was no monitor seat, and the agent should tell the user. Add a test where the mocked response comes back disabled.

Also, CI hasn't run yet: Test, Warden, Token Cost, and Eval are all waiting for maintainer approval because this PR comes from a fork.

[dcramer]

will get this over the finish line ty!

[sentry-junior]

I picked this up in #1861. It keeps both of your commits and adds the review fix on top: the monitor is now created through the detectors endpoint (type: monitor_check_in_failure), it takes optional workflowIds, and the description covers monitors that come back disabled for lack of a seat. CI runs there without needing fork approval. Thanks for the careful API work, most of it carried over unchanged.