Abonner på arrangementer over MCP

En AI-agent som er koblet til Kanera over MCP kan be om å bli fortalt når arbeidet endres, i stedet for å polle. Kanera implementerer webhook-leveringen av utkastet MCP-hendelser utvidelse: agentens vert registrerer et HTTPS-tilbakekall, Kanera bekrefter det, og fra da av blir hver matchende endring lagt ut til den som en signert JSON-forekomst.

Dette er mekanismen bak "se dette tavlen og fortell meg når en kommentar lander" i en klient som ChatGPT. Verten eier tilbakeringingen; du kjører ikke en server eller limer inn en URL hvor som helst i Kanera.

Hvem dette er for Hvis du bruker ChatGPT, les Se etter endringer i ChatGPT Resten av denne siden er kontrakten på trådnivå for folk som bygger sin egen MCP-vert eller en tilpasset integrasjon, og for alle som ønsker å vite nøyaktig hva en agent kan og ikke kan bli fortalt. :::

Hva en agent kan abonnere på

Hendelse	Brann når	Ekstra felt i data
card.created	Et kort opprettes i det overvåkede området.	title, listId, url
card.updated	Et kort endres: tittel, beskrivelse, fullføring, arkivstatus og andre kortfelt.	title, listId, url
card.moved	Et kort flyttes innenfor eller mellom lister eller tavle.	listId (bestemmelsesstedet), fromListId (kilden), prevPosition, url
card.blocked	Et aktivt kort får sin første åpne blokkering, inkludert gjenåpning eller restaurering.	title, listId, url; ingen blokkeringsdetaljer
card.unblocked	Et aktivt kort mister sin siste åpne blokkering gjennom fullføring, arkivering, avkobling eller fjerning av blokkeringskortet eller listen.	title, listId, url; ingen blokkeringsdetaljer
schedule.conflict_detected	Et åpent kort får sin første planleggingskonflikt: En åpen blokkering er planlagt å fullføre på eller etter starten.	blockerCardId, days (hverdager avhengige må flytte)
schedule.conflict_resolved	Et åpent kort mister sin siste planleggingskonflikt.	Ingen flere tidsplanfelt
schedule.critical_path_slipped	Et kort med kritisk banes planlagte slutt beveger seg senere og forsinker styrets planlagte slutt.	previousProjectedFinish, projectedFinish, days, slipDays
comment.created	En kommentar er lagt ut på et kort.	commentId, text (opptil 8000 tegn), url
priorities.changed	Din egen Neste Køen kan ha endret seg.	Ingen. Se Din neste kø.
my_day.ready	Det er en ukedag morgen i din tidssone.	localDate, timeZone. Se Morgenbriefing.
reminder.due	En av dine egne kort påminnelser kommer forfall.	reminderId, cardId, remindAt, url. Se Kortpåminnelser.

Alle kort og kommentarer er med workspaceId, boardId, cardId, og en actor (se Å fortelle dine egne skrivere fra hverandre). Nyttelast er begrenset sammendrag: et korts beskrivelse, vedlegg og full kommentartråd er aldri inkludert. Agenten leser den gjeldende posten med cards.get eller comments.list Når det trengs mer.

For kort, kommentar og planlegge hendelser, abonnement argumenter begrense hva som leveres:

Argument	Påkrevd	Effekt
workspaceId	Ja	Bare hendelser i dette arbeidsområdet.
boardId	Nei	Kun arrangementer på dette tavlen. Obligatorisk for gjester.
listId	Nei	Bare hendelser for kort i denne arbeidsområdelisten. For card.moved, et kort inn eller ut av listen matcher og reorders innenfor det ikke. boardId Se den delte listen på alle tilgjengelige tavle.
cardId	Nei	Kun hendelser for dette kortet. Krever boardId.

Access følger den tilkoblede identiteten ved hver levering, ikke bare ved abonnering. Et medlem av arbeidsområdet kan se hele arbeidsområdet; en gjest på tvers av organisasjonen må navngi en tavle de har blitt invitert til; en gjest begrenset til tildelte elementer må navngi et kort de er for øyeblikket tildelt. Hvis identiteten senere mister tilgang til omfanget, stopper leveringen og abonnementet utløper. Å miste tilgang til ett kort i et abonnement på hele tavlen hopper bare over den forekomsten.

Avhengighetsoverganger

card.blocked og card.unblocked Følg kortavhengigheter, inkludert endringer fra personer, integrasjoner, automatiseringer og speilede kort. De krever ikke en automatiseringsregel. Å legge til en ytterligere blokkering eller rydde bare en av flere blokkeringer gjentar ikke overgangen. Hver retning er begrenset til en gang per kort per transaksjon.

Hendelsen beskriver det avhengige kortet og utelater blokkeringsdetaljer for å beskytte private tavle. Les cards.get for de gjeldende forholdene som er synlige for tilkoblingen din. Kontroller gjeldende tilstand før du handler, fordi en automatisering kanskje allerede har flyttet eller fullført kortet.

Planlegg overganger

De tre schedule.* bruker samme arbeidsdag som Tidslinjevisning og work.schedule. De krever at tidslinje og avhengigheter skal aktiveres i de effektive organiserings- / arbeidsromsinnstillingene, og krever ikke en automatiseringsregel.

• schedule.conflict_detected er overgangen fra ingen planleggingskonflikter til minst en. cardId Navn på avhengige blockerCardId Dens viktigste motstridende forutsetninger og days er antall arbeidsdager fra mandag til fredag som det avhengige kortet må flyttes mot høyre. Det gjentas ikke når en ny konflikt legges til.
• schedule.conflict_resolved betyr at et åpent kort ikke har noen konflikter igjen, for eksempel etter at datoer endres, en blokkering fullføres eller en avhengighet fjernes. Å fjerne bare én av flere konflikter avfyrer det ikke. En senere gjentakelse kan utløse gjenkjenning igjen.
• schedule.critical_path_slipped krever at både et kritisk korts egen planlagte slutt flyttes senere og at styrets projiserte slutt flyttes senere. En datoendring absorbert av slakk kvalifiserer ikke, og legger heller ikke bare til nytt arbeid. days måler hvor langt projeksjon flyttet; slipDays måler sin senhet mot den siste forfallsdato. En projeksjon kan flytte senere mens slipDays Det er fortsatt null.

Den innledende tidsplanevalueringen etablerer en grunnlinje i stedet for å kunngjøre alle eksisterende konflikter. Hendelser rapporterer påfølgende grenser; bruk work.schedule for gjeldende tilstand når du starter en klokke eller gjenoppretter fra tapte leveranser. Les den igjen på en hendelse før du foreslår endringer. Disse varslene ombestiller ikke kort.

For en egendefinert vert, abonner på hvert hendelsesnavn separat. Denne forespørselen ser første konflikter på ett tavle; erstatte faktiske arbeidsområde og tavle UUIDs og vertens verifiserte tilbakeringing og signering hemmelighet:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "events/subscribe",
  "params": {
    "name": "schedule.conflict_detected",
    "arguments": { "workspaceId": "…", "boardId": "…" },
    "delivery": {
      "mode": "webhook",
      "url": "https://receiver.example.com/kanera/events",
      "secret": "whsec_…"
    },
    "ttlMs": 86400000
  }
}

En kritisk bane slip forekomst ser slik ut (IDer og datoer er illustrerende):

{
  "eventId": "evt_…_schedule.critical_path_slipped",
  "name": "schedule.critical_path_slipped",
  "timestamp": "2026-11-02T10:00:00.000Z",
  "data": {
    "workspaceId": "…",
    "boardId": "…",
    "cardId": "…",
    "previousProjectedFinish": "2026-11-06",
    "projectedFinish": "2026-11-09",
    "days": 1,
    "slipDays": 1,
    "actor": { "kind": "user", "userId": "…", "self": false }
  },
  "cursor": null
}

Datoer er YYYY-MM-DD; varighet, slakk, og slip teller ekskluderer helger. Kort og tidsplan hendelser kan beskrive den samme underliggende redigering, men har forskjellige hendelses-IDer. Deduplikat prøver på nytt ved eventId og sjekk actor.self før du reagerer på dine egne endringer. Se planlegging eksempler.

Din neste kø

priorities.changed forteller en agent at den tilkoblede brukerens egen Up neste kø kan ha endret seg, slik at den kan lese køen på nytt i stedet for å avspørre. Den branner på hver endring som endrer rekkefølgen eller endrer størrelsen på køen:

• en oppføring legges til, flyttes eller fjernes, enten fra webappen, API-et eller en annen agent;
• et kort i køen er fullført, arkivert, restaurert eller omfordelt, som tar det ut av livekøen eller setter det tilbake.

Det krever ingen argumenter (pass {}) og er aldri omfattet av et arbeidsområde, fordi køen spenner over hvert arbeidsområde du jobber i. Forekomsten bærer bare hvem som endret den:

"data": {
  "targetUserId": "…",
  "actor": { "kind": "user", "userId": "…", "self": false }
}

targetUserId er alltid den tilkoblede brukeren. Ingenting om køens kort er inkludert. Call priorities.list for den gjeldende rangeringen; den gjelder ditt normale kort synlighet.

Du kan bare se din egen Det er ingen argumenter for en annen persons, og det inkluderer arbeidsområdeadministratorer som kan lese en lagkamerats kø med priorities.list. Selv et varsel uten innhold ville avsløre når og av hvem et kort som overvåkeren ikke kan se ble fullført eller omfordelt. En gjest eller en skrivebeskyttet API-nøkkel kan også se sin egen kø.

Morgenbriefing

my_day.ready lar en agent briefe deg hver arbeidsmorgen uten egen planlegger. Kanera sender den en gang om dagen, mandag til fredag, kl 08:00 i tidssonen på profilen din, samtidig som daglig fordøyelses e-post. Det følger fordøyelsen innstilling: mens din daglige fordøyelses e-post er av, ingen ping sendes. Det sendes om noe er på grunn, slik at agenten kan fortsatt rapportere en klar dag.

Det krever ingen argumenter (pass {}) og bare beskriver din egen dag. Forekomsten bærer ikke noe arbeid:

"data": {
  "targetUserId": "…",
  "localDate": "2026-10-12",
  "timeZone": "Europe/London",
  "actor": { "kind": "system", "userId": null, "self": false }
}

Agenten ringer etter work.my_day med det timeZone. Ett anrop returnerer dine forfalte kort, kort som forfaller i de neste syv dagene, kort med forfalte sjekklisteelementer, tildelte kort som har vært inaktive i 14 dager eller mer, og toppen av din neste kø, alt sjekket mot din nåværende tilgang.

Også briefingen kommer tilbake schedule.conflicts, schedule.critical, og schedule.lateToStart: dine tildelte kort med konflikter, kritiske banekort uten konflikter og kort som har planlagt start uten å gå inn i fremgang. Sen start-sjekker krever sporing av tid i gang og en liste over pågående, og ekskluder allerede forfalte kort.

Et abonnement varer opptil 24 timer per oppdatering, så klienten må holde oppdatere den for å motta neste morgens ping. ChatGPT gjør dette mens oppgaven er aktiv.

Kortpåminnelser

reminder.due En agent kan handle når en av dine kort påminnelser branner, for eksempel for å legge kortet inn i en chat eller begynne å jobbe med det. Påminnelser er satt fra kortets alarmknapp, eller av en agent med cards.set_reminder. Det tar ingen argumenter (pass {}) og dekker bare dine egne påminnelser; ingen kan abonnere på andres.

Kanera sjekker for påminnelser hvert 30. sekund og sender en forekomst per påminnelse. Omplanlegger en påminnelse om at allerede avfyrt armer det igjen, og neste avfyring er en ny forekomst. Forekomsten navngir kortet, men bærer ikke noe av innholdet:

"data": {
  "targetUserId": "…",
  "reminderId": "…",
  "cardId": "…",
  "remindAt": "2026-10-16T07:00:00.000Z",
  "url": "https://board.kanera.app/o/…/c/MKT-42",
  "actor": { "kind": "system", "userId": null, "self": false }
}

Agenten ringer cards.get med cardId for det aktuelle kortet. Leveringskontroller at du fortsatt kan se kortet; en påminnelse på et kort som siden har blitt arkivert, eller at du ikke lenger kan få tilgang til, branner uten varsel eller en hendelse.

Se etter endringer i ChatGPT

Installer og koble til Kanera-plugin ved hjelp av ChatGPT oppsettsguide, og deretter velger du den i en arbeidssamtale som støtter hendelsesdrevne oppgaver. En kompatibel vert oppdager hendelsesfunksjonen automatisk. For en egendefinert MCP-tilkobling, åpne den i Programtillegg og velg Oppdater etter serveren endringer. Publiserte plugin verktøyoppdateringer følger OpenAI gjennomgang prosess.

I en samtale der Kanera-appen er vedlagt, spør om hva du vil skal skje:

Watch the Product board in Kanera. When a new comment appears on any card, summarise it for me and suggest a reply.

Tell me whenever a card moves into the Done list on the Launch board.

Whenever my Up next queue changes, tell me what is now at the top.

Every weekday morning, brief me on what is overdue, what is due this week, and what is at the top of my Up next queue.

Watch the Launch board for scheduling conflicts and critical-path slips. Read the current schedule when one appears, tell me which cards and dates are affected, and propose a repair. Tell me when conflicts clear. Do not change dates.

ChatGPT oppretter abonnementet på egen hånd vert tilbakeringing, oppdaterer den mens oppgaven er aktiv, og avslutter den når du stopper oppgaven. Kanera sender aldri arbeidet ditt hvor som helst ChatGPT har ikke bevist det styrer (se Tilbakekallsbekreftelse).

Flere bearbeidede eksempler, inkludert å svare på spørsmål på kort, triaging nytt arbeid, og vokte et enkelt kort, er i Eksempler på hvordan du bruker.

To ting å vite når du skriver oppgaven:

• Unngå looper. Hver forekomst navngir sin aktør og om abonnementstilkoblingen forårsaket det. En oppgave som reagerer på kommentarer ved å kommentere bør sjekke actor.self Enten skriver du en gang til, eller så svarer du selv.
• Les før du skriver. Forekomsten er et sammendrag. Spør oppgaven om å lese kortet først, og å bruke verktøyenes idempotensnøkler for repeterbare endringer.

Levering er best-innsats med en avgrenset retry vindu (se Levering og retries). Hvis ChatGPT's tilbakekalling er uoppnåelig lenger enn det, forekomsten er savnet; oppgaven gjenopprettes ved å lese gjeldende tilstand.

Protokollen

Hendelser er bare tilgjengelige på verts-HTTP-endepunktet. https://mcp.kanera.app/mcp eller din egen distribusjon /mcp, og bare til klienter på gjeldende MCP-protokoll, som er det som legger til hendelsesabonnementer. kanera mcp over stdio tilbyr dem ikke: en lokal stdio vert har ingen vert tilbakeringing å levere til.

server/discover Det er mulig å få inn begge capabilities.events (hva ChatGPT Les også: I dag og capabilities.extensions["io.modelcontextprotocol/events"] (der utvidelsesforslaget plasserer det). Tre forespørselsmetoder følger, autentisert nøyaktig som verktøyanrop, med et OAuth-tilgangstoken eller en API-nøkkel som bærer. Eksemplene nedenfor viser bare metodeparametrene; klientbiblioteket legger til protokollens per-forespørsel-hoder og metadata.

events/list

Returnerer katalogen ovenfor med et JSON-skjema for hver hendelses argumenter og nyttelast. Katalogen er en enkelt side; cursor Det må være tomt eller fraværende.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "events/list",
  "params": {}
}

events/subscribe

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "events/subscribe",
  "params": {
    "name": "comment.created",
    "arguments": { "workspaceId": "…", "boardId": "…" },
    "delivery": {
      "mode": "webhook",
      "url": "https://receiver.example.com/kanera/events",
      "secret": "whsec_…"
    },
    "ttlMs": 86400000
  }
}

Felt	Regler
delivery.mode	Bare webhook støttes. Enhver annen modus returnerer -32014 Unsupported med data.feature = "deliveryMode".
delivery.url	HTTPS, ingen legitimasjon i URL-adressen, ingen fragment, og det må løse til en offentlig adresse. Loopback, privat, link-lokal, sky-metadata og IPv4-kartlagt eller overgang IPv6-adresser blir avvist.
delivery.secret	whsec_ etterfulgt av 24 til 64 bytes base64. Kanera lagrer det kryptert og signerer hver levering med det.
ttlMs	Forespurt levetid. Standard og maksimum er 24 timer; en kortere positiv verdi er oppfylt, og null (ingen utløpstid) er begrenset til 24 timer.
cursor, maxAgeMs	Akseptert for kompatibilitet. Kanera tilbyr ingen replay: cursor Alltid tilbake som null, og en ikke-null-forespørselsmarkør rapporteres som truncated: true.

Svaret:

{
  "id": "sub_…",
  "refreshBefore": "2026-10-07T13:00:00.000Z",
  "cursor": null,
  "truncated": false,
  "deliveryStatus": {
    "active": true,
    "lastDeliveryAt": "2026-10-06T12:58:10.000Z",
    "lastError": null
  }
}

Abonnementet id er deterministisk for tilkoblingen, tilbakeringingsadressen, hendelsesnavnet og argumentene (for priorities.changed, my_day.ready, og reminder.due, den tilkoblede brukeren), så ringer events/subscribe Igjen, med samme identitet, er det oppfrisk: Det utvider refreshBefore, aksepterer en ny secret (både det gamle og det nye hemmelige skiltet leveres i fem minutter), og returnerer deliveryStatus Et abonnement som fortsatt er aktivt. deliveryStatus er utelatt på et første abonnement og på en fornyelse etter utløp. refreshBefore; et utløpt abonnement fornyet senere starter frisk fra fornyelsestiden, uten replay av hva det savnet.

active er alltid true: Kanera suspenderer aldri et abonnement for leveringsfeil. Det begrenser retries per forekomst i stedet og rapporterer endepunktets helse gjennom lastError (en av connection_refused, timeout, tls_error, http_4xx, http_5xx, challenge_failed) og failedSinceTilstede mens endepunktet fortsetter å svikte.

En tilkobling kan inneholde opptil 100 aktive abonnementer. -32013 ResourceExhausted.

events/unsubscribe

Tar det samme name, arguments, og delivery.url, uten hemmelighet. Bare tilkoblingen som opprettet et abonnement kan avslutte det; en annen legitimasjon forespørsel er en no-op. Avmelding er idempotent.

Feil

Kanera bruker feilkoder utkastet dokumenter for hendelser. Abonnement feil bære strukturert data En slik kan en vert handle på dem uten å parse meldinger.

Kode	Navn	Når
-32011	NotFound	name Det er ikke i katalogen (data.kind = "event").
-32012	Forbidden	Identiteten kan ikke se det forespurte omfanget, eller legitimasjonen er ikke en API-nøkkel eller OAuth-tilkobling.
-32013	ResourceExhausted	Abonnementsgrensen (data.max) eller en satsgrense.
-32014	Unsupported	En annen leveringsmåte enn webhook (data.feature, data.value).
-32015	CallbackEndpointError	Verifisering mislyktes. data.reason er en av connection_refused, timeout, tls_error, http_4xx, http_5xx, eller challenge_failed. Et avslått reisemål rapporteres som challenge_failedFeilmeldinger kan ikke brukes til å kartlegge et privat nettverk.
-32602	InvalidParams	En feilformet forespørsel, en ugyldig hemmelighet eller URL, et arbeidsområde, tavle eller kort i arguments Det finnes ikke, eller det finnes ikke argumenter. priorities.changed, my_day.ready, eller reminder.due.

Tilbakekallsbekreftelse

Før et abonnement er lagret, Kanera beviser tilbakeringing er din. Det legger inn en bekreftelse forespørsel til delivery.url, signert med hemmeligheten du leverte:

{ "type": "verification", "challenge": "…" }

Endpoint må svare 2xx med en JSON kropp som ekko utfordringen nøyaktig:

{ "challenge": "…" }

Alt annet svikter abonnementet med -32015 og årsaken ovenfor. Omdirigeringer blir aldri fulgt. En vellykket bekreftelse er bufret i fem minutter per tilkobling og tilbakeringingsadresse, så forfriskende eller varierende arguments Jeg gjentar ikke utfordringen.

Verifisering kjører med samme strenge destinasjonspolicy som levering: Offentlige HTTPS-adresser bare, løst en gang og festet for tilkoblingen, slik at en DNS-endring mellom sjekken og forespørselen ikke kan omdirigere den.

Levering og retries

Hver hendelse er en POST til tilbakekallingen med Content-Type: application/json:

{
  "eventId": "evt_…",
  "name": "comment.created",
  "timestamp": "2026-10-06T12:58:09.412Z",
  "data": {
    "workspaceId": "…",
    "boardId": "…",
    "cardId": "…",
    "commentId": "…",
    "text": "Can we ship this on Thursday?",
    "url": "https://board.kanera.app/o/3F2A9C1D7B4E6A08/c/PROJ-123",
    "actor": { "kind": "user", "userId": "…", "self": false }
  },
  "cursor": null
}

Overskrift	Innhold
webhook-id	Den eventId. Stabil over retries; bruke den til å gjøre handleren idempotent.
webhook-timestamp	Unix sekunder når dette forsøket ble signert. Frisk på hver ny prøve.
webhook-signature	En eller flere romseparerte v1,<base64> signaturer (to under en hemmelig rotasjon).
X-MCP-Subscription-Id	Abonnementet id.

Kroppsbytene er identiske ved hvert forsøk; bare tidsstempelet og signaturen endres.

Svar 2xx å anerkjenne. Kanera behandler svar som følger:

Respons	Adferd
2xx	Liket blir ignorert.
410, 413, og andre 4xx	Denne forekomsten er droppet. Abonnementet fortsetter; fremtidige forekomster leveres fortsatt.
408, 425, 429, 5xx, timeout, TLS eller tilkoblingsfeil	Prøvde igjen med samme eventId: fem forsøk totalt på omtrent 0 s, 30 s, 1,5 min, 3,5 min og 7,5 min. Etter at forekomsten er droppet.

Et responslegeme over 4 KiB blir kastet uten å påvirke utfallet. En forekomst over 256 KiB blir aldri sendt. Kanera holder leveringsrekord i 14 dager.

Leveringer for et aktivt abonnement overlever Kanera starter på nytt. Autorisasjon sjekkes på nytt før hvert forsøk, så en frakoblet agent, en tilbakekalt nøkkel, et fjernet medlem eller en gjest som mistet et oppdrag, slutter å motta data ved neste forsøk, ikke ved neste oppdatering.

priorities.changed forekomster er køen øyeblikket køen endringen er lagret, ikke fra varig endring loggen som korthendelser bruker, fordi køen ikke er knyttet til et enkelt arbeidsområde. I sjeldne tilfeller at Kanera starter på nytt i det øyeblikket, kan ett varsel gå tapt; neste priorities.list Lesing er alltid aktuelt.

Bekreft signaturen

Ordningen er Standard Webhooks oppsett. Dekode hemmeligheten etter whsec_ prefiks fra base64, HMAC-SHA256 strengen {webhook-id}.{webhook-timestamp}.{body}, og sammenligne mot hver signatur i overskriften i konstant tid:

import crypto from "node:crypto";
import express from "express";

const app = express();
const key = Buffer.from(process.env.KANERA_MCP_EVENT_SECRET!.slice("whsec_".length), "base64");

app.post("/kanera/events", express.raw({ type: "application/json" }), (req, res) => {
  const body = req.body.toString("utf8");
  const payload = JSON.parse(body) as { type?: string; challenge?: string };
  const id = req.header("webhook-id") ?? "";
  const timestamp = req.header("webhook-timestamp") ?? "";
  const expected = crypto.createHmac("sha256", key).update(`${id}.${timestamp}.${body}`).digest("base64");
  const digest = Buffer.from(expected);
  const valid = (req.header("webhook-signature") ?? "").split(" ").some((entry) => {
    const received = Buffer.from(entry.replace(/^v1,/, ""));
    return received.length === digest.length && crypto.timingSafeEqual(received, digest);
  });
  if (!valid) return res.status(401).send("invalid signature");
  // Verification challenge: echo it back.
  if (payload.type === "verification") return res.json({ challenge: payload.challenge });
  // Occurrence: handle it idempotently by webhook-id.
  res.sendStatus(204);
});

Kontroller alltid mot rålegemet. Avvis leveranser som webhook-timestamp Det er mer enn noen minutter til reprise.

Å fortelle dine egne skrivere fra hverandre

En agent som reagerer på hendelser ved å skrive tilbake vil se sine egne skriver komme rundt som hendelser. userId En personlig API-nøkkel eller en OAuth-agent fungerer som brukeren, så en kommentar som agenten har lagt ut og en kommentar som personen har lagt ut, bærer det samme. userId.

Hver hendelse inkluderer derfor:

"actor": { "kind": "apiKey", "userId": "…", "self": true }

Felt	Betydning
kind	user (Nettappen), apiKey, agent (en interaktiv OAuth-agent), support, automation, eller system.
userId	Brukeren ble endret som. null Automatisering og systemendringer.
self	true bare når abonnementstilkoblingen selv gjorde endringen: samme OAuth agent tilskudd, samme API-nøkkel som brukes direkte, eller samme uovervåket servicetilkobling.

Automatiseringseffekter rapporteres som automation selv når agentens egen skriving utløste dem, så en regel som legger til en etikett etter agentens kommentarer, leses ikke som agentens skriving.

Den title og text felt er brukerinnhold. Behandle dem som data, aldri som instruksjoner til agenten.

Bruker samme API

MCP-metodene videresender til tre offentlige API-ruter, som godtar samme bærerlegitimasjon og samme forespørsels- og svarorganer. Bruk dem fra en integrasjon som inneholder en API-nøkkel og vil ha hendelsesabonnementer uten å snakke MCP:

Rute	MCP-metode
GET /api/v1/mcp-events	events/list
POST /api/v1/mcp-events/subscribe	events/subscribe
POST /api/v1/mcp-events/unsubscribe	events/unsubscribe

Feil returneres som offentlige API-problemdokumenter med kodene MCP_EVENT_NOT_FOUND, MCP_EVENT_UNSUPPORTED, MCP_SUBSCRIPTION_LIMIT, og MCP_CALLBACK_ENDPOINT, som MCP-laget kartlegger på feiltabellen ovenfor.

For en teamintegrasjon som skal overleve en hvilken som helst tilkobling og dekke hele arrangementskatalogen, bruk Webhooks i stedet. MCP-hendelsesabonnementer tilhører legitimasjonen som opprettet dem, utløper innen 24 timer med mindre de oppdateres, og dekker bare de fire kort- og kommentarhendelsene pluss din egen neste kø. Webhooks leverer ikke neste endringer, fordi køen er personlig i stedet for arbeidsområdedata.

Feilsøking

Problem	Hva du skal sjekke
Kunden tilbyr ikke arrangementer.	Den må kobles til verten /mcp endepunkt på gjeldende MCP-protokoll. Skann serveren på nytt i klienten; stdio via kanera mcp Aldri tilby hendelser.
events/subscribe returer -32015 med challenge_failed.	Tilbakeringingen ga ikke ekko av utfordringen, svarte på en ikke-2xx-status, omdirigert, eller er på en privat, loopback eller metadata-adresse. Kanera rapporterer bevisst alle disse på samme måte.
-32012 Forbidden på abonner.	Identiteten kan ikke se arbeidsområdet, tavlen eller kortet. boardId; tildelt-elementer-bare gjester må passere en tildelt cardId. Sesjonsinformasjonskapsler kan ikke abonnere; bruk en OAuth-tilkobling eller en API-nøkkel.
Leveringene stoppet, men abonnementet oppdateres fortsatt.	Sjekk deliveryStatus.lastError og failedSince Hvis legitimasjonen ble tilbakekalt eller brukeren mistet tilgang, har abonnementet utløpt og oppdateringen returnerer ingen deliveryStatus.
Agenten reagerer på sine egne kommentarer.	Sjekk data.actor.self Før du skriver.
-32602 Når du abonnerer på priorities.changed.	Pass tom arguments. En targetUserId eller andre argumenter blir avvist: bare din egen kø kan sees.
Mistet endringer etter et utbrudd.	Opptakene stopper etter ca 7,5 minutter og det er ingen replay. Les gjeldende tilstand med cards.list, cards.get, comments.list, eller priorities.list.

Relaterte sider

• Sett opp ChatGPT
• MCP teknisk referanse
• Webhooks
• Neste
• Påminnelser
• Agent sikkerhet