Agentenfähiges Unternehmen

Termine von KI-Agenten buchen lassen

Von Gorden Wübbe · Zuletzt aktualisiert: 28. August 2026

„Kann ChatGPT bei mir einen Termin buchen?" ist eine Frage, die in Beratungsgesprächen inzwischen fast wöchentlich fällt – und fast immer meinen zwei Personen am Tisch etwas Verschiedenes damit. Die eine denkt an ihren eigenen Assistenten, der irgendwo anders einen Termin besorgt. Die andere denkt an Kundschaft, die nachts um elf mit einem Agenten spricht und am Ende in ihrem Kalender steht. Nur eine der beiden Fragen lässt sich heute zuverlässig beantworten.

Zwei Fragen, die verwechselt werden

Richtung eins: Ihr Agent bucht anderswo. Also der Assistent, der beim Zahnarzt, in der Werkstatt oder beim Steuerberater einen Termin holt. Dafür gibt es keinen Standard. Terminvergabe läuft im deutschsprachigen Raum überwiegend über geschlossene Buchungsportale, die fremden Agenten keine offene Schnittstelle anbieten. Suchsysteme mit agentischen Funktionen führen Buchungen bislang über eingebundene Partnerplattformen aus – Restaurants, Reise, Ticketing –, nicht über eine beliebige Praxis um die Ecke. Bleibt der gesteuerte Browser, der das Formular ausfüllt wie ein Mensch: technisch möglich, aber empfindlich gegen Anmeldungen, Sicherheitsabfragen und jeden Relaunch. Wer darauf einen Geschäftsprozess baut, baut auf Sand.

Richtung zwei: Fremde Agenten buchen bei Ihnen. Diese Seite ist heute lösbar, und zwar mit vorhandenen Bausteinen. Sie entscheiden selbst, was buchbar ist, unter welchen Regeln und mit welchen Daten. Und Sie stehen auf der Seite, auf der es bereits ein Protokoll gibt, statt gegen fremde Schutzmechanismen zu arbeiten. Der Rest dieses Artikels handelt von dieser Richtung.

Die vier Stufen bis zum Termin

Zwischen der Frage „hast du am Dienstag Zeit?" und einem Eintrag in Ihrem Kalender liegen vier Stufen. Sie fallen einzeln aus, und drei davon haben mit künstlicher Intelligenz nichts zu tun: finden – der Agent muss überhaupt wissen, dass bei Ihnen gebucht werden kann; verstehen – er muss erkennen, welche Art von Termin er sucht; prüfen – er braucht echte freie Zeiten, keine Vermutung; buchen – er muss verbindlich schreiben dürfen und eine Bestätigung zurückbekommen.

Der wunde Punkt liegt fast nie beim Modell. Er liegt bei Stufe drei und vier: Ein Kalender, dessen freie Zeiten nur ein eingebettetes Widget kennt, ist für einen Agenten leer. Und ein Buchungsformular, das erst nach zwei Bestätigungsklicks und einem Cookie-Banner sein Ziel erreicht, wird eben nicht gebucht.

Der teure Irrtum beim MCP-Server

Cal.com betreibt einen offiziellen MCP-Server unter mcp.cal.com, der die Schnittstelle der Version 2 in 34 Werkzeuge übersetzt: Buchungen anlegen, verschieben, absagen, Termintypen verwalten, Zeitpläne pflegen. Die Anmeldung läuft über OAuth, der Client führt einmal durch die Freigabe, danach spricht der Agent mit dem Kalender.

Genau hier entsteht das Missverständnis, das mehrere Projekte in die falsche Richtung geschickt hat. Dieser Zugang ist der Schlüssel zu einem Konto, nicht die Ladentür zu einem Betrieb. Wer sich dort mit seinem Agenten anmeldet, verwaltet seinen eigenen Kalender. Eine fremde Interessentin, die bei Ihnen buchen will, hat davon nichts – sie müsste sich in Ihr Konto einloggen, und dann hätte sie Zugriff auf alles, was Ihre 34 Werkzeuge können.

Die gute Nachricht steht in der Dokumentation der Schnittstelle: Das Anlegen einer Buchung und das Abfragen freier Zeiten sind öffentlich. Sie brauchen dafür keinen Schlüssel, den Sie irgendwem geben müssten – und genau deshalb lässt sich ein schmaler Endpunkt bauen, der Fremden ein bisschen erlaubt und sonst nichts.

Anleitung in sechs Schritten

• 1. Den Kalender zum Vertrag machen: Ein Termintyp ist die Stelle, an der Sie alles festlegen, was der Agent später nicht mehr verhandeln kann: Dauer, Puffer davor und danach, Mindestvorlauf, wie weit im Voraus gebucht werden darf, wie viele Termine pro Tag möglich sind, und ob eine Buchung sofort gilt oder erst nach Ihrer Bestätigung. Je weniger Pflichtfelder, desto weniger Gelegenheiten, sich etwas auszudenken – Name, E-Mail, Anliegen reichen meist.
• 2. Prüfen, ob die öffentliche Schnittstelle genügt: Vor jeder Zeile Code: Erst mit zwei Aufrufen nachsehen, ob Ihr Termintyp so überhaupt buchbar ist. Freie Zeiten lesen und eine Testbuchung anlegen – wenn das nicht sauber durchläuft, hilft kein Agent darüber hinweg.
• 3. Einen eigenen Endpunkt mit genau zwei Werkzeugen: Der Endpunkt ist eine kleine Anwendung, die per MCP zwei Funktionen anbietet und dahinter die Kalender-API aufruft. Zwei, nicht zwanzig: freie Zeiten lesen und einen Termin anlegen. Die Beschreibungen schreiben Sie für ein Sprachmodell, nicht für Ihre Entwicklerdokumentation – sie entscheiden darüber, ob das richtige Werkzeug zur richtigen Zeit gewählt wird.
• 4. Absichern, bevor jemand es findet: Ein öffentlicher Buchungsendpunkt ist ein Formular ohne Aufsicht. Ratenbegrenzung je Adresse, E-Mail-Bestätigung im Termintyp, eine Obergrenze an Buchungen pro Tag, keine Rückgabe fremder Termine, keine internen Hostnamen in Beschreibungen und ein Protokoll, das jede Buchung nachvollziehbar macht.
• 5. Einbinden und mit echten Sätzen testen: Erst im eigenen Client verbinden, dann prüfen, wie das Modell sich unter realen Formulierungen verhält: „nächste Woche vormittags", „so früh wie möglich", „mein Kollege kommt mit". Interessant sind die Fälle, in denen kein Termin frei ist – da zeigt sich, ob Ihr Werkzeug ehrlich antwortet oder das Modell etwas erfindet.
• 6. Auffindbar machen: Ein Endpunkt, von dem niemand weiß, wird nicht benutzt. Buchungsseite verlinken und im Markup als Handlung auszeichnen, in llms.txt und Agent Card aufnehmen, in der robots.txt nicht versehentlich aussperren.

Schritt 2 im Detail: zwei Aufrufe, die alles entscheiden

Freie Zeiten lesen – lesend, ungefährlich, jederzeit wiederholbar:

curl -s "https://api.cal.com/v2/slots?eventTypeId=123\
&start=2026-09-01&end=2026-09-05&timeZone=Europe/Berlin" \
  -H "cal-api-version: 2024-09-04"

Und die Buchung selbst. Auffällig daran ist, was fehlt: ein Authorization-Header. Der Versionskopf dagegen ist Pflicht, sonst antwortet eine ältere Fassung der Schnittstelle mit einem anderen Format:

curl -X POST https://api.cal.com/v2/bookings \
  -H "Content-Type: application/json" \
  -H "cal-api-version: 2026-02-25" \
  -d '{
    "eventTypeId": 123,
    "start": "2026-09-02T08:00:00Z",
    "attendee": {
      "name": "Anna Berger",
      "email": "anna.berger@example.de",
      "timeZone": "Europe/Berlin",
      "language": "de"
    }
  }'

Die Startzeit steht in UTC. Wer das übersieht, verschiebt im Sommer jeden Termin um zwei Stunden – der häufigste Fehler in dieser Kette und einer, den kein Modell für Sie bemerkt.

Schritt 3 im Detail: das lesende Werkzeug

Der Endpunkt selbst ist unspektakulär: ein MCP-Server, der über HTTP erreichbar ist und zwei Funktionen anmeldet. Entscheidend ist nicht der Code, sondern die Beschreibung – sie ist das, was das Modell liest, wenn es entscheidet, ob dieses Werkzeug gemeint ist:

server.registerTool(
  "freie_termine",
  {
    title: "Freie Termine abfragen",
    description:
      "Nennt freie Termine für ein Erstgespräch in der Praxis " +
      "in einem Zeitraum. Gibt Startzeiten in der Zeitzone " +
      "Europe/Berlin zurück. Bucht nichts.",
    inputSchema: {
      von: z.string().describe("Erster Tag, Format JJJJ-MM-TT"),
      bis: z.string().describe("Letzter Tag, Format JJJJ-MM-TT"),
    },
    annotations: { readOnlyHint: true },
  },
  async ({ von, bis }) => {
    const slots = await calSlots(von, bis);
    return {
      content: [{ type: "text", text: formatSlots(slots) }],
      structuredContent: { slots },
    };
  },
);

Das zweite Werkzeug – termin_buchen – ist ebenso schmal: Startzeit, Name, E-Mail, Anliegen, sonst nichts. Es gibt die Buchungsnummer und den bestätigten Zeitpunkt zurück, damit der Agent nicht behaupten muss, etwas sei gebucht, ohne es zu wissen. Alles Weitere – Absagen, Verschieben, Termintypen – gehört nicht in einen öffentlichen Endpunkt. Wer absagen will, klickt den Link in seiner Bestätigungsmail.

Schritt 5 im Detail: einbinden in Claude und ChatGPT

In Claude tragen Nutzer eigene Remote-MCP-Server unter Customize → Connectors als eigenen Connector ein; in Team- und Enterprise-Organisationen legt das eine Person mit Eigentümerrechten einmalig für alle an, danach verbindet sich jeder selbst. In ChatGPT führt der Weg über die Connectors in den Einstellungen, für eigene Server derzeit im Entwicklermodus – oder Sie bauen eine App auf Basis des Apps SDK und reichen sie zur Prüfung für das Verzeichnis ein. Beides ist heute machbar; nur ist keines davon ein Automatismus, der ohne Zutun Ihrer Kundschaft funktioniert.

Damit Agenten es überhaupt finden

Ein Endpunkt ohne Auffindbarkeit ist eine Telefonnummer ohne Verzeichnis. Vier Bausteine helfen, und keiner davon ist Zauberei:

Die Buchungsseite selbst muss erreichbar, verlinkt und ohne JavaScript verständlich sein – das ist der Weg, den heute die meisten Agenten tatsächlich nehmen. Die Auszeichnung im Markup sagt maschinenlesbar, dass hier etwas gebucht werden kann. llms.txt und eine Agent Card fassen für Agenten zusammen, wofür Sie zuständig sind und welche Einstiege es gibt – nützlich, aber kein Rankingfaktor bei Google. NLWeb schließlich macht aus vorhandenen Schema.org-Daten einen natürlichsprachigen Endpunkt, der zugleich als MCP-Server dient – interessant für Kataloge und Bestände, für einen einzelnen Terminkalender Overkill.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Zahnarztpraxis Berger",
  "url": "https://praxis-berger.de",
  "telephone": "+49301234567",
  "address": { "@type": "PostalAddress", "streetAddress": "…" },
  "potentialAction": {
    "@type": "ReserveAction",
    "name": "Termin buchen",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://cal.com/praxis-berger/erstgespraech",
      "actionPlatform": "https://schema.org/DesktopWebPlatform"
    },
    "result": { "@type": "Reservation", "name": "Behandlungstermin" }
  }
}

Welche maschinenlesbaren Einstiege diese Website selbst anbietet, steht unter Maschinenlesbare Schnittstellen. Wie eine Seite einem Agenten Werkzeuge direkt im Browser reicht – die Variante ohne eigenen Server –, erklärt WebMCP.

Grenzen, Missbrauch und DSGVO

Der Aufbau oben funktioniert. Er löst aber fünf Dinge nicht, und die sollte man kennen, bevor man ihn öffentlich stellt:

• Reichweite: Ein eigener Endpunkt wird nicht automatisch von jedem Agenten gefunden. Heute muss ihn die Nutzerin bewusst hinzufügen – oder Sie reichen eine App in ein Verzeichnis ein und durchlaufen die Prüfung des Anbieters. Wer eine Buchung an sich verspricht, verspricht zu viel.
• Identität: Der Agent bucht mit den Angaben, die ihm jemand genannt hat. Ob die E-Mail-Adresse stimmt, weiß niemand, bis sie bestätigt wurde. Für Termine, an denen Aufwand hängt, gehört die Bestätigungspflicht in den Termintyp und nicht in die Hoffnung.
• Missbrauch: Was ein Agent buchen kann, kann ein Skript hundertfach buchen. Eine Obergrenze pro Adresse und Tag, ein Mindestvorlauf und ein Blick in das Protokoll sind kein Übermaß, sondern die Voraussetzung dafür, den Endpunkt offen lassen zu können.
• Datenschutz: Name, E-Mail und Anliegen sind personenbezogene Daten, im Behandlungs- oder Beratungskontext oft besonders schutzbedürftige. Es braucht einen Auftragsverarbeitungsvertrag mit dem Kalenderdienst, eine Entscheidung über den Hosting-Ort – Cal.com lässt sich auch selbst betreiben – und die Regel, dass das Werkzeug nur zurückgibt, was der Buchende selbst eingegeben hat. Niemals fremde Termine, auch nicht als Freitext.
• Fremder Text im Rückgabewert: Alles, was Ihr Werkzeug zurückgibt, liest das Modell im selben Textstrom wie seine Anweisungen. Geben Sie keine ungeprüften Eingaben Dritter zurück – ein Anliegen-Freitext aus einer anderen Buchung ist der bequemste Weg, einen Agenten fremdzusteuern.

Nüchtern betrachtet ist das kein Grund zu warten, sondern eine Reihenfolge: erst der Kalender mit klaren Regeln, dann die saubere Buchungsseite, dann der Endpunkt. Die ersten beiden Schritte zahlen sich auch dann aus, wenn kein einziger Agent je vorbeikommt – weil Menschen genau daran ebenfalls scheitern.

Häufige Fragen

Kann ChatGPT heute einfach so bei mir einen Termin buchen?

Nur, wenn der Weg dorthin existiert. Ein Agent braucht entweder eine Schnittstelle, die Ihr Kalender ihm anbietet, oder er füllt Ihr Buchungsformular wie ein Mensch aus. Der zuverlässige Weg ist der erste: ein eigener MCP-Endpunkt mit zwei Werkzeugen vor einem Kalender wie Cal.com. Der Nutzer muss diesen Endpunkt derzeit noch bewusst in seinem Client hinzufügen.

Reicht nicht der offizielle Cal.com-MCP-Server unter mcp.cal.com?

Für Ihr eigenes Terminmanagement ja – Sie verbinden ihn per OAuth mit Ihrem Konto und lassen Ihren Agenten Buchungen, Termintypen und Zeitpläne verwalten. Für fremde Interessenten nicht: Wer sich dort anmeldet, greift auf sein eigenes Cal.com-Konto zu, nicht auf Ihren Buchungsschalter. Öffentliche Terminbuchung braucht einen eigenen Endpunkt mit stark begrenztem Funktionsumfang.

Muss ich dafür programmieren können?

Für den Kalender selbst nicht, der ist Konfiguration. Der öffentliche Endpunkt ist eine kleine Anwendung von wenigen hundert Zeilen, die irgendwo laufen und gepflegt werden muss – inklusive Erreichbarkeit, Zertifikat und Protokoll. Das ist der Teil, der Aufwand macht, und der Teil, den man nicht nebenbei betreibt.

Was kostet das?

Der Kalender ist bei einem einzelnen Nutzer meist kostenlos oder im niedrigen zweistelligen Bereich pro Monat, selbst betrieben nur die Serverkosten. Der Endpunkt kostet einmalig Einrichtung und dann laufend das, was jeder kleine Dienst kostet: Betrieb, Erreichbarkeit, gelegentliche Anpassung, wenn sich die Schnittstelle ändert.

Und wenn mein Agent umgekehrt beim Zahnarzt buchen soll?

Das ist die andere Richtung, und dort gibt es keinen Standard. Geschlossene Buchungsportale bieten fremden Agenten keine offene Schnittstelle an, und Suchsysteme mit agentischen Funktionen führen die Buchung bislang über eingebundene Partnerplattformen aus, nicht über beliebige Praxen. Bleibt das Ausfüllen des Formulars im gesteuerten Browser – das funktioniert, bricht aber an Anmeldungen, Sicherheitsabfragen und jedem Relaunch.

Bringt das etwas für die Sichtbarkeit bei Google?

Nicht direkt. llms.txt wird von Google nicht ausgewertet, und ein MCP-Endpunkt ist kein Rankingfaktor. Was wirkt, ist die Grundlage darunter: eine erreichbare, korrekt ausgezeichnete Buchungsseite, die Menschen und Maschinen gleichermaßen verstehen. Der Endpunkt zahlt auf Erreichbarkeit ein, nicht auf Platzierungen.

Quellen

• Cal.com Docs – MCP-Server unter mcp.cal.com, OAuth 2.1 und die 34 Werkzeuge
• GitHub – calcom/cal-mcp, der offizielle MCP-Server von Cal.com
• Cal.com Docs – POST /v2/bookings mit Pflicht-Header cal-api-version
• Cal.com Docs – welche Endpunkte öffentlich sind und keinen Scope brauchen
• Anthropic Support – eigene Connectors über Remote-MCP hinzufügen
• OpenAI Developers – Apps SDK: einen MCP-Server an ChatGPT anbinden
• OpenAI – Apps können zur Prüfung und Aufnahme ins Verzeichnis eingereicht werden
• Google – agentische Buchung im AI Mode über eingebundene Partnerplattformen
• NLWeb – Schema.org-Daten als natürlichsprachiger Endpunkt, zugleich MCP-Server
• Schema.org – ReserveAction zur Auszeichnung einer Buchungsmöglichkeit