---
title: "MCP Events: o servidor que acorda o seu agente"
description: "A metade do MCP que quase ninguém cita — eventos, subscriptions e webhooks assinados, com o que já está implementado e o que continua sendo rascunho."
canonical: "https://ronanrodrigo.dev/notes/mcp-events-do-pull-ao-push"
markdown: "https://ronanrodrigo.dev/notes/mcp-events-do-pull-ao-push.md"
last-updated: "2026-10-03"
---
## MCP Events: do pull ao push

Um reel de 1m46 sobre a parte do protocolo que não aparece nos tutoriais: se todo modelo só trabalha quando você chama, toda integração que depende do modelo chamando vira polling. Chamar ferramenta à toa, ficar checando o Drive de hora em hora, pedir para a IA "posta a aula que acabou de chegar" — isso é pull, e é o antipadrão. A virada é o servidor poder *emitir* eventos, o agente assinar uma vez e ser acordado quando o evento acontece. No exemplo do vídeo, uma plataforma de mentorias encadeia o fim de um trabalho imprevisível com o começo do próximo: o Meet avisa que a live terminou, o agente processa, a plataforma emite o segundo evento, o agente posta e avisa no Discord. Dois detalhes separam isso de gambiarra: webhook assinado (senão qualquer pessoa acorda o seu agente) e ID único por evento (entrega duplicada não gera post duplicado). E a pergunta que importa não é qual modelo usar: é qual sistema emite eventos e quem está ouvindo.

[Acesse a fonte original](https://www.instagram.com/reel/DeAkyDSRyIY/)

## A especificação: três modos de entrega

O draft de Peter Alexander (Anthropic, 2026-02-19) descreve a mecânica por trás do raciocínio do vídeo. Um servidor declara tipos de evento em `events/list`, cada um com nome, `inputSchema` (argumentos da assinatura), `payloadSchema` e os modos de entrega suportados — nenhum é obrigatório. **Poll** (`events/poll`) é request/response com cursor. **Push** (`events/stream`) é uma requisição longa, com eventos chegando como `notifications/events/event` e heartbeat carregando o cursor em períodos de silêncio. **Webhook** (`events/subscribe`) registra uma URL `https` mais um segredo `whsec_` fornecido pelo cliente; o servidor faz POST de cada evento assinado no padrão Standard Webhooks (`webhook-id`/`-timestamp`/`-signature` + `X-MCP-Subscription-Id`). A subscription carrega TTL sugerido pelo cliente (`ttlMs`) e concedido pelo servidor (`refreshBefore`), que deve ser menor ou igual à sugestão; `null` significa sem expiração. O SDK negocia o modo e roda o loop — o modelo só enxerga os eventos que chegam.

[Leia o design sketch da especificação](https://github.com/modelcontextprotocol/experimental-ext-triggers-events/blob/main/docs/design-sketch-proposal.md)

## O que já está implementado: MCP Events no ChatGPT

A OpenAI já expõe essa parte do rascunho em produção, e o guia de desenvolvimento documenta exatamente o contrato: exige MCP 2.0 (versão de protocolo `2026-07-28`), com `events` adicionada às capabilities na resposta de `server/discover` e três métodos no mesmo endpoint autenticado das tools — `events/list`, `events/subscribe` e `events/unsubscribe`. O passo a passo é: o servidor lista os eventos, o usuário diz o que quer monitorar e como responder, o ChatGPT assina informando callback URL e segredo de assinatura, e o servidor entrega os eventos naquele chat. Vale reter duas ausências: polling, streaming e as notificações de controle `gap` e `terminated` do draft **não** são suportados por essa integração. Fica só webhook, com verificação de callback.

[Veja o guia de MCP Events da OpenAI](https://developers.openai.com/plugins/build/mcp-events)

## A subscription é uma credencial

O ponto de segurança que o draft não nomeia, mas que a integração do ChatGPT materializa: uma assinatura de evento é uma credencial. É um registro durável, criado sob o access token de um usuário, que autoriza seu servidor a continuar empurrando dados daquele usuário para um agente muito depois de o token que a criou ter expirado. Um access token vive cerca de uma hora e é verificado a cada requisição; uma subscription com TTL de 24 horas continua entregando o dia inteiro, e `ttlMs: null` não expira e nunca é renovado. Ou seja: escolher a janela de revogação é uma decisão de produto, não um detalhe. Some-se a isso a regra explícita do guia — receber o evento não autoriza agir sobre ele, a chamada de tool passa pelos mesmos checks de qualquer tool call — e o desenho fica defensável: a assinatura é a fonte do evento, não da autorização.

[Leia a análise sobre assinatura como credencial](https://workos.com/blog/mcp-events-chatgpt-subscription-revocation)