Ihr ERP soll für KI-Agenten erreichbar sein. Aber über welchen Kanal? Das Model Context Protocol verspricht agentennativen Zugriff, eine REST-API ist der bewährte Standard, und ein CLI-Wrapper lässt sich in einer Stunde bauen. Dieser Vergleich zeigt, wann welcher Konnektor der richtige ist — und warum die Antwort fast immer „alle drei, aber in verschiedenen Rollen" lautet.
Dieser Artikel ist ein vertiefender Fachbeitrag aus unserem Content-Cluster. Entdecken Sie die vollständige Übersicht auf unserer Hauptseite:KI & Automatisierung für den Mittelstand →
Drei Protokolle, ein Ziel: KI auf Firmendaten
2026 ist das Jahr, in dem KI-Agenten nicht mehr nur antworten, sondern handeln. Doch bevor ein Agent eine Rechnung im ERP anlegen oder ein Ticket schließen kann, braucht er einen Konnektor. MCP, REST-API und CLI sind die drei Kandidaten — und jeder hat seine Domäne.
- MCP (Model Context Protocol): Agentennatives Protokoll mit bidirektionalem Tool-Zugriff, feingranularer Rechtesteuerung und integriertem Audit-Trail — ideal für Echtzeit-Interaktion zwischen LLM und Unternehmensystemen.
- REST-API: Der bewährte Standard für systemübergreifende CRUD-Operationen mit dem breitesten Ökosystem, der besten Dokumentationslage und universeller Tooling-Unterstützung.
- CLI-Konnektor: Der schnellste Weg, ein bestehendes System für Agenten erreichbar zu machen — über stdio als MCP-Transport, als Batch-Prozessor oder als Scripting-Brücke.
- Was sind MCP, API und CLI?
- Anatomie eines Konnektors: Schema, Authentifizierung, State
- MCP im Detail: Die agentennative Schicht
- REST-API im Detail: Der universelle Standard
- CLI im Detail: Der unterschätzte Dritte
- Vergleichsmatrix: 8 Entscheidungskriterien
- Entscheidungsbaum: Wann welcher Konnektor?
- Hybrid-Architekturen: MCP als Orchestrator
- Praxisbeispiel: Ein Mittelständler öffnet sein ERP
- Sicherheit und Compliance
- Fazit und Handlungsempfehlung
1. Was sind MCP, API und CLI?
Bevor ein KI-Agent eine Rechnung im ERP anlegen, ein Support-Ticket schließen oder einen Lagerbestand prüfen kann, braucht er einen definierten Kanal in das Zielsystem. Drei Konnektortypen dominieren 2026 die Landschaft — und jeder löst das Problem auf einer anderen Protokollebene.
MCP — Model Context Protocol
Ein von Anthropic initiiertes, offenes JSON-RPC-2.0-Protokoll, das speziell dafür entworfen wurde, KI-Modellen den Zugriff auf Werkzeuge (Tools), Datenquellen (Resources) und Kontext-Prompts bereitzustellen. Es definiert eine standardisierte Server-Client-Architektur mit integriertem Rechtemodell.
REST-API — Representational State Transfer
Der seit über zwei Jahrzehnten bewährte Architekturstil für Webschnittstellen. Eine REST-API exponiert Ressourcen über HTTP-Verben (GET, POST, PUT, DELETE), nutzt JSON als Datenformat und wird typischerweise über OpenAPI 3.1-Spezifikationen maschinenlesbar beschrieben.
CLI — Command-Line Interface
Ein textbasiertes Programm, das über Terminal-Befehle gesteuert wird und seine Ein-/Ausgabe über Standard-Streams (stdin/stdout/stderr) abwickelt. CLI-Tools folgen POSIX-Konventionen, lassen sich in Shell-Skripte einbetten und dienen als stdio-Transport für MCP-Server.
Die entscheidende Erkenntnis vorweg: Diese drei Konnektortypen sind keine Konkurrenten, sondern komplementäre Schichten. Ein MCP-Server ruft intern häufig REST-APIs auf, und sein Prozess wird oft als CLI-Binary gestartet. Wer die drei Ebenen versteht, baut bessere Integrationsarchitekturen.
2. Anatomie eines Konnektors: Schema, Authentifizierung, State
Jeder Konnektor muss drei Grundfragen beantworten: Was kann ich? (Schema), Wer darf mich nutzen? (Authentifizierung) und Merke ich mir etwas zwischen zwei Aufrufen? (Statefulness). Die Unterschiede in diesen drei Dimensionen bestimmen, welcher Konnektor zu welchem Einsatzszenario passt.
Vergleich: Schema, Auth & State
- MCP: Tool-Definitionen mit JSON Schema als Eingabeparameter. Das Modell sieht Name, Beschreibung und erwartete Parameter jedes Werkzeugs.
- API: OpenAPI 3.1 mit vollständigen Pfad-, Parameter- und Response-Definitionen. Maschinenlesbar, aber auf HTTP-Semantik beschränkt.
- CLI:
--help-Ausgabe, Manpages oder informelles README. Keine standardisierte maschinenlesbare Beschreibung.
- MCP: OAuth 2.1 (seit Spec-Revision März 2026), Scoped Tokens, Session-basiert — der Server kann Kontext zwischen Aufrufen halten.
- API: API-Keys, OAuth 2.0, JWT — jeder Request ist prinzipiell zustandslos (RESTful), Sessions nur über Token-Binding.
- CLI: Umgebungsvariablen, Konfigurationsdateien, SSH-Keys — Auth ist prozesslokal, State nur über Dateisystem oder Datenbank.
Experten-Tipp: Schema-First denken
Egal welchen Konnektor Sie wählen: Beginnen Sie immer mit der maschinenlesbaren Schnittstellenbeschreibung. Ein KI-Agent kann nur so autonom arbeiten, wie seine Tool-Definitionen präzise sind. OpenAPI-Specs und MCP-Tool-Schemas sind nicht „nette Dokumentation" — sie sind die Bedienungsanleitung für das Modell.
3. MCP im Detail: Die agentennative Schicht
Das Model Context Protocol wurde 2024 von Anthropic als Open-Source-Standard veröffentlicht und hat sich 2026 zum De-facto-Protokoll für die Kommunikation zwischen KI-Agenten und externen Systemen entwickelt. Google, Microsoft und OpenAI unterstützen das Protokoll mittlerweile. Die Architektur besteht aus drei Rollen:
MCP-Host
Die Anwendung, in der das Sprachmodell läuft — eine Chat-Oberfläche wie Claude Desktop, eine IDE wie Cursor oder AntiGravity, oder ein Agenten-Framework wie LangGraph. Der Host entscheidet, welche Server verbunden werden und wann ein Tool-Aufruf ausgeführt wird.
MCP-Client
Eine 1:1-Verbindung zwischen Host und einem einzelnen Server. Der Client handelt die Capabilities aus (tools/list, resources/list), leitet Tool-Aufrufe weiter und empfängt Ergebnisse. Er isoliert den Sicherheitskontext pro Server.
MCP-Server
Der Dienst, der interne Systeme (ERP, CRM, DMS, Datenbank) als Tools, Resources und Prompts über das Protokoll exponiert. Er erzwingt Zugriffsrechte, validiert Eingaben und protokolliert jeden Aufruf im Audit-Trail. Details dazu in unserem Deep Dive: MCP-Server auf Firmendaten.
Was MCP fundamental von einer REST-API unterscheidet, ist die Bidirektionalität: Der Server kann dem Client aktiv Benachrichtigungen senden (z. B. wenn sich eine Ressource ändert), und das Modell kann in einer laufenden Session Kontext zwischen mehreren Tool-Aufrufen akkumulieren. Eine REST-API kennt dieses Muster nicht nativ — dort muss der Client pollen oder Webhooks konfigurieren.
Das zweite Alleinstellungsmerkmal ist die Drei-Primitiven-Architektur: Tools (ausführbare Aktionen), Resources (lesbare Datenquellen) und Prompts (vorgefertigte Kontext-Templates) bilden ein Vokabular, das Agenten-Frameworks direkt verstehen. Eine REST-API liefert rohe Endpunkte; die semantische Einordnung (ist das eine Aktion oder eine Leseabfrage?) muss der Agent selbst vornehmen.
4. REST-API im Detail: Der universelle Standard
REST-APIs sind seit über zwanzig Jahren der Standard für Systemintegration im Web. Ihre Stärken liegen in der Universalität, der ausgereiften Toolchain und der breiten Akzeptanz. Jedes moderne ERP, jedes CRM und jedes SaaS-Produkt bietet eine REST-API — oft mit einer OpenAPI-3.1-Spezifikation, die maschinelles Konsumieren erlaubt.
Für KI-Agenten sind REST-APIs besonders in folgenden vier Szenarien die überlegene Wahl:
Stabile, versionierte API
Das Zielsystem verfügt bereits über eine produktionsreife Schnittstelle (z. B. DATEV, Shopify, HubSpot) mit klarer Dokumentation und Versionsgarantie.
Standardisierte CRUD-Operationen
Klassisches Lesen, Erstellen, Aktualisieren und Löschen von Datensätzen reicht für den angestrebten Geschäftsprozess vollständig aus.
Systemübergreifende Integration
Die Integration verbindet heterogene Drittsysteme und Cloud-Dienste, die allesamt standardmäßig über HTTPS kommunizieren.
Infrastruktur bereits etabliert
Rate Limiting, Pagination, Request-Throttling und Caching sind bereits robust auf API-Gateway-Ebene implementiert und erprobt.
Unser Artikel zur autonomen API-Integration via OpenAPI zeigt, wie KI-Agenten OpenAPI-Spezifikationen zur Laufzeit parsen, Endpunkte dynamisch verknüpfen und bei API-Änderungen ihre Payloads selbstständig korrigieren (Self-Healing). Das Muster „Agent + OpenAPI-Spec = autonomer API-Zugriff” ist der direkteste Weg, bestehende Systeme für KI zu öffnen.
Die Grenzen einer REST-API zeigen sich, sobald der Agent mehr als Datenzugriff braucht: Konversationeller Kontext über mehrere Aufrufe, dynamische Capability-Discovery (welche Endpunkte gibt es überhaupt?) und feingranulare, nutzerbezogene Berechtigungen sind zwar technisch möglich, erfordern aber zusätzliche Infrastruktur. Genau dort setzt MCP an.
5. CLI im Detail: Der unterschätzte Dritte
CLI-Konnektoren werden in Architektur-Diskussionen oft übersehen — zu Unrecht. In der Praxis sind sie der schnellste Weg, ein bestehendes System für KI-Agenten erreichbar zu machen, und sie spielen eine Schlüsselrolle als Transportschicht für MCP-Server.
1. stdio als MCP-Transport
Der stdio-Transport ist der Standard-Startmodus für lokale MCP-Server: Der Host startet das CLI-Binary als Kindprozess und kommuniziert über stdin/stdout. Kein HTTP-Server, kein Port-Konfig — der Agent spricht direkt mit dem Prozess.
2. Shell-Scripting & Pipes
CLI-Tools lassen sich über Pipes (|) komponieren: datev-cli export --month=09 | jq '.items[]' | wc -l. Für Agenten, die agentische Workflows steuern, ist das ein mächtiges Kompositionsmuster, das keine API-Registrierung erfordert.
3. Batch- & Cron-Aufgaben
Für geplante Aufgaben (nächtlicher Datenabgleich, wöchentlicher Report) ist ein CLI-Aufruf per Cron oder systemd-Timer oft einfacher und robuster als ein dauerhaft laufender API-Server.
4. Rapid Prototyping
Ein CLI-Wrapper um ein bestehendes Python-Skript ist in einer Stunde gebaut. Für den Proof-of-Concept, ob ein KI-Agent mit einem internen System arbeiten kann, ist das oft der Einstieg, bevor ein vollwertiger MCP-Server entwickelt wird.
5. Sandbox & Isolation
CLI-Prozesse lassen sich über Container, chroot oder Seccomp-Profile isolieren. Für sicherheitskritische Operationen kann der Agent einen CLI-Aufruf in einer Sandbox ausführen, deren Blast Radius klar begrenzt ist.
Die Schwächen eines reinen CLI-Konnektors liegen in der fehlenden standardisierten Schema-Beschreibung (kein Äquivalent zu OpenAPI oder MCP-Tool-Definitionen), der begrenzten Fehlerbehandlung (Exit Codes vs. strukturierte Fehlerobjekte) und der fehlenden Bidirektionalität. Ein CLI-Aufruf ist immer eine Einbahnstraße: Befehl rein, Ergebnis raus, fertig.
6. Vergleichsmatrix: 8 Entscheidungskriterien
Die folgende Matrix verdichtet die Unterschiede in den acht Dimensionen, die für die Konnektor-Wahl im Mittelstand entscheidend sind:
1. Echtzeit-Kontext & Bidirektionalität
MCP: Vollständig bidirektional — Server kann Notifications senden, Client hält Session-Kontext. API: Unidirektional (Request/Response), Webhooks als Workaround. CLI: Unidirektional (Befehl → Ausgabe), kein Session-Konzept.
2. Auth-Granularität & Least Privilege
MCP: OAuth 2.1 mit Scoped Tokens pro Tool und Nutzer. API: OAuth 2.0 / API-Keys — Scoping auf Endpunkt-Ebene, nicht auf Feld-Ebene. CLI: Prozess-Berechtigungen des ausführenden Users — grobgranular.
3. Tooling & Ökosystem-Breite
MCP: Wachsend — tausende Community-Server, SDKs für TypeScript, Python, Java, C#. API: Maximal — Postman, Swagger, OpenAPI Generator, jedes HTTP-Tool. CLI: Universal — jede Shell, jedes Betriebssystem.
4. Deployment-Aufwand & Time to Market
MCP: Mittel — Server-Entwicklung nötig, aber SDKs beschleunigen massiv. API: Variabel — existierende API nutzen: schnell; neue bauen: Wochen bis Monate. CLI: Minimal — ein Python-Skript mit argparse ist in einer Stunde ein Konnektor.
5. Agenten-Ökosystem & Nativität
MCP: Nativ unterstützt von Claude, Gemini, GPT-4o und führenden Agenten-Frameworks. API: Erfordert Dynamic Tool Calling via OpenAPI-Parsing. CLI: Braucht Prozess-Wrapper (häufig: MCP-Server mit stdio-Transport).
6. Debugging & Monitoring
MCP: MCP Inspector für interaktives Tool-Tracing und Session-Prüfung. API: Maximal ausgereift — Postman, cURL, Browser-DevTools, APM-Suiten. CLI: Logging auf stderr und Exit-Codes.
7. Vendor-Unabhängigkeit
MCP: Offener Standard (MIT-Lizenz) mit breiter Community. API: Per Definition herstellerunabhängig nach W3C/IETF-Standards. CLI: Gebunden an das jeweilige Binary und Betriebssystem.
8. Kostentransparenz & TCO
MCP: Eigene Server-Infrastruktur oder lokaler Prozess — kalkulierbare Fixkosten. API: Oft volumen- oder call-basierte Lizenzmodelle (z. B. DATEV nach Buchungsstapeln). CLI: Nur lokale Compute-Ressourcen.
7. Entscheidungsbaum: Wann welcher Konnektor?
Die Wahl des richtigen Konnektors ist keine technische Grundsatzentscheidung, sondern eine Frage des konkreten Einsatzszenarios. Der folgende Entscheidungsbaum führt in vier Schritten zum richtigen Ansatz:
Braucht der Agent Echtzeit-Kontext zwischen Aufrufen?
Ja → MCP-Server. Das Session-basierte Protokoll hält Kontext über mehrere Tool-Aufrufe. Ein KI-Agent, der eine Bestellung prüft, den Lagerbestand abfragt und dann eine Rechnung erstellt, braucht Kontext zwischen diesen Schritten.
Nein → Weiter zu Schritt 02.
Existiert bereits eine stabile, dokumentierte API?
Ja → REST-API direkt nutzen. Warum eine zusätzliche Schicht bauen, wenn der Agent die API über eine OpenAPI-Spec autonom ansprechen kann? (Siehe Autonome API-Integration.)
Nein → Weiter zu Schritt 03.
Ist es ein einmaliger Batch-Job oder ein wiederkehrender Prozess?
Batch/Einmalig → CLI-Konnektor. Ein Shell-Skript oder Python-CLI, das der Agent über subprocess oder als MCP-Tool via stdio aufruft, reicht völlig.
Wiederkehrend & komplex → Weiter zu Schritt 04.
Braucht der Agent feingranulare Rechtesteuerung pro Nutzer?
Ja → MCP-Server mit OAuth 2.1 und Scoped Tokens. Der Server erzwingt die Rechte des aufrufenden Nutzers auf Tool-Ebene.
Nein → REST-API mit Standard-OAuth oder API-Key.
Experten-Tipp: Der CLI-zu-MCP-Upgrade-Pfad
Starten Sie mit einem CLI-Konnektor für den Proof-of-Concept. Wenn der Agent produktiv wird, wickeln Sie das CLI-Binary als MCP-Server mit stdio-Transport ein. Das dauert mit dem MCP TypeScript SDK weniger als einen Tag — und Sie gewinnen Schema-Discovery, Auth und Audit-Trail, ohne den Kern-Code zu ändern.
8. Hybrid-Architekturen: MCP als Orchestrator
In der Praxis ist die Antwort auf „MCP, API oder CLI?” fast immer: alle drei — aber in verschiedenen Rollen. Die am häufigsten anzutreffende Architektur sieht so aus:
MCP-Server als Frontend zum Agenten
Der MCP-Server definiert die Tools, die der KI-Agent sehen und aufrufen darf. Er übernimmt Schema-Beschreibung, Rechteprüfung und Audit-Logging. Der Agent kommuniziert ausschließlich über MCP — er sieht weder die darunterliegenden APIs noch die CLI-Aufrufe.
REST-APIs als Backend-Integration
Innerhalb des MCP-Servers rufen die Tool-Handler die REST-APIs der Zielsysteme auf: DATEV Buchungsdatenservice, Shopify Admin API, HubSpot CRM API. Die API-Komplexität (Pagination, Rate Limiting, Retry-Logik) wird vom Server gekapselt — der Agent bekommt ein sauberes Ergebnis.
CLI-Tools für Dateisystem & Batch
Für lokale Operationen (PDF-Generierung, CSV-Export, Datei-Konvertierung) ruft der MCP-Server CLI-Tools als Subprozesse auf. Das ist robuster als eine API für Operationen, die auf dem Dateisystem des Servers stattfinden.
n8n & iPaaS als Workflow-Kleber
Für komplexe Multi-System-Workflows (ERP → CRM → E-Mail → Buchhaltung) bleibt n8n als iPaaS-Middleware relevant. Der MCP-Server kann einen n8n-Workflow als Tool exponieren — das Beste aus beiden Welten.
Diese Architektur ist kein theoretisches Konstrukt. Unser MCP-Server-Artikel beschreibt genau dieses Muster in der Praxis: Ein MCP-Server, der das ERP über dessen REST-API anspricht, PDFs über ein CLI-Tool generiert und den Audit-Trail in eine lokale Datenbank schreibt.
9. Praxisbeispiel: Ein Mittelständler öffnet sein ERP
Ein mittelständischer Maschinenbauer (120 Mitarbeiter, SAP Business One als ERP, DATEV für die Buchhaltung) will seinen Vertriebsmitarbeitern einen KI-Assistenten bereitstellen, der Kundenanfragen beantwortet, Angebote erstellt und Lieferzeiten prüft. So entscheiden die drei Konnektoren über die Architektur:
CLI-Konnektor. Ein Python-Skript liest die SAP-Artikelstammdaten über die SAP Service Layer REST-API und gibt sie als JSON auf stdout aus. Der Agent ruft das Skript als MCP-Tool via stdio auf. Aufwand: 2 Tage Entwicklung, keine Infrastruktur.
MCP-Server. Das CLI-Skript wird zum vollwertigen MCP-Server mit TypeScript SDK erweitert. Drei Tools entstehen: lookup_article, create_quote, check_delivery_time. Jedes Tool hat sein eigenes Scoped Token — der Vertrieb darf Angebote erstellen, das Marketing nur Artikel nachschlagen.
REST-API. Der MCP-Server bekommt ein viertes Tool: export_invoice_to_datev. Es ruft intern die DATEV Buchungsdatenservice API auf. Der Agent sieht nur das MCP-Tool — die DATEV-API-Komplexität (Stapelformat, Belegbilder, GoBD-Sequenznummern) bleibt gekapselt.
CLI-Tool. Für die PDF-Angebotsgenerierung ruft der MCP-Server ein wkhtmltopdf-CLI-Binary als Subprozess auf. Ein fünftes Tool generate_quote_pdf nimmt die Angebotsdaten entgegen, rendert ein HTML-Template und gibt den PDF-Pfad zurück.
Das Ergebnis: Vier Monate nach Projektstart hat der Maschinenbauer einen KI-Assistenten, der autonom Angebote erstellt, Lieferzeiten prüft, Rechnungen an DATEV übergibt und PDFs generiert — über einen einzigen MCP-Server, der intern REST-APIs und CLI-Tools orchestriert.
10. Sicherheit und Compliance
Jeder Konnektor öffnet einen Kanal in interne Systeme. Die Sicherheitsanforderungen unterscheiden sich je nach Typ fundamental:
Least Privilege auf Tool-Ebene
MCP-Server müssen nach dem Least-Privilege-Prinzip konfiguriert werden: Jedes Tool bekommt nur die Rechte, die es für seine spezifische Aufgabe braucht. Ein lookup_article-Tool darf lesen, aber nie schreiben. Das ist bei REST-APIs über Scopes möglich, bei CLI-Tools nur über Prozess-Isolation.
Prompt Injection über Datenquellen
Indirekte Prompt Injection ist das größte Sicherheitsrisiko aller drei Konnektoren: Ein Angreifer platziert eine Anweisung in einem Datenbankfeld, einer E-Mail oder einem PDF, die der Agent beim Lesen als Befehl interpretiert. MCP-Server brauchen deshalb Output-Sanitierung und Approval-Flows für schreibende Operationen.
Audit-Trail & Nachvollziehbarkeit
Für DSGVO- und NIS-2-Compliance muss jeder Zugriff auf personenbezogene Daten protokolliert werden. MCP-Server bieten das nativ. REST-APIs erfordern serverseitiges Access-Logging. CLI-Tools brauchen explizites Logging — ohne Wrapper geht jeder Aufruf verloren.
Transport-Verschlüsselung
MCP (SSE/HTTP): TLS 1.3 Pflicht. MCP (stdio): Prozess-lokal, kein Netzwerk. REST-API: HTTPS Standard. CLI: Kein Netzwerk bei lokaler Ausführung; bei Remote-Aufrufen SSH oder VPN erforderlich.
Experten-Tipp: Human-in-the-Loop als Sicherheitsnetz
Für schreibende Operationen (Rechnung anlegen, Bestellung auslösen, Kundendaten ändern) empfehlen wir grundsätzlich einen Human-in-the-Loop-Approval-Flow — unabhängig vom Konnektortyp. Der MCP-Server kann das über sampling-Requests an den Host implementieren, bei APIs über Webhook-basierte Freigabe-Workflows.
Fazit: Kein Entweder-oder, sondern ein Zusammenspiel
Die Frage „MCP, API oder CLI?" ist eine Scheinfrage. In der Praxis sind die drei Konnektortypen keine Konkurrenten, sondern komplementäre Schichten einer modernen Integrationsarchitektur:
MCP — Die Kontrollschicht
Definiert, was der Agent sehen und tun darf: Autorisierung, Scope-Prüfung, semantische Tool-Kataloge und lückenloser Audit-Trail.
REST-APIs — Die Datenschicht
Transportieren die Daten zwischen Systemen: Standardisierte CRUD-Operationen, Gateway-Policies, Caching und universelle HTTP-Konnektivität.
CLI-Tools — Die Ausführungsschicht
Erledigen lokale Operationen und dienen als schneller Einstieg: Lokale Scripts, Pipes, automatisierte Cron-Batches und schlanke stdio-Transports.
Wer ein KI-Projekt im Mittelstand plant, sollte nicht mit der Protokollwahl beginnen, sondern mit der Frage: Welche Geschäftsprozesse soll der Agent unterstützen? Daraus leitet sich ab, welche Systeme angebunden werden müssen, welche Rechte der Agent braucht und wie die Architektur aussieht.
Quick-Check: Ihre Konnektor-Strategie
Haben Sie Fragen zur Konnektor-Strategie für Ihre KI-Projekte?
Kostenlose Erstberatung vereinbarenOffizielle Quellen & Primärdokumentation
- Anthropic / Model Context Protocol (2024–2026): „Model Context Protocol Specification" – Die offizielle Protokollspezifikation mit JSON-RPC-2.0-Nachrichtenformat, Capability-Negotiation, Tool/Resource/Prompt-Primitiven und OAuth-2.1-Autorisierung.
- OpenAPI Initiative (2021–2026): „OpenAPI Specification v3.1.0" – Der internationale Standard zur maschinenlesbaren Beschreibung von REST-APIs, auf dem Dynamic Tool Calling und autonome API-Integration basieren.
- Google Chrome (2026): „Model Context Protocol for the Web (WebMCP)" – Die Browser-Seite des Protokolls: Wie Websites über
document.modelContextWerkzeuge für KI-Browser-Agenten bereitstellen. - IEEE / The Open Group (2017): „POSIX.1-2017 (IEEE Std 1003.1)" – Der Standard für CLI-Konventionen, Prozess-Management und stdio-Streams, auf dem CLI-basierte Konnektoren aufbauen.
Unsere Expertise vor Ort
Wir sind Ihr digitaler Partner – regional verankert und überregional erfolgreich.
Haben Sie eine Vision?
Lassen Sie uns gemeinsam prüfen, wie wir Ihre Idee zum Fliegen bringen.
Jetzt kostenloses Strategiegespräch buchenErweitertes Fachglossar
Model Context Protocol
Ein von Anthropic initiiertes, offenes Kommunikationsprotokoll (JSON-RPC 2.0), das KI-Modellen den standardisierten Zugriff auf externe Werkzeuge, Datenquellen und Prompts über eine einheitliche Server-Client-Architektur ermöglicht.
JSON-RPC 2.0
Ein leichtgewichtiges Remote-Procedure-Call-Protokoll, das Funktionsaufrufe als JSON-Objekte über beliebige Transportkanäle (HTTP, stdio, WebSocket) kodiert und die Grundlage des MCP-Nachrichtenformats bildet.
OpenAPI 3.1
Offener Standard zur maschinenlesbaren Schnittstellenbeschreibung von REST-APIs, der auf JSON Schema basiert und KI-Agenten die autonome Payload-Validierung und Funktionsgenerierung ermöglicht.
stdio Transport
Ein MCP-Transportkanal, bei dem die Kommunikation zwischen Host und Server über Standard-Input und Standard-Output (stdin/stdout) eines Kindprozesses erfolgt — ideal für lokale CLI-basierte MCP-Server.
Scoped Token
Ein Zugangstoken, dessen Gültigkeit auf einen eng umrissenen Satz an Berechtigungen, Ressourcen und eine kurze Lebensdauer beschränkt ist, um das Least-Privilege-Prinzip auf Konnektor-Ebene durchzusetzen.
Dynamic Tool Calling
Die Fähigkeit eines LLM-basierten Agenten, Funktionssignaturen und Schnittstellenbeschreibungen zur Laufzeit dynamisch zu instanziieren und auszuführen, anstatt auf statisch vorprogrammierte Konnektoren angewiesen zu sein.
