Repository navigation
feat(mcp): Add create_monitor tool for cron monitors - #1861
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Nov 3, 2026
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
dcramer
reviewed
Nov 3, 2026
![semgrep-code-getsentry[bot]](https://avatars.githubusercontent.com/in/1153895?s=60&v=4){kind=small}
This was referenced Nov 3, 2026
dcramer
added a commit
that referenced
this pull request
Nov 3, 2026
…1912) Semgrep keeps flagging zod usage (GHSA-mrhx-c7xc-m3w5 / CVE-2023-54404) on any PR that touches zod schemas, e.g. #1861. The code we ship already resolves a patched `zod@4.6.7`. The flagged copies come only from stale Cloudflare dev tooling in `mcp-cloudflare`: - `@cloudflare/vitest-plugin@1.4.6` pins `zod@4.6.5` exactly. - `miniflare@4.20251011.1` pins `zod@3.22.3` (no patched 3.x exists). It comes in through `@cloudflare/vite-plugin@1.13.15`, which `mcp-cloudflare` pinned locally below the catalog's `^1.31.0`. ## Changes - `packages/mcp-cloudflare` takes `@cloudflare/vite-plugin` from `catalog:` instead of its own `^1.13.15` pin. - The Cloudflare toolchain moves together to mutually compatible versions in the catalog: `@cloudflare/vite-plugin` 1.66.0, `@cloudflare/vitest-pool-workers`/vitest-plugin 1.4.9, `wrangler` 4.154.0, `miniflare` 5.20261023.1-beta. These are about a week old; I skipped the Nov 1 releases. `minimumReleaseAgeExclude` entries are updated to match. - Workspace override `zod: ^4.6.6` keeps every copy on a patched release. Result: the lockfile resolves a single `zod@4.6.7`. ## Verification Locally: `pnpm install --frozen-lockfile`, `pnpm run tsc`, `pnpm run lint`, `pnpm run build`, and the `mcp-cloudflare` tests (447 passed). Peer dependency warnings went down. Not tested: `wrangler dev` or a deploy on the new wrangler/miniflare. Worth a look before merging since this is the tooling that builds and deploys the hosted MCP server. Related: #1861 Co-Authored-By: David Cramer <dcramer@users.noreply.github.com> <!-- junior-request-attribution:start --> via @dcramer. <!-- junior-request-attribution:end --> <!-- junior-session-footer:start --> <!-- junior-conversation-id:slack%3AC08J1NSPU6S%3A1793724602.686199 --> -- [View Session](https://junior-prod.sentry.dev/conversations/slack%3AC08J1NSPU6S%3A1793724602.686199) [[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC08J1NSPU6S%3A1793724602.686199/?project=4510944073809921) <!-- junior-session-footer:end --> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: David Cramer <23610+dcramer@users.noreply.github.com>
Agents could create uptime and metric monitors but not cron monitors,
so they sent users to the UI. Add a catalog-only create_monitor tool
gated by the project-management skill that calls
POST /organizations/{org}/monitors/ with Sentry's ConfigValidator fields
(schedule, timezone, check-in margin, max runtime, failure/recovery
thresholds), and point find_monitors at it.
Fixes #1845
Co-Authored-By: Grok Bot <noreply@x.ai>
Originally authored by Alec Gutman (@Chipagosfinest) in #1846.
The exactly-one crontab/interval rule lived only in the handler, so the generated tool schema allowed both or neither. Replace the two optional fields with a required `schedule` discriminated union of strict crontab and interval variants, which generates a oneOf schema. Allow checkInMargin=0, which Sentry's MissedMarginField accepts and coerces to 1. Co-Authored-By: Grok Bot <noreply@x.ai> Originally authored by Alec Gutman (@Chipagosfinest) in #1846.
The legacy POST /organizations/{org}/monitors/ endpoint creates the cron
detector without created_by_id, so monitors an agent creates have no
creator. Post to the project detectors endpoint the Sentry UI uses
(type monitor_check_in_failure), which records the acting user and can
connect existing Alerts through workflowIds, as create_metric_monitor does.
The created Monitor comes back as dataSources[0].queryObj, so the output
shape is unchanged apart from the connected workflowIds.
Sentry still returns success when no monitor seat is available but
disables the monitor, so the description tells agents to report an
unrequested disabled status.
Agents already find create_monitor through tool search, and the pointer could steer them away from SDK monitor_config setup.
Add concise descriptions to the non-obvious create_monitor output schema fields and regenerate tool definitions.
Cap the untrusted workflowIds array at 50 entries so oversized input is rejected instead of parsed element by element.
sentry-junior
Bot
force-pushed
the
feat/create-cron-monitor-detectors
branch
from
November 3, 2026 22:10
597a9d4 to
1e87c0e
Compare
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1845. This supersedes #1846: it keeps @Chipagosfinest's commits for the
create_monitortool and adds a fix on top, applied from that PR's review.create_monitorlets agents create cron monitors instead of sending users to the UI. It's catalog-only, gated by theproject-managementskill, and takes the same schedule, timezone, margin, runtime and threshold inputs as in #1846.What changed from #1846:
POST /organizations/{org}/projects/{project}/detectors/withtype: monitor_check_in_failure, the same payload the cron UI sends (cronFormDataToEndpointPayload). The legacyPOST /organizations/{org}/monitors/path creates the detector throughensure_cron_detector, which never setscreated_by_id, so monitors created through MCP would have had no creator. This is the same gap feat(uptime): Create uptime monitors through the detectors endpoint #1837 fixes for uptime monitors. The detector path also matchescreate_metric_monitor, so the tool now accepts optionalworkflowIdsto connect existing Alerts.dataSources[0].queryObj, so the tool returns the same summary with no second request. The only addition is the connectedworkflowIds. The owner is sent on both the detector and the monitor, which matches what the legacy path copied over.disabledstatus to the user.I checked the request and response shapes against getsentry/sentry@e39c07b (
MonitorIncidentDetectorValidator,MonitorDataSourceValidator, and the base detectorcreate). Nothing has been run against a live org yet.via @dcramer.
--
View Session [Sentry]