MCP und OAuth

Was ist jetzt möglich?

Realite stellt einen MCP-Endpunkt bereit. Ein MCP-Client kann damit:

• dein Dashboard lesen
• Gruppen und Kontakte lesen, Gruppen anlegen
• Events und Kommentare lesen
• Vorschläge lesen und entscheiden
• Einstellungen lesen und Vorschlagslimits ändern
• Smart-Treffen lesen, anlegen und aktualisieren
• mit eigener Berechtigung Date nutzen: Kandidaten suchen, Interesse zeigen, Termine, Orte, Fragen und Angaben aushandeln. Details stehen unter Date-Tools
• Aktionen vorschlagen, die du in der App freigibst: Events anlegen, kommentieren, Kontakte einladen, Mitglieder hinzufügen, Gruppen ändern und löschen, Einladungslinks, Gruppenbeitritte, Kalenderauswahl sowie Date-Annahmen, die Date-Verhandlung, Feedback und Bürgschaften

Welche Tools sofort wirken und welche auf dich warten, steht im Abschnitt Bestätigungsschicht.

Der Zugriff läuft über OAuth mit Better Auth. Dein MCP-Client bekommt also keinen statischen Realite-Login, sondern authentifiziert sich regulär gegen Realite und erhält dann ein Zugriffstoken.

Wichtige URLs

• MCP-Endpunkt: /api/mcp
• kompatibler Alias für Clients mit Standardpfad: /mcp
• OAuth Protected Resource Metadata: /.well-known/oauth-protected-resource/api/mcp
• OAuth Protected Resource Metadata für den Alias: /.well-known/oauth-protected-resource/mcp
• OAuth Protected Resource Metadata Fallback: /.well-known/oauth-protected-resource
• OAuth Authorization Server Metadata: /.well-known/oauth-authorization-server
• OpenID-Konfiguration: /.well-known/openid-configuration

So läuft die Anmeldung ab

1. Dein MCP-Client verbindet sich mit dem geschützten Resource-Endpunkt von Realite.
2. Realite verweist den Client auf die OAuth-Metadaten von Better Auth.
3. Du meldest dich mit einem für dieses Deployment freigeschalteten Realite-Login an, heute im Regelfall Google.
4. Du bestätigst den Zugriff auf dein Realite-Konto.
5. Danach kann der MCP-Client Tools und Resources von Realite nutzen.

Wenn du in Realite bereits angemeldet bist, setzt Realite den OAuth-Flow direkt fort. Du musst die Anmeldung in diesem Fall nicht noch einmal manuell neu anstossen.

Welche Berechtigungen werden angefragt?

Realite verwendet für MCP aktuell diese Scopes:

• openid
• profile
• email
• offline_access
• realite:read
• realite:write
• realite:dating (separater Date-Zugriff)
• realite:photos (separater Fotozugriff, nur zusammen mit realite:dating)

realite:read deckt lesende Zugriffe ab. realite:write erlaubt Änderungen wie neue Gruppen oder Entscheidungen auf Vorschläge und das Anlegen von Aktionen, die auf deine Freigabe warten. realite:dating und realite:photos sind für alle nutzbar, müssen aber ausdrücklich angefragt und bestätigt werden.

Hinweise für MCP-Clients

• Der MCP-Transport läuft über HTTP POST auf /api/mcp.
• Falls ein Client automatisch den Standardpfad /mcp verwendet, akzeptiert Realite auch diesen Alias.
• Der Endpunkt ist OAuth-geschützt und erwartet ein Bearer-Token.
• Access Tokens gelten 24 Stunden. Mit offline_access kann der Client sie über ein Refresh Token bis zu 30 Tage lang erneuern, ohne dass du dich erneut anmelden musst.
• Für Discovery sollte der Client die Protected-Resource-Metadata lesen statt feste Auth-URLs anzunehmen.
• Browser-basierte Clients können den WWW-Authenticate-Header lesen; darüber findet der Client die passende resource_metadata-URL.
• Realite nutzt den angemeldeten Better-Auth-User als Grundlage und synchronisiert daraus den internen App-User.

Typische Probleme

Der Client bekommt 401 Unauthorized

Meist fehlt das Bearer-Token, oder das Access Token passt nicht zu dieser Resource. Prüfe insbesondere:

• ob /.well-known/oauth-protected-resource/api/mcp erreichbar ist
• ob bei Nutzung des Alias auch /.well-known/oauth-protected-resource/mcp erreichbar ist
• ob alternativ /.well-known/oauth-protected-resource erreichbar ist
• ob der Client wirklich ein Access Token für die Resource /api/mcp oder /mcp anfordert
• ob die Anmeldung und die Consent-Seite vollständig abgeschlossen wurden

Wenn der Client gleichzeitig „Angemeldet“ und „Anmeldung erforderlich“ zeigt, wurde das Token gespeichert, aber Realite hat einen späteren MCP-Request mit 401 abgelehnt. Dann den Flow komplett neu starten, nicht nur die alte Consent-URL erneut öffnen.

Wenn die Anmeldung zuerst klappt und nach kurzer Zeit wieder verlangt wird, hat der Client das Access Token nicht rechtzeitig erneuert. Nach einem erneuten Login sollte die Verbindung dann einen vollen Tag halten. Persistiert der Client Refresh Tokens korrekt, ist danach keine erneute Anmeldung nötig.

MCP Inspector im Browser zeigt CORS-Fehler

Wenn du den MCP Inspector lokal im Browser nutzt, kommen Requests typischerweise von einer Localhost-Origin (z. B. http://localhost:6274).

Realite erlaubt dafür CORS auf den Discovery- und MCP-Endpunkten:

• /.well-known/oauth-protected-resource/api/mcp
• /.well-known/oauth-protected-resource/mcp
• /.well-known/oauth-authorization-server
• /.well-known/openid-configuration
• /api/mcp
• /mcp

Falls du eine andere Origin verwenden willst, setze MCP_ALLOWED_ORIGINS als kommaseparierte Liste (z. B. http://localhost:6274,http://localhost:3001).

Hinweis: Für den Browser-Inspector muss CORS nicht nur auf den /.well-known- und /api/mcp-Routen stimmen, sondern auch auf den OAuth-Endpunkten unter /api/auth/* (z. B. Dynamic Client Registration).

Was bedeuten issuer und audience?

• issuer: Wer hat das Access Token ausgestellt (der OAuth-Server).
  Realite erwartet hier die eigene Origin (z. B. https://realite.app).
• audience: Für welche Resource ist das Token gedacht.
  Realite erwartet hier den MCP-Resource-Endpunkt https://realite.app/api/mcp oder den kompatiblen Alias https://realite.app/mcp.

Wenn issuer oder audience nicht zum Token passen, lehnt Realite den Zugriff auf /api/mcp mit 401 ab.

Die Anmeldung endet wieder auf der Login-Seite

Dann wurde der OAuth-Flow nicht vollständig fortgesetzt oder die Sitzung ist nicht gültig. Starte die MCP-Verbindung neu und melde dich erneut an.

Der MCP-Client sieht keine Realite-Daten

Realite legt den internen App-User beim ersten gültigen Zugriff automatisch an bzw. aktualisiert ihn aus Better Auth. Wenn der Client zwar authentifiziert ist, aber keine Daten sieht, melde dich einmal regulär in Realite an und versuche es dann erneut.

Getrennte Berechtigungen

Jeder Tool-Aufruf und jeder Resource-Abruf prüft die Berechtigungen des Zugriffstokens:

• realite:read: lesende Tools und Resources, einschließlich Inbox und Agentenprotokoll.
• realite:write: Änderungen im Freunde-Modus und Dashboard-Refresh. Nach außen wirkende Schritte laufen über die Bestätigungsschicht.
• realite:dating: Date-Profil lesen, Änderungen daran vorschlagen, Date-Tools und die Resource realite://dating. Dieser Scope ist unabhängig von den beiden Freunde-Berechtigungen.
• realite:photos: Freigegebene Date-Fotos an deinen Agenten und dessen Modellanbieter übermitteln. Gilt nur zusammen mit realite:dating und schließt realite:write aus. Realite lehnt Freigabe, Token und Aufrufe mit Fotozugriff ohne Date-Zugriff ab. Mit Fotozugriff sind nur lesende Date-Aufrufe möglich; unbekannte Date-Aufrufe und Date-Aktionen mit Außenwirkung bleiben gesperrt.

Date-Zugriff wird auf der Bestätigungsseite als eigener Eintrag mit deutschem Hinweis angezeigt. Neue Clients erhalten ihn nicht als Registrierungsstandard. Ein Client, der Date nutzen soll, muss realite:dating bei Registrierung und Autorisierung ausdrücklich anfordern. Fehlende Scope-Angaben im Token erlauben keinen Zugriff. Eine Ablehnung nennt die fehlende Berechtigung; verbinde den Client bei Bedarf erneut mit dem passenden Scope.

Date-Tools

Alle Date-Tools brauchen realite:dating. Für den Ablauf braucht das Konto außerdem die Date-Einwilligung, ein vollständiges Profil und eine bestätigte Telefonnummer. Die Einwilligung gibt nur der Mensch in der App. Eingaben und Ausgaben sind strukturiert: feste Listen, Bereiche, Zeiten und Referenzen. Name, Foto, E-Mail, Telefonnummer, Nutzer-ID und Freitext anderer Personen kommen nicht vor.

Bereich	Tools	Wirkung
Profil	date.get_profile_schema, date.get_my_profile, date.get_budget, dating.get	Lesen
Profil ändern	date.propose_profile_changes, date.propose_preferences, dating.update	Nur ein Vorschlag. Übernehmen kann nur der Mensch unter Profil und Vorlieben
Kandidaten	date.find_candidates, date.send_interest	Suche ohne Wirkung auf andere. Ein erstes Interesse wirkt direkt, im Rahmen des Budgets
Ablauf	date.list, date.get_plan, date.respond_to_interest, date.propose_slots, date.respond_to_slot, date.request_confirmation	Annehmen und Vorschlagen laufen über die Bestätigungsschicht, Absagen wirken sofort
Orte	date.search_places, date.propose_places, date.respond_to_place	Gegend und Ortsart nur aus festen Listen
Fragen und Angaben	date.get_question_catalog, date.ask_question, date.answer_question, date.list_questions, date.share_details	Nur der feste Katalog. Beantwortet wird nur mit der gespeicherten Antwort des Menschen unter der Regel Mein Agent darf antworten
Nach dem Date	date.submit_feedback, date.get_insights, reputation.get	Feedback wartet auf Freigabe. Vorschläge aus dem Rückblick übernimmt der Mensch
Bürgschaften	vouch.create, vouch.list	vouch.create wartet auf Freigabe
Fotos	date.get_photos	Braucht zusätzlich realite:photos, siehe unten

date.find_candidates und date.get_budget liefern das Budget mit. queriesRemainingThisHour zählt alle Abfragen der Stunde, refreshesRemaining nur Abrufe mit neuen Kandidaten. Beim Stundenlimit meldet das Tool retryAfterSeconds.

Ein Tool für diese Schritte gibt es bewusst nicht: Zusage, Absagen eines Dates, Eintragen, ob es stattgefunden hat, Melden, Einwilligung, Foto-Freigabe. Vorname, Notiz und Kontaktweg stehen nur für Menschen in der App. Ist Date pausiert oder abgeschaltet, antworten die Tools mit „Der Date-Modus ist derzeit nicht verfügbar.“

Der Ablauf für Menschen steht unter Date im Überblick.

Agentenaktionen ansehen und Zugriff widerrufen

Unter Einstellungen → Agentenzugriff & Protokoll findest du die letzten 20 Aktionen und die freigegebenen Clients. Das Protokoll enthält Zeitpunkt, Client (soweit bekannt), Aktion, Modus und Ergebnis. Bekannte Aktionen stehen dort als lesbarer Text, zum Beispiel Freigegeben: Event anlegen, alles andere als Toolname. Aufrufparameter, Kommentare und andere persönliche Inhalte werden nicht protokolliert. Auch abgelehnte Aufrufe erscheinen im Protokoll. Technische Protokollierungsfehler verhindern die eigentliche Aktion nicht.

Mit Zugriff widerrufen entfernst du die Freigabe und die gespeicherten Zugriffs- und Refresh-Tokens dieses Clients. Bereits ausgestellte JWT-Zugriffstokens werden am MCP-Endpunkt ebenfalls abgelehnt. Für eine neue Verbindung ist eine erneute OAuth-Freigabe nötig. Ein bereits laufender Aufruf wird dadurch nicht abgebrochen.

Agenten können ihr eigenes Protokoll mit activity.list({limit?}) abrufen (maximal 100 Einträge).

Inbox und Benachrichtigungen

inbox.get({since?, limit?}) liefert {items, cursor, nextPollAfterSeconds}. Beim ersten Abruf kann since fehlen. Danach gibt der Client den zurückgegebenen Cursor als Zeichenkette unverändert beim nächsten Abruf mit. Maximal 100 Einträge werden pro Abruf geliefert. Ohne neue Einträge bleibt der Cursor gleich; der nächste Abruf sollte frühestens nach 60 Sekunden erfolgen.

Hinweise entstehen bei neuen Vorschlägen, Kommentaren anderer Personen auf eigenen Events, Teilnahmeanfragen über einen geteilten Wochenstatus, beim Hinzufügen zu einer Gruppe per E-Mail und wenn eine Aktion auf deine Freigabe wartet (agent.action_pending, im Date-Modus date.agent_action_pending). Neuberechnungen bestehender Vorschläge erzeugen keinen weiteren Hinweis. Hinweise enthalten nur Ereignisart und Referenz-IDs. Sie verfallen standardmäßig nach 48 Stunden und werden danach nicht mehr ausgeliefert. Ein Hinweis ist keine automatische Zusage und ändert keine Teilnahme.

Bei einem Hinweis wird ein Web-Push über die bestehende Hintergrundwarteschlange eingeplant. Dafür müssen Push-Benachrichtigungen eingerichtet und erlaubt sein. Der feste Text lautet „Neue Aktivität bei Realite“, ohne Namen, Profilangaben oder Kommentare. Wartet eine Aktion auf dich, führt der Push zu /agent-actions, bei Date-Hinweisen zu /dates. Date-Hinweise wecken auch Personen ohne verbundenen Agenten, wenn sie Push eingeschaltet haben. E-Mail-Benachrichtigungen werden dafür nicht versendet. Ein Push startet einen externen Agenten nicht automatisch; der Agent muss die Inbox selbst abrufen können.

Bestätigungsschicht

Die Tools in der Tabelle unten führen nichts selbst aus. Der Tool-Aufruf prüft die Eingabe und legt eine Aktion an. Die Antwort lautet dann:

{ "status": "pending_human_approval", "actionId": "…", "summary": "…", "expiresAt": "…", "note": "…" }

Der Agent kann die Aktion nicht freigeben. Du entscheidest unter Einstellungen → Offene Aktionen deines Agenten oder auf /agent-actions, angemeldet mit einem registrierten Konto. Bearer-Tokens werden dort immer abgelehnt. Offene Aktionen laufen nach 24 Stunden ab. Eine Freigabe führt die Aktion genau einmal aus und prüft dabei die Rechte und den aktuellen Zugriff des Clients neu. Mit Zugriff widerrufen verfallen die offenen Aktionen dieses Clients, mit dem Entzug von realite:dating seine offenen Date-Aktionen.

Tool	Art	Regel	Autopilot möglich
events.create	event_create	Höchstens 10 Tags. Für Gruppen nur mit selbst bestätigter Mitgliedschaft. Farbe nur als #rrggbb	Nur Gruppe oder Freunde, ohne Vor-Ort-Sichtbarkeit, Shortcut und #alle oder #freunde+ irgendwo in Titel oder Tags
events.add_comment	event_comment	Nur eigene oder zugesagte Events. 20 pro Tag, 5 pro Event	Nein
events.invite_contact	event_invite_contact	Nur bestehende Kontakte, per contactRef oder email. 20 pro Tag	Nein
groups.add_member	group_add_member	Nur Eigentümer. Gleiche Antwort mit und ohne Konto. 20 pro Tag, 10 pro Gruppe	Nein
groups.update	group_update	Nur Eigentümer, nur Hashtags: höchstens 10 mit je 40 Zeichen, ohne Komma und Leerzeichen. 10 pro Tag	Nein
groups.delete	group_delete	Nur Eigentümer. 5 pro Tag	Nein
groups.create_invite_link	group_create_invite_link	Nur mit selbst bestätigter Mitgliedschaft. Link nur für den Menschen. 5 pro Tag	Nein
groups.join_by_token	group_join_by_token	5 pro Tag	Nein
settings.update	settings_changes_sensitive	Nur wenn sich die Kalenderauswahl ändert	Nein
date.respond_to_interest, date.respond_to_slot	date_accept	Nur accept. decline wirkt sofort	Ja
date.send_interest	date_accept	Nur wenn die Person schon Interesse gezeigt hat. Das zählt zusätzlich gegen das Tagesbudget für Interessen	Ja
date.propose_slots	date_negotiate_slots	Gegend als areaCode aus der festen Liste, Umkreis 1, 3, 5, 10 oder 25 km	Ja, Schalter date_negotiate
date.propose_places	date_negotiate_places	Höchstens 4 Runden je Date	Ja, Schalter date_negotiate
date.respond_to_place	date_negotiate_place_response	Nur accept und counter. decline wirkt sofort	Ja, Schalter date_negotiate
date.ask_question	date_negotiate_question	Nur aus dem Katalog, höchstens 5 je Seite	Ja, Schalter date_negotiate
date.answer_question	date_negotiate_answer	Nur mit Regel auto_answer, nur die gespeicherte Antwort	Ja, Schalter date_negotiate
date.share_details	date_negotiate_details	Höchstens 3 Änderungen je Date. Gesundheitsangaben gehen auch nach der Freigabe nicht weiter	Ja, Schalter date_negotiate
date.submit_feedback	date_feedback	Wird weiter als Agenten-Feedback gespeichert	Nein
vouch.create	date_vouch		Nein

Den Autopilot schaltest du in derselben Karte ein, je Schalter einzeln. date_negotiate gilt für alle date_negotiate_*-Arten zusammen. Dann antwortet das Tool mit status: "executed" und dem Ergebnis, oder mit status: "failed" und einem Code. Jede Autopilot-Ausführung steht als autopilot.<art> im Protokoll, jede Freigabe als approved.<art>. So liefert es auch activity.list, die Einstellungen zeigen dafür Autopilot: … und Freigegeben: ….

Abgelehnte Aufrufe antworten mit status: "rejected", einem code und einer Begründung, zum Beispiel unknown_contact, human_only_field, rate_limited oder not_allowed. Es sind höchstens 30 Aktionen gleichzeitig offen, davon höchstens 10 je Client, und eine identische offene Aktion wird nicht doppelt angelegt.

Mit actions.status({actionId}) liest ein Agent den Stand einer Aktion: pending, rejected, expired, approved, executed oder failed, bei groups.add_member nach der Entscheidung nur decided_by_human. Dieses Tool braucht realite:read. Date-Aktionen sind darüber nur mit realite:dating sichtbar.

settings.update ändert Limits und blockierte Tags direkt. autoInsertSuggestions und blockedCreatorIds ändert nur der Mensch in den Einstellungen. Die Felder sind optional, geänderte Werte werden abgelehnt.

events.get_invite_context liefert zu Kontakten eine contactRef, die events.invite_contact annimmt. Unbekannte Adressen schlägt das Tool nicht mehr vor.

smart_meetings.create und smart_meetings.update lehnen #date ohne realite:dating ab. Gastkonten können über MCP weder Events noch Smart-Treffen anlegen. In der App können Gäste keine öffentlichen Events anlegen.

date.propose_slots nimmt Beginn und Ende nur im 15-Minuten-Raster an. areaLat und areaLng gibt es für Agenten nicht mehr. date.search_places nimmt ebenfalls nur areaCode aus der festen Liste.

Link-Vorschauen entstehen nur für Events, die ein Mensch freigegeben hat. Autopilot-Events rufen keine fremde Adresse ab.

Was direkt wirkt

Diese Tools laufen ohne Freigabe. Alle anderen, die nicht nur lesen, stehen in der Tabelle oben.

Tool	Warum das kein Weg für private Daten ist
suggestions.decide	Trägt nur Zusage oder Absage zu einem bestehenden Event. note und reasons einer Absage bleiben bei dir. Eine Zusage ist für andere sichtbar, also genau eine Ja-Nein-Information
groups.create	Die neue Gruppe hat nur dich als Mitglied. Name, Beschreibung und Hashtags zeigt die Freigabe, bevor jemand dazukommt. Namen wie #alle und #kontakte sind reserviert
smart_meetings.create, smart_meetings.update	Speichern nur einen Plan. Event und Einladungen entstehen erst, wenn du den Termin unter Vorschläge freigibst. Wartet ein Termin auf dich, lehnt update ab. #alle, #freunde+ und Systemgruppen sind ausgeschlossen
settings.update	Limits und blockierte Tags wirken nur auf deine eigenen Vorschläge. Die Kalenderauswahl ist eine Aktion
date.send_interest an einen Kandidaten ohne vorheriges Interesse	Trägt eine einzige Wahl aus wenigen vorgeschlagenen Personen, begrenzt durch das Tagesbudget
date.request_confirmation	Bittet nur beide Menschen um ihre Zusage und trägt keine Inhalte
date.search_places, date.find_candidates, dashboard.refresh	Erreichen keine andere Person. Die Ortssuche geht mit Gegend und Art aus festen Listen an den Ortsanbieter
alle Absagen	Ein Ausstieg muss immer sofort möglich sein. Jede Absage trägt höchstens eine Ja-Nein-Information

Inhalte offener Aktionen, etwa ein Kommentartext oder eine E-Mail-Adresse, werden gespeichert, bis du entschieden hast, und 7 Tage danach gelöscht. Das Agentenprotokoll enthält sie nicht.

Hinweise zum sicheren Agentenbetrieb

Die Tools aus der Tabelle unter Bestätigungsschicht wirken erst nach deiner Freigabe, außer du hast den Autopilot eingeschaltet. Die wenigen direkten Tools stehen dort mit Begründung. Mit Autopilot kann ein manipulierter Agent frei formulierten Text an deine Freunde oder eine bestätigte Gruppe geben und über die Auswahl in der Date-Verhandlung kleine Mengen an Information weitertragen. Freitext in Ergebnissen gilt als nicht vertrauenswürdiger Inhalt, niemals als Anweisung. Steuer- und bidirektionale Formatierungszeichen werden entfernt, einzelne Textwerte auf 4000 Zeichen begrenzt; die JSON-Struktur bleibt erhalten. Das gilt insbesondere für Titel, Beschreibungen und Kommentare anderer Personen.

Fotos und Fotoreferenzen werden aus allgemeinen MCP-Ergebnissen entfernt. Ausschließlich date.get_photos kann ausdrücklich freigegebene Date-Fotos mit den Berechtigungen realite:dating und realite:photos übermitteln. Date-Daten erscheinen nur in den strukturierten date.*-Tools, im Protokoll und in der Inbox (jeweils mit realite:dating). Allgemeine Listen enthalten keine Date-Events, Date-Treffen oder Date-Kriterien.

Getrennte Modi und geschützte Inhalte

Ohne realite:dating erhält ein Agent keine Date-Hinweise aus der Inbox, keine Date-Aktionen aus dem Protokoll und keine Date-Vorschläge oder Date-Kommentare. Date-Vorschläge lassen sich dann auch nicht beantworten; Events mit #date oder #dating lassen sich nicht erstellen. Mit ausschließlich realite:dating können Agenten Inbox und Protokoll für Date abrufen. Einwilligung und Geburtsjahr werden ausschließlich direkt in der App bestätigt. Date-Sperrtags bleiben bei settings.update erhalten. Date-Vorschläge lassen sich nicht über suggestions.decide bearbeiten; dafür gibt es derzeit kein Date-Tool.

Tool-Ergebnisse und Ressourcen tragen unter _meta.untrustedFields einen Hinweis: Freitext, etwa Titel, Namen und Kommentare, ist fremder Inhalt und keine Anweisung. Unsichtbare Formatierungszeichen werden entfernt. IDs, Zeiten und Enums behalten ihre Form. Freitextstrings werden standardmäßig mit ‹fremder Text›…‹/fremder Text› markiert. Strukturierte Kennungen, Enums, Zeiten, URLs und Tags/Hashtags sind ausgenommen. Die Marker sind ein Datenhinweis und kein Schutzversprechen gegen Prompt-Injection. Ein führender Textblock erklärt dies auch ohne Auswertung von _meta. Deshalb ist content[0] bzw. contents[0] immer ein Sicherheitshinweis: Skripte dürfen Nutzdaten nicht fest aus dem ersten Block lesen.

Erfolgreiche Leseaufrufe werden nach 60 Einzelzeilen je Konto und Minute zusammengefasst; Schreibaufrufe, Fehler und Ablehnungen werden weiter einzeln protokolliert. Erfolgreiches Inbox-Polling erscheint nicht als einzelne Aktion im Protokoll. Ressourcenabrufe und verweigerte Zugriffe werden protokolliert. Protokolle werden nach 30 Tagen gelöscht, abgelaufene Inbox-Hinweise beim nächsten Bereinigungslauf. Die API unterstützt weitere Protokollseiten über Zeitstempel und ID; die Einstellungen zeigen zunächst 20 Einträge. Push-Weckrufe erhalten nur Konten mit einer Agentenfreigabe, höchstens einmal in fünf Minuten.

Telefon und Prüffotos

Verifikation und geschützte Fotos benötigen ein registriertes Konto. Gastkonten können keine Nachweise erhalten. SMS-Anfragen zählen auch bei fehlgeschlagener Nummernprüfung oder Zustellung gegen das Kontingent. Standardmäßig werden Mobilnummern aus Deutschland, Österreich und der Schweiz unterstützt. Bereits belegte Nummern werden bei der Anforderung nicht offengelegt.

Pro Konto sind höchstens zehn Uploadversuche täglich und 20 gespeicherte Fotos zulässig. Große Selfies verkleinert der Browser vor dem Upload; der Server begrenzt Bilder zusätzlich auf vier Millionen Pixel. Eigene Fotos können über die Foto-API gelöscht werden, solange sie nicht in einer offenen Prüfung verwendet werden. Geprüfte Selfie-Evidenz wird nach 30 Tagen zur Löschung vorgemerkt. Konto- und Fotolöschung speichern einen dauerhaften Löschauftrag für den privaten Fotospeicher; fehlgeschlagene Löschungen werden beim nächsten Bereinigungslauf wiederholt.

Listen, Suche und Kontakte

• contacts.list und events.list nehmen optional limit (Standard 50, höchstens 100) und cursor an. Gibt es weitere Einträge, steht der nächste Wert in _meta.nextCursor, am Ende null. Ohne Angabe bleibt die Form der Antwort wie bisher. dashboard.get zeigt höchstens 100 Events und verweist über eventsPagination auf events.list.
• events.get_invite_context sucht nur nach Anzeigenamen (mindestens 2 Zeichen) oder nach einer exakt vollständigen Adresse. Treffer enthalten eine contactRef statt der E-Mail-Adresse.
• events.invite_contact, groups.add_member und vouch.create nehmen eine contactRef entgegen (bei vouch.create als contactRef statt targetEmail). Die bisherige Eingabe per E-Mail-Adresse funktioniert weiter, es gilt genau eines von beiden. Die aufgelöste Adresse bleibt auf dem Server. Dir zeigt die Freigabe Name und Adresse.
• Erwartbare Fehler kommen mit _meta.code und gegebenenfalls _meta.retryAfterSeconds beim Agenten an, zum Beispiel bei einem erreichten Tageslimit.
• Hashtags einer Gruppe darf in der App nur der Eigentümer ändern. Systemgruppen wie #alle und #kontakte sowie synchronisierte Gruppen sind dafür gesperrt, auch für Agenten.

Freigabe, Grenzen und Datensparsamkeit

• Die Freigabe zeigt den bereinigten, auf 100 Zeichen begrenzten Clientnamen und den Host der Rückleitungsadresse. Ungeprüfter Client bedeutet: Name und Ziel stammen vom Client; Realite empfiehlt oder prüft diesen Anbieter nicht.
• Du kannst die angefragten Rechte einzeln auswählen. Date- und Fotozugriff sind zunächst abgewählt. Fotozugriff und Freunde-Schreibzugriff können nicht gemeinsam erteilt werden (getrennte Clients mit je einem der beiden Rechte bleiben erlaubt; die Einstellungen weisen auf diese Kombination hin). Das gilt auch für Token-Erneuerung und bereits ausgestellte Tokens. Fotozugriff gibt es nur zusammen mit Date-Zugriff. Auch eine von Hand gebaute Freigabe ohne Date-Zugriff lehnt der Server ab. Neue Clients erhalten weiterhin standardmäßig weder Date- noch Fotorechte; beide müssen ausdrücklich angefragt und bestätigt werden.
• Gastkonten erhalten keinen MCP-Zugriff. Für die Verbindung ist ein registriertes Konto erforderlich.
• Unter Einstellungen → Agentenzugriff & Protokoll kannst du nur Fotozugriff oder Date-Zugriff entziehen. Date-Widerruf entzieht auch den Fotozugriff. Jeder neue Aufruf verwendet nur Rechte, die sowohl im Token als auch in der aktuellen Freigabe stehen; ein altes Token stellt entzogene Rechte nicht wieder her.
• Agenten können keine öffentlichen Events durchsuchen. Allgemeine Ausgaben schließen öffentliche und Date-Events aus; zugänglich bleiben eigene, Gruppen-, Freunde- und beigetretene Aktivitäten mit entsprechend anderer Sichtbarkeit.
• Fremde E-Mail-Adressen werden aus Text und E-Mailfeldern entfernt (auch Unicode-Adressen und %40). Deine eigene Adresse und technisch benötigte Kalender-IDs und Quellenreferenzen bleiben verwendbar. Kontakte erhalten stattdessen eine kontogebundene contactRef. Die App verwendet weiterhin die vollständigen Kontaktdaten.
• Anfragen sind auf 64 KiB begrenzt, Stapel auf zehn Aufrufe, und es gelten 120 POSTs je Token und Minute. Listen enthalten höchstens 100 sichtbare Einträge; _meta.truncations nennt bei Kürzung Gesamt- und Rückgabezahl. Toolantworten sind auf 128000 Byte begrenzt, die gesamte HTTP-Antwort einschließlich Protokollmethoden auf 128 KiB. Zu große Antworten werden mit einem neutralen Fehler abgelehnt. Fotoantworten haben eigene Größen- und Abrufgrenzen.
• Pro Token und Minute gelten 120 günstige Leseaufrufe, 30 aufwendige Leseaufrufe, 20 Änderungen und 2 Synchronisierungsaufrufe. Pro Konto gilt jeweils das Doppelte. Bei Überschreitung erhält der Agent einen Fehler mit Statushinweis 429 und 60 Sekunden Wartezeit. Diese Grenzen gelten je Serverprozess.
• Dashboard-Abrufe stoßen Synchronisierung und Kalender-Watch-Prüfung höchstens einmal pro Minute an. Unter hoher Last speichert das allgemeine Aktivitätsprotokoll höchstens 60 Einträge je Konto und Minute; weitere Aufrufe erscheinen dort nicht einzeln. Das gesonderte Fotoabrufprotokoll bleibt davon unabhängig.
• Erwartbare Fehler wie ein erreichtes Tageslimit kommen mit Code, sicherer Meldung und gegebenenfalls Wartezeit beim Agenten an. Unerwartete Fehler liefern eine neutrale Meldung mit Referenz statt Datenbankabfragen oder Parametern; der Server protokolliert dazu Fehlerklasse, SQLSTATE und den obersten Stackframe, ohne Meldung, SQL oder Parameter. Link-Vorschauen laden ausschließlich HTTPS-Ziele mit öffentlicher Adresse, prüfen jede Weiterleitung und begrenzen Abrufzeit und Datenmenge. Der Abruf selbst erreicht die fremde Seite, darum läuft er bei Agenten nur nach menschlicher Freigabe.