MCP Events: agenta v ChatGPT teď probudí událost, ne tvoje otázka

Většina AI agentů dneska jen sedí a čeká, až se jich na něco zeptáš. Od DevDay 29. září jim v ChatGPT může zazvonit plugin sám, když se v napojené aplikaci něco stane.

Tento týden obletěl X a LinkedIn virální post, podle kterého si toho skoro nikdo nevšiml. Má pravdu v tom hlavním: agent se už nemusí pořád ptát, jestli je něco nového, stačí se přihlásit k odběru. A postavit si s tím něco můžeš už teď.

Co OpenAI na DevDay oznámilo

Podle InfoQ OpenAI ohlásilo podporu navrhované specifikace MCP Events. Plugin, tedy MCP server, tak může spustit automatizaci ve chvíli, kdy se v napojené aplikaci něco stane.

Samotný návrh ale OpenAI nevymyslelo. Píše ho pracovní skupina kolem protokolu MCP a OpenAI ho teď zapojilo do ChatGPT.

Příklad, který OpenAI ukázalo: ChatGPT hlídá projektovou nástěnku. Když na ní přibude úkol, přečte navázané dokumenty a připraví plán. Ty mezitím nemusíš sedět u počítače.

Podle blogu WorkOS, který implementaci v ChatGPT rozebral do detailu, jsou automatizace přes MCP Events dostupné na všech plánech ChatGPT.

Z pull na push: agent dostane zvonek

Dosud fungoval agent jako člověk, který pořád dokola chodí ke schránce kontrolovat poštu. Většinou je prázdná, a když něco přijde, zjistí to stejně až při další obchůzce. Tomu se říká polling: opakované dotazování, jestli se něco nezměnilo.

MCP Events dávají agentovi zvonek. Nic nekontroluje. Když se něco stane, server zazvoní a agent začne pracovat.

V praxi to znamená méně pomocné infrastruktury. Dnes, když chceš, aby AI zareagovala na nový tiket nebo e-mail, stavíš cron, který se každých pár minut na něco ptá, nebo scénář v Zapieru, který událost chytí a přepošle dál. Funguje to, ale každý takový mezičlánek musíš hlídat a platit.

S událostmi přímo v MCP stačí jeden kus: server, který agentovi dává tooly, mu zároveň řekne, že se něco stalo.

Co si s tím postavíš

Všechny scénáře mají stejný tvar: když se stane X, agent udělá Y. Rozhoduje, kdo provozuje MCP server.

Nad vlastním serverem to jde už dnes a nemusíš na nikoho čekat. Vezmi třeba e-shop (názvy jsou jen ilustrační):

Událost order.complaint_created se spustí, když zákazník podá reklamaci.
Payload nese jen minimum: orderId a krátký text reklamace.
Agent si přes tooly stejného serveru dohledá objednávku, zkontroluje, jestli je zboží v záruce, a do chatu ti napíše návrh postupu i odpovědi zákazníkovi.

Stejně postavíš hlášení o pádu buildu ve vlastním CI, upozornění na docházející zboží nebo shrnutí incidentu z interního monitoringu.

Scénáře z virálního postu, kdy GitHub ohlásí každý PR, Linear každý nový tiket a Superhuman každý e-mail, zatím nefungují. Ty nástroje musí events nejdřív naimplementovat do svých MCP serverů, a to se ještě nestalo.

Jak to funguje pod kapotou

Server nejdřív ohlásí schopnost (capability) events. Metodou events/list pak klientovi vrátí katalog událostí. Každá má název, popis, inputSchema (parametry odběru) a payloadSchema (tvar dat, která přijdou).

Návrh počítá se třemi režimy doručení:

poll: klient se ptá přes events/poll a posílá kurzor, aby věděl, kde skončil,
push: events/stream drží otevřené spojení přes SSE (Server-Sent Events, jednosměrný proud zpráv ze serveru),
webhook: klient přes events/subscribe zaregistruje svou callback URL a server do ní pošle POST, když se něco stane. Odhlásí se přes events/unsubscribe.

Webhook nepatří serveru: URL dodává agent, server do ní jen volá. ChatGPT podle WorkOS umí jen webhook, poll ani push nepodporuje.

Odběr vypadá zhruba takhle (zjednodušeně, podle draftu):

{
  "method": "events/subscribe",
  "params": {
    "name": "ticket.created",
    "arguments": { "project": "web" },
    "delivery": { "url": "https://agent.example.com/mcp/events" },
    "ttlMs": 3600000
  }
}

name a arguments určují, co chceš odebírat, delivery.url kam to má přijít. ttlMs je navržená životnost odběru, tady hodina. Spec dovoluje i ttlMs: null, tedy odběr bez expirace. To je riskantní, proč, rozebírám v části Na co si dát pozor. Server odpoví časem refreshBefore a klient musí odběr obnovit dřív, než vyprší:

{
  "result": {
    "refreshBefore": "2026-10-04T21:00:00Z"
  }
}

Doručená událost pak (opět zjednodušeně) nese eventId, podle kterého klient pozná duplicity, a samotná data:

{
  "eventId": "evt_01",
  "name": "ticket.created",
  "payload": { "title": "Nový úkol na nástěnce" }
}

Každý požadavek je podepsaný podle Standard Webhooks (HMAC-SHA256 s tajemstvím whsec_…). Callback URL se musí nejdřív ověřit: server před aktivací pošle na URL podepsanou výzvu (challenge) a klient musí odpovědět, že adresa je jeho. URL musí běžet jen na https, bez přesměrování, a server se musí bránit proti SSRF (zneužití serveru k volání interních adres).

Spec zná i řídicí zprávu terminated, kterou server klientovi oznámí, že odběr skončil, třeba po odebrání práv. ChatGPT ji nepodporuje, takže o zrušení se dozví až ve chvíli, kdy se mu nepovede odběr obnovit.

Že to není jen papír, ukázal komunitní vývojář 2. 10. 2026. Po připojení serveru do ChatGPT a novém načtení toolů se na stránce pluginu objevila událost, kterou server nabízí. Na pokyn „hlídej tuhle firmu“ si ChatGPT sám vytvořil odběr a ověřil callback. Po testovací události se během pár sekund ozval v chatu, aniž by se ho kdokoli ptal.

Kdo za MCP Events stojí

MCP Events jsou návrh rozšíření otevřeného protokolu MCP. Píše ho MCP Triggers & Events Working Group, založená v březnu 2026. Vedou ji Peter Alexander z Anthropicu a Clare Liguori z AWS. Návrh designu vznikl 19. 2. 2026 a v září prošel revizí, celý je ve veřejném repozitáři v souboru docs/design-sketch-proposal.md.

V tomhle má virální post pravdu. Méně vendor lock-inu je výhoda. Z velkých klientů zatím víme o podpoře jen u ChatGPT, ale protože jde o otevřený standard, jakmile ho podpoří další klienti, stejný server bude budit i je.

Že se tím směrem hýbe víc lidí, ukazují i další návrhy. SEP-2495 řeší, aby server mohl rovnou spustit nové kolo LLM. A v repozitáři Hermes agenta od Nous Research leží issue, které chce MCP Events použít jako zdroj probuzení místo pollingu.

Na co si dát pozor

Je to draft. Oficiální SDK events zatím neumí: Python SDK mcp 2.2.0 ani TypeScript SDK. Specifikace se ještě může změnit.
Odběr je přístupový údaj. WorkOS upozorňuje, že odběr vzniká pod tokenem uživatele, ale doručování běží i po vypršení tokenu. Spec vyžaduje kontrolu práv při subscribe, opakovanou kontrolu jen doporučuje a interval neurčuje. Když tedy zaměstnanec odejde a firma mu vezme přístup do aplikace, server mu může dál posílat firemní data, třeba změny smluv nebo nové tikety, do jeho ChatGPT. Tam je vidí v chatu a spouští nad nimi automatizace až do konce TTL nebo do další neúspěšné obnovy.
Proto dávej krátké TTL, nikdy odběr bez expirace (ttlMs: null) a práva kontroluj průběžně, WorkOS zmiňuje třeba každých 15 minut.
Payload je nedůvěryhodný vstup. Platí stejné obrany proti prompt injection (podstrčeným instrukcím v datech) jako u výsledků toolů.
Počítej s opakováním. Zápisy dělej idempotentní, duplicity odfiltruj podle eventId a v payloadu posílej jen minimum dat. Oprávnění ověř až ve chvíli, kdy agent něco dělá.

Jak začít

Začni jednou událostí, ne celým katalogem. Vyber věc, kvůli které dnes obnovuješ stránku, a udělej z ní událost.

Přečti si design v repozitáři pracovní skupiny.
Do svého MCP serveru přidej events/list a webhook odběr přes events/subscribe.
V Pythonu můžeš vyjít z komunitního balíku mcp-webhook-events, se kterým test s ChatGPT vznikl. Je to rozšíření nad oficiálním SDK: chybějící metody events/* doplní přes add_request_handler.
Pohlídej dvě zrady z toho testu. Transport vyžaduje hlavičku Mcp-Method a ta musí odpovídat metodě v těle požadavku, jinak dostaneš chybu -32020. A capability events musíš vložit přes middleware, protože SDK neznámé klíče v capabilities při serializaci zahodí.
Připoj server do ChatGPT, nech znovu načíst tooly a napiš „hlídej mi X“.