On 13 October 2026, Cloudflare’s changelog said the Cloudflare API MCP server now sends Workers Issues to MCP clients as MCP Events. The changelog entry calls this the first event that server exposes. A client discovers the event cloudflare.alert.workers_observability_real_time_issue with events/list, then subscribes with events/subscribe, scoped to an account or to a single Worker. When Issues detects a new or recurring issue, Cloudflare says the server posts a signed event to the client’s webhook, so an agent can start from that push instead of polling.
What a Workers Issue is
Workers Issues is built-in error monitoring for Cloudflare Workers. The docs, last updated 12 October 2026, say it detects production failures and groups related failures into issues without an SDK or an application wrapper. An occurrence is recorded when a Worker throws an uncaught exception, fails an invocation, returns a 5xx response, or logs an error. Related occurrences from the same Worker become one issue.
You turn it on in Wrangler (4.134.0 or later) by setting observability.issues.enabled to true, in the dashboard, or in the cf CLI with worker.observability.issues.enabled. It processes traffic after you enable it. It does not process older failures. The same page says Issues is available to all Workers accounts in open beta, and that it is free during the beta. The limits listed there are 50 automations per account, a minimum occurrence threshold of 1, a recurrence inactivity period from 1 hour to 365 days, and 30 days of completed automation-run history. The changelog does not add a separate price for the MCP event.
What an MCP Event is
The changelog’s link for “MCP Events” is the Triggers and Events working-group repository. That README says the repository is experimental and that its contents do not represent official MCP specifications. The charter says the group exists to define how a server proactively notifies a client, including a webhook-style callback, and it lists an accepted SEP for that mechanism among the group’s targets.
The MCP schema dated 2026-07-28 does define notifications, including notifications/tools/list_changed, notifications/resources/updated, and notifications/progress, plus a subscriptions/listen path for those notifications. It does not define events/list or events/subscribe. Cloudflare’s MCP server docs say the servers support that 2026-07-28 specification. Those method names in the changelog are Cloudflare’s event interface, pointed at the experimental working group, and they are not methods in the schema opened here.
How a client subscribes
The changelog’s steps are: enable Issues on the Worker, and connect https://mcp.cloudflare.com/mcp with the Notifications Write and Workers Observability Write permissions, using a client that supports MCP Events webhooks. It does not name any client that supports those webhooks.
The MCP server docs, updated 12 October, describe the same URL as the Cloudflare API MCP server and say you can connect with OAuth on clients such as Claude, Windsurf, Cloudflare’s AI Playground, or any SDK that supports MCP. That sentence is about connecting to the server. The page does not say those clients accept MCP Events webhooks. Those names are not a list of clients for the new event. The page also does not mention Workers Issues events. It was last updated the day before the changelog.
An earlier Cloudflare observability post, Cloudflare Traces, describes a different path: an Observability MCP server that can query traces. That is a query tool in the tracing beta, not this webhook.
What to turn on
Enable Issues, grant those two token permissions, and use a client that actually implements the webhook side. Cloudflare has not published a client list for that side. Until it does, a connection to https://mcp.cloudflare.com/mcp only shows that the API server is reachable. It does not show that Workers Issues will arrive as events.
The Campfire
No commentsNobody has pulled up a log by this one yet. Be the first to say what you make of it.
Held for the desk. It appears after a look.