ChatGPT Introduces MCP Events: Why a Subscription Is a Credential

MCP Events: From Passive Responses to Active Push

ChatGPT is adding draft support for MCP Events — a noteworthy direction in the evolution of the Model Context Protocol. Historically, MCP servers have played a passive role: the client initiates a request, and the server returns tool call results. The introduction of Events means MCP servers can now actively push notifications to clients, shifting the interaction model from one-way polling to two-way subscriptions.

This might look like a minor technical addition, but it touches the core of the protocol's security model: when an external system is authorized to continuously push information into a user's AI assistant, how should that authorization be understood, stored, and revoked?

Model Context Protocol (MCP) is an open standard proposed by Anthropic in late 2024, designed to provide a unified protocol layer for interactions between AI assistants and external tools and data sources. Analogous to how HTTP underpins web services, MCP defines how clients (such as AI assistants like ChatGPT or Claude) discover and invoke the Tools and Resources exposed by MCP servers. In the original design, communication was primarily request-response: a user triggers the AI assistant, the assistant calls a tool as needed, and the session ends when the tool returns its result. The MCP Events draft adds server-initiated push capabilities — similar to WebSocket or Server-Sent Events in web development — so servers are no longer purely passive. They can send event notifications to clients when specific conditions are met, covering scenarios like monitoring alerts, data updates, and task completion callbacks.

Why a Subscription Is a Credential

The central argument here is that a subscription is, in essence, a credential. This framing deserves unpacking.

When a user establishes an event subscription with an MCP server through ChatGPT, they are effectively issuing that server a long-lived permission — the ability to reach into the user's session at some future point in time. This is fundamentally different from a one-off tool call. A one-off call's authorization expires once the request-response cycle completes; a subscription represents a persistently active authorization state.

From a security perspective, any continuously valid authorization should be managed as a credential. That means a subscription needs a clear holder, a defined scope, a lifecycle, and — most critically — a mechanism for revocation. Treating subscriptions as credentials rather than simple configuration entries is a prerequisite for building a trustworthy event system.

How Revocation Works

If subscriptions are credentials, then all the standard questions of credential management apply: how to create them, how to verify them, how to expire them, and how to revoke them.

Revocation is the most challenging part. When a user decides they no longer want event pushes from a particular MCP server, the system must ensure the subscription is immediately invalidated — and that the server cannot continue pushing using the old subscription identifier. This requires the client and server to maintain a consistent view of subscription state; any lag on either side could allow pushes to continue after they should have been cut off.

Reliable revocation typically requires the server to respond promptly to revocation signals and to validate subscription validity before each push — not by relying on locally cached stale state. This places concrete engineering requirements on MCP server implementations.

Credential revocation has well-established precedents in web security. OAuth 2.0's Token Revocation (RFC 7009) defines a standard interface for clients to send revocation requests to an authorization server. JWT (JSON Web Token), by contrast, is inherently difficult to revoke due to its stateless nature, typically requiring short expiry windows or server-side blocklists as compensating controls. The problem MCP Events faces is highly analogous: if a subscription token resembles a long-lived Refresh Token, revocation requires not only instructing the MCP server to delete the corresponding record, but also preventing pushes during the window between issuing the revocation signal and the server acknowledging it — a period of potential security exposure. The common industry approach is "short windows + strong validation": keep token lifetimes extremely short (e.g., a few minutes) while performing real-time validity checks against an authoritative state source before each push, striking a balance between performance and security.

What MCP Servers Must Store

To support event subscriptions and revocation, MCP servers can no longer be stateless, simple response nodes. They must persistently store key information related to each subscription.

At minimum, this includes: a unique subscription identifier, the user or session the subscription belongs to, the permission scope granted by the subscription, creation and expiry timestamps, and the current active/revoked status. Only by maintaining this complete record can a server correctly answer — before each push — "Is this subscription still valid?", "Who should receive this push?", and "Is the push content within the authorized scope?"

This effectively transforms the MCP server from a tool provider into a system that must take on credential lifecycle management responsibilities. Developers implementing MCP Events must treat subscription storage and state management as first-class design concerns, not as an afterthought.

This storage requirement pushes MCP server design complexity toward that of a traditional OAuth authorization server. Authorization servers must maintain complete lifecycle records for tokens, typically using relational databases or dedicated secret management services (such as HashiCorp Vault) to ensure data durability and access auditability. For MCP servers, subscription record storage also needs to address multi-tenant isolation (subscription data from different users must never be commingled), encrypted storage (subscription identifiers may carry sensitive information), and high availability (storage layer failures should not result in total loss of subscription state). Lightweight implementations can use Redis with persistence enabled; production-grade scenarios are better served by a transactional relational database with indexes on revocation status fields to support high-frequency queries.

Implications for Developers

MCP Events is still in draft, but the design thinking it reveals has broad reference value for the AI tooling ecosystem. As AI assistants integrate more external services and support active push delivery, the clarity of the authorization model directly determines the security and controllability of the overall system.

Thinking of subscriptions as credentials means developers need to introduce the full set of security primitives from the outset: identity binding, permission scopes, expiry, and revocation. For teams building MCP servers, planning subscription storage structures and revocation paths upfront is far safer than retrofitting them after features ship.

This also serves as a reminder that the more capable an AI application becomes, the more important its underlying authorization and credential management becomes. The convenience of active push must be built on a foundation of revocable, auditable trust.