Ist Ihre API bereit für KI-Agenten? Eine praktische MCP-Bereitschafts-Überprülliste

Arbeitsfähigkeit bedeutet nicht automatisch Agentenbereitschaft

Eine API, die korrekt antwortet, ist noch nicht für KI-Agenten vorbereitet. Das klingt nach einigen Integrationen offensichtlich, wird aber frühzeitig leicht übersehen. Die meisten SaaS-Unternehmen betreiben bereits APIs, auf die ihre Frontend-Systeme, Partner und Kunden täglich zugreifen. Die Routen funktionieren, die Authentifizierung funktioniert und die Produktlogik existiert bereits.

Eine gängige Erstmaßnahme besteht darin, die API direkt an einen Agenten anzuschließen und den Vorgang als abgeschlossen zu markieren. Dadurch wird ein wesentlicher Unterschied übersprungen. Entwickler lesen Dokumentationen, wählen einen Ansatz, schreiben Code, testen Anfragen und behandeln Fehler absichtlich. Ein KI-Klient benötigt eine Schnittstelle, die einen Großteil dieser Arbeit übernimmt: Sie sollte auflisten, was sie kann, jede Aktion klar beschreiben, Eingaben mit Schemata definieren, sich sicher authentifizieren, Ergebnisse in einer vorhersehbaren Form zurückgeben, gegen realistische Fälle getestet worden sein und hinter einem Endpunkt liegen, den man nach dem Start weiterhin betreiben kann.

Eine praktikable Definition lautet wie folgt: Eine API gilt als für KI geeignet, wenn die gewählten Produktfunktionen gefunden, aufgerufen, autorisiert, getestet, gehostet, überwacht und aktualisiert werden können, ohne dass der Client raten muss, wie sich das Produkt verhält. Dazu geht es weniger darum, einfach „KI“ hinzuzufügen, sondern vielmehr darum, eine für Entwickler bestimmte Schnittstelle in eine Funktionsoberfläche zu verwandeln, auf die sich ein Agent verlassen kann.

Dokumentation wird Rohmaterial

Gute API-Dokumentation versorgt heute direkt die für KI bestimmte Schicht. Wenn der Vertrag unklar ist, erben alle daraus generierten oder konfigurierten MCP-Tools diese Unklarheit. Eine Route kann vollkommen gültig sein, während der Agent keine Ahnung hat, wann er sie verwenden soll, was er übergeben muss, was zurückkommt oder ob der Aufruf Daten ändert.

Dokumentation, die für diese Aufgabe geeignet ist, beschreibt für jede Operation Folgendes ausführlich:

• seinen Zweck sowie die Situationen, in denen er angewendet wird
• welche Felder obligatorisch sind und was jede Eingabe bedeutet
• die zulässigen Werte
• die Struktur einer erfolgreichen Antwort
• die auftreten können
• die benötigte Authentifizierungsmethode
• ob er nur Daten liest oder auch ändert
• ob das Endpunkt öffentlich, für Kunden zugänglich, intern, veraltet oder für Administratoren bestimmt ist

Interne APIs stützen sich in der Regel auf gemeinsamen Kontext. Jeder im Unternehmen weiß, was ein „Arbeitsbereich“, ein „Konto“ oder ein „Mitglied“ ist. Ein KI-Klient verfügt nicht über dieses Hintergrundwissen, es sei denn, die Schnittstelle liefert es ihm. Nehmen wir einen Aufruf wie POST /records/update. Das Team, das ihn geschrieben hat, mag ihn klar finden, aber für einen Agenten sagt er fast nichts aus. Welches Datensatz? Welche Felder? Welcher Workflow? Ist es sicher, ohne den Benutzer vorher zu fragen? Was, wenn der Datensatz einem anderen Mieter gehört? Genau dieser fehlende Kontext macht eine funktionsfähige API zu einer anfälligen Agentenschnittstelle.

Schemata weisen den Client an, wie er aufrufen soll

Das Eingabeschema ist der Ort, an dem eine API erklärt, wie eine Operation ohne Raten aufgerufen werden kann. Ein Mensch kann ein fehlendes Schema durch Beispiele, Ausprobieren oder im Team weitergegebenes Wissen ausgleichen. Bei Agenten führen einfache Schemata zu unzuverlässigen Aufrufen. Das Modell könnte Felder erfinden, den falschen Typ verwenden, erforderliche Werte weglassen oder nicht erkennen, welche Parameter in den Pfad, die Abfragesuche, die Header oder den Body gehören.

Ein für Agenten geeignetes Schema macht diese Punkte explizit:

• welche Felder erforderlich sind und welche optional
• Grundtypen wie Text, numerisch, boolesch, Liste und Objektwerte
• spezielle Formate, beispielsweise E-Mail-Adressen, URLs, Datumsangaben, Zeitstempel und Identifikatoren
• Enum-Werte und die zulässigen Zustände
• Unter- und Obergrenzen für Werte
• die Struktur von verschachtelten Objekten
• Seitenleitungs-Eingabefelder wie limit und cursor
• Wie Filter funktionieren und welche Standardwerte sie haben
• Die Antwortfelder, die für den nächsten Schritt wichtig sind

Antworten erfordern genauso viel Sorgfalt wie Anfragen. Wenn ein Tool eine Rechnung zurückgibt, muss dem Agenten mitgeteilt werden, ob er eine ID, einen Status, einen Fälligkeitsdatum, eine Betragsangabe, eine Währung, eine Kundenreferenz, Postenliste oder einen Zahlungslink erhält. Wenn die Dokumentation die Antwort lediglich als „Objekt“ bezeichnet, hat der Client nur sehr begrenzte Möglichkeiten zur Verarbeitung.

Auch die Qualität des Schemas beeinflusst die Sicherheit. Ein locker strukturierter, frei formierter Datensatz lässt dem Modell viel Spielraum, Anfragen zu erstellen, die niemand erwartet hat, während ein eng definiertes Schema den Client im vorgesehenen Workflow hält. Bei Projekten, bei denen eine API in MCP-Tools umgewandelt wird, ist die OpenAPI- oder Swagger-Definition der Vertrag, der die Funktionalitäten bestimmt, die der Agent letztendlich sieht.

Die Authentifizierung hat zwei Ebenen

Gute Dokumentationen enthalten keine Beschreibungen einer KI-Integration mit unklarer Authentifizierung. Zwei Aspekte sind entscheidend: Erstens, wie kann eine Anfrage ihre Identität nachweisen? Zweitens, was darf der Anrufer nach dem Eindringen tun? Zum ersten Thema gehören API-Schlüssel, Träger-Token, OAuth, Header, Berechtigungsgebiete, Ablaufzeiten sowie die Handhabung von Zugangsdaten. Zum zweiten Thema gehören die Trennung der Benutzerkonten, Rollen, Zugriff auf Datensätze, Limits auf Feldebene sowie Berechtigungen für bestimmte Aktionen. Beide Ebenen sollten ausdrücklich erwähnt werden.

Stellen Sie sich drei Arbeitsabläufe vor: Ein Support-Workflow könnte ein nur zum Lesen geeignetes Token benötigen, das auf Tickets und Kundendaten beschränkt ist. Ein Buchungs-Workflow könnte Rechnungen erfordern, aber niemals die Löschung von Konten. Ein Projektmanagement-Workflow könnte das Aktualisieren von Aufgaben zulassen, während die Verwaltung des Arbeitsraums blockiert wird.

Anmeldedaten sollten nicht zu gewöhnlichen, vom Modell sichtbaren Eingaben werden. Niemand sollte vom Agenten verlangen, eine Roh-API-Schlüssel zu erfinden, zu wiederholen oder auszuwählen. Sie gehören auf den Laufzeitpfad und werden innerhalb des bestehenden Sicherheitsmodells des Produkts an die ursprüngliche API übergeben. Eine praktikable Einrichtungsmöglichkeit ist die Durchleitung: Der Benutzer liefert die Anmeldedaten über den MCP-Client, die Hostingschicht leitet sie während der Anfrage an die echte API weiter, ohne sie zu speichern, und die übergeordnete API bleibt für Autorisierung, Tenant-Grenzen und Geschäftsregeln verantwortlich.

Daher geht es nicht darum, ob der MCP-Server eine Anfrage akzeptieren kann. Es geht darum, ob die richtige Identität mit der richtigen Berechtigung die richtige Operation aufrufen kann und ob Fehler verständlich sind, wenn das nicht möglich ist.

Entscheidung darüber, was offengelegt werden soll

Viele APIs sind umfassend, weil Entwickler Flexibilität wünschen. Ein Agent funktioniert in der Regel besser, wenn er sich auf eine Aufgabe konzentrieren kann. Die Fähigkeit, jeden Endpunkt in ein MCP-Tool umzuwandeln, bedeutet nicht, dass man dies unbedingt tun sollte – das Team muss weiterhin entscheiden, welche Operationen zuerst durchgeführt werden.

Starke Kandidaten für frühe Nutzung haben einen offensichtlichen Zweck im Arbeitsablauf:

• Das Abrufen eines bekannten Datensatzes
• Das Suchen innerhalb eines begrenzten Bereichs des Produkts
• Das Auflisten von Datensätzen mit sicheren Filtern
• Das Erstellen eines einfachen Objekts aus erforderlichen Feldern
• Die Änderung eines spezifischen Zustands oder Feldes
• Das Lesen von Status-, Historie- oder Zusammenfassungsdaten

Risikoreichere Kandidaten erfordern eine separate Überprüfung:

• Destruktive Operationen und Massenaktualisierungen
• Änderungen bei Abrechnung und Berechtigungen
• Admin-Endpunkte und interne Wartungswege
• Umfassende Exportfunktionen und beliebige Abfrageendpunkte
• Debug-Endpunkte

Einlogge- oder Token-Endpunkte

Schreiboperationen sind in Ordnung, wenn die Zustandsänderung sichtbar, beabsichtigt, autorisiert und getestet ist. Dennoch übertrifft oft das kleinste nützliche Werkzeugset das größtmögliche. Eine fokussierte Auswahl beseitigt Unklarheiten beim Kunden und verringert die Last in Bezug auf Sicherheit, Testing und Wartung für das Team.

Wenn der Ausgangspunkt unklar ist, wählen Sie einen Kundenauftragsablauf und arbeiten Sie von dort aus rückwärts. Beispiele: Finden Sie die neueste unbezahlte Rechnung eines Kunden, fassen Sie offene Tickets eines Kontos zusammen, erstellen Sie ein Projekt aus einer genehmigten Anfrage oder aktualisieren Sie den Status einer Aufgabe nach Bestätigung durch den Benutzer. Exponieren Sie anschließend nur die Operationen, die der Auftragsablauf benötigt. Wenn die größte Gefahr darin besteht, zu früh zu viel preiszugeben, betrachten Sie die Auswahl der Endpunkte eher als Produktbewertung denn als mechanische Umwandlung.

Namen und Beschreibungen tragen Bedeutung

Die Art und Weise, wie eine Fähigkeit dargestellt wird, bestimmt, wie gut ein Agent sie nutzen kann. Betrachten Sie einen solchen Weg.

PATCH /projects/{project_id}/members/{member_id}

Es gibt dem Entwickler mit an, wohin die Anfrage geht, doch es vermittelt nicht, was die Operation für einen AI-Client bedeutet. Als Tool, das an MCP angebunden ist, wäre vielleicht ein solcher Name besser geeignet.

update_project_member_role

Die Beschreibung sollte dann angeben, wann sie verwendet werden soll, welche Rollenwerte zulässig sind, welche Berechtigungen erforderlich sind und ob die Änderung sofort auf den Zugriff wirkt.

Eine schwache Beschreibung wiederholt lediglich den Pfad, zum Beispiel „Projektmitglied aktualisieren“. Eine starke Beschreibung legt die Entscheidungsgrenzen fest: Sie ändert die Rolle eines bestehenden Projektmitglieds, sollte nur verwendet werden, nachdem der Benutzer das Projekt, das Mitglied und die neue Rolle benannt hat, den Zugriff auf das Projekt geändert hat und eine Berechtigung zum Verwalten von Mitgliedern vorliegt. Die präzisere Formulierung leitet die Auswahl und bietet den Prüfern eine bessere Grundlage zur Überprüfung.

Wenn mehrere Tools ähnlich sind, sollten die Beschreibungen auch angeben, wann eines von ihnen nicht verwendet werden sollte. Der Benutzer muss wissen, was eine Funktion leistet und warum sie besser geeignet ist als die danebenstehende.

Testing umfasst Entdeckung und Fehlerbehebung

Eine erfolgreiche Anfrage reicht nicht aus. Das Testen einer für Agenten geeigneten API bedeutet, den gesamten Weg auf MCP-Ebene zu durchlaufen. Zu beantwortende Fragen:

• Kann ein Client überhaupt mit dem MCP-Server verbunden werden?
• Werden die erwarteten Tools, Ressourcen und Anfragen angezeigt?
• Sind die Namen und Beschreibungen klar genug, um die richtige Funktionalität auszuwählen?
• Werden die erforderlichen Eingaben ordnungsgemäß dargestellt?
• Erreichen gültige Aufrufe die vorgesehene API-Operation, und scheitern ungültige Aufrufe mit einer klaren Meldung?
• Was passiert bei fehlenden, abgelaufenen oder falsch eingeschränkten Zugangsdaten?
• Werden die Autorisierungsregeln weiterhin in der übergeordneten API angewendet?
• Wie verhalten sich leere Ergebnisse, fehlende Einträge, Rate Limits und Zeitlimits?
• Erlauben die zurückgegebenen Daten es dem Agenten, seinen Workflow fortzusetzen?

Dies überprüft sowohl die für Agenten zugängliche Schnittstelle als auch die darunterliegende HTTP-Route. Angenommen, ein Benutzer bittet darum, die kürzlichen Aktivitäten eines Kontos anzusehen. Der Test sollte bestätigen, dass der Client das richtige Tool finden kann, ermitteln kann, welchen Kontoinhaber-Identifikator er benötigt, die Operation mit gültigen Anmeldeinformationen aufrufen kann und die zurückgegebene Aktivitätenliste richtig interpretieren kann.

Ein gehosteter Testumgebungsdienst eignet sich hervorragend für diesen Ablauf. Teams können Tools durchsehen und aufrufen, Ressourcen sowie Anweisungen ausprobieren, die Authentifizierung überprüfen und einzelne Protokolle lesen, bevor echter Traffic ankommt. Realistische Fehler sollten ebenfalls in den Plan einbezogen werden, da sie in der Produktion auftreten: fehlende Felder, fehlerhafte Enum-Werte, abgelaufene Anmeldeinformationen, unzureichende Berechtigungen, Fehlercodes 500 von vorgelagerten Systemen sowie Rate Limits kommen ständig vor.

Die Hosting-Lösung macht es zu einer Produktoberfläche

Ursprünglich mag eine API fertig sein, aber dennoch nicht für den Einsatz in der Produktion geeignet sein. Wenn echte KI-Kunden einen MCP-Server nutzen, muss jemand entscheiden, wo dieser läuft, wie darauf zugegriffen wird, wie Zugangsdaten übertragen werden, wie Updates bereitgestellt werden und wer auf Vorfälle reagiert.

Ein Produktions-Endpunkt benötigt in der Regel folgende Elemente:

• eine stabile Adresse sowie einen unterstützten Übertragungsmechanismus
• TLS sowie sicheren Netzwerkzugang
• Timeout-Werte, die sich vorhersagbar verhalten
• Protokolle für jede Anfrage sowie zusammenfassende Nutzungsanalysen
• einen Plan für Verzögerungen und Ausfälle in der Vorverarbeitung
• ein Versionierungssystem sowie einen Weg zur Rücksetzung
• einen benannten Verantwortlichen im Team

Lokalen MCP-Servern eignen sie sich für die Entwicklung oder persönliche Arbeitsabläufe. Ein SaaS-Produkt, das Funktionen an Nutzer oder Kunden bereitstellt, wird in der Regel besser durch einen gehosteten, entfernten Endpunkt bedient. Der Deployment-Stil ist Teil der Bereitstellungsfähigkeit, weshalb er sorgfältig ausgewählt werden sollte. Ein Team, das ein lokales stdio-Verhalten benötigt, sollte eine selbst verwaltete Einrichtung wählen. Ein Team, das lieber einen gehosteten Streamable-HTTP-Endpunkt um eine bestehende API-Definition herum haben möchte, kann die MCP-Hosting- und Infrastrukturkomponenten einer verwalteten Plattform überlassen, während die ursprüngliche API weiterhin ihre Funktion erfüllt.

Observability zeigt an, ob es funktioniert

Nach dem Start bleibt die Bereitschaft eine anhaltende Frage. Das Team sollte in der Lage sein zu beurteilen, welche Tools am häufigsten genutzt werden und welche am häufigsten versagen, ob Authentifizierungsfehler bestimmten Workflows zugeordnet werden können, ob die Latenz akzeptabel ist, ob Kunden aufgrund verwirrender Benutzeroberflächen zusätzliche Anfragen senden, ob die Antworten unerwartet groß sind, ob veraltete Funktionen weiterhin genutzt werden und ob eine API-Änderung ein Tool beeinträchtigt hat.

Logs helfen dabei, einzelne Anfragen zu debuggen, während Analysen Muster aufzeigen. Ein Tool mit hohem Fehleranteil weist möglicherweise fehlerhafte Schemata, Beschreibungen, Authentifizierungsanforderungen oder Upstream-Endpunkte auf. Wenn viele ähnliche Tools nur selten aufgerufen werden, könnte die Funktionsvielfalt zu überwältigend sein. Zusammen zeigen diese Anzeichen, ob die MCP-Benutzeroberfläche mit der tatsächlichen Arbeitsweise der Nutzer übereinstimmt.

Versionierung schützt Agent-Workflows

APIs entwickeln sich ständig weiter. Neue Felder entstehen, Enums ändern sich, die Struktur der Antworten variiert, alte Operationen werden veraltet und die Authentifizierungsregeln werden strenger. All das kann die MCP-Schicht beeinflussen, weshalb bereits vor dem ersten Produktivstart ein Versionierungssystem vorhanden sein sollte. Dieses muss folgende Fragen beantworten:

• wie man feststellt, welche MCP-Tools von einem geänderten Endpunkt abhängen
• wie man aktualisierte Schemata vor ihrer Veröffentlichung testet
• wie man ein Tool umbenennen oder aus dem Einsatz nehmen kann, ohne die Kunden zu überraschen
• wie man zu einer früheren Konfiguration zurückkehrt, wenn etwas nicht funktioniert
• wie man Änderungen an den API-Versionen von Änderungen in der MCP-Präsentation trennt

Die MCP-Konfiguration ist kein einmaliges Dokument. Sie gehört zum Lebenszyklus des Produkts. Nützliche Plattformen unterstützen Konfigurationsversionen, die Überprüfung von Änderungen, das Wiederherstellen älterer Versionen sowie das Aktualisieren eines gehosteten Servers, ohne dass die URL sich ändert.

Checkliste zur Vorbereitung

Bevor eine bestehende API zu einem MCP-Server für Agenten wird, ist es hilfreich, in den folgenden Bereichen Antworten zu haben.

Dokumentation:

• Es liegt eine unterstützte OpenAPI-, Swagger- oder Postman-Definition vor.
• Mitarbeiter außerhalb des Engineering-Teams können sich an den Operationsnamen, Zusammenfassungen und Beschreibungen orientieren.
• Veraltete, interne, admin-relevante sowie risikoreiche Operationen sind klar gekennzeichnet.
• Statuscodes, Fehler, Paginierung, Filter und Rate Limits sind dokumentiert.

Schemata:

• Jedes Feld ist korrekt als erforderlich oder optional markiert.
• Feldtypen, Formate, Enum-Werte, Arrays und verschachtelte Objekte lassen keinen Zweifel zu.
• Anfrageschemata und Antwort-Schemata spiegeln das tatsächliche Verhalten der API wider.
• Die wichtigen Ergebnisfelder sind ausreichend beschrieben, damit der Agent fortfahren kann.

Authentifizierung:

• Das Verhalten von API-Schlüsseln,Bearer-Tokens oder OAuth ist dokumentiert.
• Keine Anmeldeinformationen erscheinen unter den Eingaben, die das Modell sehen kann.
• Die übergeordnete API selbst setzt Regeln für Tenant, Benutzer, Rolle, Datensatz und Aktion durch.
• Jeder Fall wurde getestet: gültige Anmeldeinformationen, fehlende Anmeldeinformationen, abgelaufene Anmeldeinformationen sowie solche ohne ausreichende Berechtigungen.

Endpunktauswahl:

• Der erste Server ist um ein oder zwei konkrete Benutzerworkflows organisiert.
• Nur die nützlichen Operationen werden bereitgestellt.
• Lese- und Schreiboperationen werden auf verschiedenen Ebenen überprüft.
• Destruktive, batchbasierte, admin-relevante sowie umfangreiche Exportoperationen bleiben außen vor, es sei denn, es besteht ein echter Bedarf.
• Die Formulierung von Namen und Beschreibungen ermöglicht es dem Client, ähnliche Funktionen voneinander zu unterscheiden.

Testing:

• Ein Client kann sich verbinden und auflisten, was verfügbar ist.

Es wurden gültige Eingaben, fehlerhafte Eingaben, leere Ergebnisse, fehlende Datensätze sowie Fehler in der Vorverarbeitung getestet.

Eine fehlgeschlagene Authentifizierung oder Autorisierung liefert eine für die Nutzer verständliche Nachricht.

Die zurückgegebenen Informationen helfen bei dem nächsten Schritt im Workflow.

Die gehostete Schnittstelle wurde vor der Produktivnutzung getestet.

Hosting und Betrieb:

• Das Team wählte bewusst eine lokale, selbst verwaltete oder gehostete Remote-Deployment-Lösung.
• Endpunkte, Übertragungsmethoden, Anmeldeinformationen, Protokolle, Analysen sowie die Verantwortlichkeiten sind alle definiert.
• Jemand kann Latenzzeiten, Fehlerraten, Nutzungsmuster sowie die verwendeten Clients überprüfen.
• Konfigurationsänderungen werden versioniert und können rückgängig gemacht werden.

Mehrere schwache Aspekte machen die API zwar nicht wertlos, erfordern aber zusätzliche Arbeit, bevor sie als Schnittstelle für Agenten genutzt werden kann.

Ein typischer verwalteter Weg

Die verwalteten Plattformen richten sich an SaaS-Teams, die bereits eine API-Definition haben und eine MCP-Route ohne Betrieb der vollständigen Infrastruktur wünschen. Der übliche Ablauf ist wie folgt:

1. Importieren Sie eine unterstützte Swagger-, OpenAPI- oder Postman-Definition.
2. Lassen Sie die Plattform die verfügbaren Operationen erkennen.
3. Prüfen Sie alle Validierungswarnungen oder Fehler.
4. Wählen Sie die Operationen aus, die zu Funktionen für KI werden sollen.
5. Erstellen oder bearbeiten Sie Tools, Ressourcen und Anfragen.
6. Feinjustieren Sie Namen und Beschreibungen.
7. Verwenden Sie einen Laufzeit-Übertragungsweg für API-Schlüssel, Token oder OAuth-Zertifikate.
8. Testen Sie den gehosteten Server in einer Testumgebung.
9. Überwachen Sie nach dem Start Protokolle und Analysen.
10. Verwalten Sie Konfigurationsversionen, während sich die API weiterentwickelt.

Die API und ihr Team behalten weiterhin die Logik unter Kontrolle: Geschäftsregeln, Autorisierung, Paginierung, Rate Limits, Datenvalidierung sowie das Verhalten der Produkte. Eine Plattform fügt lediglich die gehostete MCP-Schicht darauf auf, was die Umwandlung unterstützter Definitionen, die Auswahl von Operationen, die Konfiguration von Tools, die Bereitstellung von Streamable HTTP, Tests, Logging, Analytics sowie Versionskontrolle beinhaltet.

Die letzte Überprüfung: Kein Raten

Eine bestehende API ist agentbereit, sobald der Agent ohne Raten über die Produktinterface arbeiten kann. Das bedeutet, dass nicht geraten werden muss, welcher Endpunkt zu einer Anfrage passt, welche Felder benötigt werden, ob eine Operation sicher ist, wie die Authentifizierung funktioniert oder was ein Ergebnis bedeutet. Perfektion ist nicht erforderlich, doch der Weg von der Absicht des Benutzers bis zu einem autorisierten Toolaufruf muss klar genug sein, um getestet werden zu können.

Nine Elemente bilden einen praktikablen Standard: klare Dokumentation, genaue Schemata, explizite Authentifizierung, bewusst ausgewählte Endpunkte, fokussierte Toolbeschreibungen, Tests, die der Realität entsprechen, zuverlässige Hosting-Lösungen, beobachtbares Nutzungsverhalten sowie ein Plan für Änderungen. Sobald diese vorhanden sind, kann MCP eine bestehende API in eine Schnittstelle umhüllen, die von Agenten genutzt werden kann. Ohne sie kann die Integration zwar auf technischer Ebene funktionieren, wobei der Agent den fehlenden Kontext ausgleichen muss – ohne jedoch eine sorgfältig gestaltete Funktionsoberfläche, auf die man sich verlassen kann.