GPT Actions vs. MCP: technischer Vergleich

OpenAIs GPT Actions und Anthropics Model Context Protocol (MCP) lösen dasselbe grundlegende Problem: Ein KI-Modell kann während einer Konversation externe Tools und APIs aufrufen. Sie lösen es auf sehr unterschiedliche Weise.

Dieser Beitrag ist ein technischer Vergleich beider Ansätze. Er behandelt Architektur, Protokollmechanik, Authentifizierung, Tool Discovery und die Abwägungen, die bei der Entscheidung zwischen ihnen (oder beim Einsatz beider) relevant sind.

Was sind GPT Actions?

GPT Actions sind OpenAIs Mechanismus, mit dem Custom GPTs (und allgemeiner Assistenten, die über die OpenAI API gebaut werden) externe HTTP-APIs aufrufen können. Das Konzept wurde Ende 2023 mit dem GPT Store eingeführt und ging aus dem früheren ChatGPT Plugins-System hervor.

Die Grundidee: Du stellst eine OpenAPI-Spezifikation (Version 3.0 oder 3.1) bereit, die die Endpoints, Parameter und Antwortschemata deiner API beschreibt. OpenAIs System parst diese Spezifikation und stellt die Endpoints dem Modell als aufrufbare Tools bereit. Wenn das Modell entscheidet, eines davon aufzurufen, senden OpenAIs Server die HTTP-Anfrage im Namen des Nutzers.

Hier ist ein minimales OpenAPI-Schema, das eine einzelne Aktion zum Nachschlagen eines Kunden per E-Mail definiert:

openapi: "3.1.0"
info:
  title: "Customer Lookup API"
  version: "1.0.0"
servers:
  - url: "https://api.example.com"
paths:
  /customers/search:
    get:
      operationId: "searchCustomer"
      summary: "Nach einem Kunden per E-Mail suchen"
      parameters:
        - name: "email"
          in: "query"
          required: true
          schema:
            type: "string"
            format: "email"
          description: "Die E-Mail-Adresse des Kunden"
      responses:
        "200":
          description: "Kunde gefunden"
          content:
            application/json:
              schema:
                type: "object"
                properties:
                  id:
                    type: "string"
                  name:
                    type: "string"
                  email:
                    type: "string"
                  plan:
                    type: "string"

Du fügst dieses Schema in den GPT Builder ein oder lädst es hoch (oder referenzierst es per URL), konfigurierst die Authentifizierung, und der Custom GPT kann nun GET /customers/search?email=... aufrufen, sobald das Modell es für relevant hält. (Das Erstellen der Spezifikation ist der Teil, der automatisiert werden kann: Quickchat AI zum Beispiel generiert die entsprechende Aktion aus einer Ein-Satz-Beschreibung, basierend auf der Live-Dokumentation der API.)

Wichtige architektonische Eigenschaften von GPT Actions:

• Serverseitige Ausführung: OpenAIs Infrastruktur führt den ausgehenden HTTP-Aufruf aus. Deine API erhält die Anfrage aus OpenAIs IP-Bereich, nicht aus dem Browser des Endnutzers.
• OpenAPI als Schemaformat: Das Modell nutzt die Felder operationId, summary und description aus der OpenAPI-Spezifikation, um zu verstehen, wann und wie jeder Endpoint aufzurufen ist.
• Nur REST/HTTP: Actions sind auf Standard-HTTP-Methoden (GET, POST, PUT, DELETE, PATCH) über HTTPS beschränkt.
• Authentifizierungsoptionen: OAuth 2.0, API Key (als Header oder Query-Parameter gesendet) oder keine Authentifizierung. OpenAI übernimmt den OAuth-Token-Exchange-Flow im Namen des Nutzers.
• Statische Tool-Definitionen: Die Menge verfügbarer Aktionen wird zur Konfigurationszeit festgelegt. Das Modell kann zur Laufzeit keine neuen Endpoints entdecken.

Was ist MCP?

Model Context Protocol (MCP) ist ein offenes Protokoll, das Ende 2024 von Anthropic veröffentlicht wurde und standardisiert, wie KI-Anwendungen mit externen Tools und Datenquellen kommunizieren. Es ist nicht an ein bestimmtes Modell oder einen bestimmten Anbieter gebunden.

Wir haben einen vollständigen Leitfaden dazu geschrieben, wie MCP funktioniert, der das Protokoll von Grund auf erklärt. Die Kurzfassung: MCP definiert eine Client-Server-Architektur, bei der eine KI-Anwendung (der MCP-Client) eine Verbindung zu einem oder mehreren MCP-Servern herstellt, verfügbare Tools über eine tools/list-Anfrage entdeckt und sie über tools/call-Nachrichten aufruft. Die Kommunikation verwendet JSON-RPC 2.0.

Hier ist dasselbe Tool zur Kundensuche als MCP-Tool-Definition:

{
  "name": "search_customer",
  "description": "Nach einem Kunden per E-Mail-Adresse suchen",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email": {
        "type": "string",
        "description": "Die E-Mail-Adresse des Kunden"
      }
    },
    "required": ["email"]
  }
}

Diese Definition liegt in einem MCP-Server (einem kleinen Programm, das deine Geschäftslogik kapselt). Wenn ein MCP-Client eine tools/call-Anfrage mit name: "search_customer" und arguments: {"email": "user@example.com"} sendet, führt der Server den Code aus, der hinter diesem Tool liegt (einen API-Aufruf, eine Datenbankabfrage, einen Dateizugriff), und gibt das Ergebnis zurück. Wenn du einen AI Assistant statt roher Geschäftslogik bereitstellen möchtest, kannst du darauf verzichten, den Server selbst zu schreiben: Dein Quickchat AI Agent kann als MCP-Tool bereitgestellt werden, mit einer gehosteten URL.

Architekturvergleich

Die beiden Ansätze unterscheiden sich darin, wo Code ausgeführt wird, wie Kommunikation abläuft und welche Abstraktionen sie bereitstellen.

GPT Actions: zentralisiert, HTTP-nativ

User <-> ChatGPT (OpenAI servers) --HTTPS--> Your API server

Das Modell und der Action Executor befinden sich zusammen auf OpenAIs Seite. Wenn das Modell entscheidet, eine Aktion aufzurufen, erstellt OpenAIs Backend anhand der OpenAPI-Spezifikation eine HTTP-Anfrage, sendet sie an deine API, empfängt die Antwort und speist das Ergebnis zurück an das Modell. Der Client des Nutzers (Browser, mobile App) kommuniziert nie direkt mit deiner API.

Das bedeutet:

1. Deine API muss öffentlich über HTTPS erreichbar sein (oder zumindest von OpenAIs Infrastruktur aus erreichbar sein).
2. Die Latenz enthält einen Roundtrip von OpenAI zu deinem Server und zurück.
3. Alle Anfrage- und Antwortdaten laufen über OpenAIs Server.

MCP: dezentralisiert, protokollnativ

User <-> AI Application (MCP Client) <--JSON-RPC--> MCP Server <-> Your API / DB / service

Der MCP-Client läuft dort, wo die KI-Anwendung läuft. Bei Claude Desktop ist das auf dem Rechner des Nutzers. Bei einem cloudgehosteten AI Agent (wie Quickchat AI) läuft der MCP-Client im Backend des Agenten. Der MCP-Server kann lokal laufen (Kommunikation über stdio), im selben Netzwerk oder remote über HTTP mit Server-Sent Events (SSE) oder dem neueren Streamable HTTP-Transport.

Das bedeutet:

1. MCP-Server können auf lokale Ressourcen zugreifen (Dateien, Datenbanken, localhost-Dienste), die nicht im öffentlichen Internet verfügbar sind.
2. Die Kommunikation ist bidirektional. Server können Benachrichtigungen an Clients senden (z. B. wenn sich eine Ressource ändert).
3. Das Protokoll ist transportagnostisch. Es funktioniert über stdio-Pipes, SSE oder einfaches HTTP.

Vergleichstabelle

Technischer Deep Dive: eine Beispielintegration

Um die Unterschiede konkret zu machen, betrachten wir eine typische Aufgabe: Eine PostgreSQL-Datenbank wird nach Kundenbestellungen abgefragt, und die Ergebnisse werden an den Nutzer zurückgegeben.

GPT Actions-Ansatz

Du musst eine HTTP-API vor deiner Datenbank bauen und hosten:

# Flask API-Server (vereinfacht)
from flask import Flask, request, jsonify
import psycopg2

app = Flask(__name__)

@app.route("/orders", methods=["GET"])
def get_orders():
    customer_email = request.args.get("email")
    conn = psycopg2.connect("dbname=mydb user=myuser")
    cur = conn.cursor()
    cur.execute(
        "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
        (customer_email,)
    )
    rows = cur.fetchall()
    cur.close()
    conn.close()
    return jsonify([
        {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
        for r in rows
    ])

Dann schreibst du eine OpenAPI-Spezifikation für diesen Endpoint, stellst die API mit TLS bereit, konfigurierst die Authentifizierung und fügst die Spezifikation in den GPT Builder ein. OpenAI übernimmt den Rest: Es liest die Spezifikation, zeigt dem Modell die verfügbare Operation und führt bei Bedarf den HTTP-Aufruf aus.

Das gesamte Setup umfasst: einen laufenden API-Server, einen öffentlichen HTTPS-Endpoint, eine OpenAPI-Spezifikation und die GPT Action-Konfiguration in OpenAIs UI.

MCP-Ansatz

Du schreibst einen MCP-Server, der dieselbe Datenbankabfrage kapselt:

# MCP-Server mit dem mcp Python SDK
from mcp.server import Server
from mcp.types import Tool, TextContent
import psycopg2
import json

server = Server("orders-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_orders",
            description="Bestellungen für einen Kunden per E-Mail nachschlagen",
            inputSchema={
                "type": "object",
                "properties": {
                    "email": {
                        "type": "string",
                        "description": "E-Mail-Adresse des Kunden"
                    }
                },
                "required": ["email"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_orders":
        conn = psycopg2.connect("dbname=mydb user=myuser")
        cur = conn.cursor()
        cur.execute(
            "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
            (arguments["email"],)
        )
        rows = cur.fetchall()
        cur.close()
        conn.close()
        results = [
            {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
            for r in rows
        ]
        return [TextContent(type="text", text=json.dumps(results, indent=2))]

Wenn der MCP-Server lokal läuft (über stdio), kann er direkt eine Verbindung zu einer Datenbank auf localhost oder im lokalen Netzwerk herstellen. Kein öffentlicher Endpoint erforderlich. Wenn der Server remote läuft, benötigt er einen HTTP-Endpoint, kommuniziert aber über JSON-RPC über SSE oder Streamable HTTP statt über rohes REST.

Das gesamte Setup für die lokale Nutzung umfasst: das MCP-Server-Skript, die MCP-Client-Konfiguration (die auf den Befehl des Servers zeigt) und eine Datenbankverbindung. Keine OpenAPI-Spezifikation, kein TLS-Zertifikat, keine öffentlich zugängliche API.

Wichtige Unterschiede in der Praxis

Der GPT Actions-Pfad erfordert mehr Infrastruktur (einen bereitgestellten HTTP-Dienst), nutzt aber vorhandene REST-API-Muster, die den meisten Teams bereits vertraut sind. Wenn du bereits eine REST-API hast, besteht das Hinzufügen einer GPT Action hauptsächlich darin, die OpenAPI-Spezifikation zu schreiben.

Der MCP-Pfad erfordert für lokale Anwendungsfälle weniger Infrastruktur, führt aber ein neues Protokoll ein, das dein Team lernen muss. Für Remote-Deployments sind die Infrastrukturanforderungen ähnlich wie bei GPT Actions, aber das Kommunikationsmodell ist anders (persistente Verbindungen, JSON-RPC-Framing, bidirektionale Benachrichtigungen).

Wie Quickchat AI mit beiden Ansätzen umgeht

Das AI Actions-System von Quickchat AI unterstützt zwei unterschiedliche Aktionstypen, die diesen beiden Paradigmen entsprechen: HTTP Request Actions und Remote MCP Actions.

HTTP Request Actions

HTTP Request Actions sind konzeptionell ähnlich wie GPT Actions. Du konfigurierst einen HTTP-Endpoint, eine Methode, Headers, Query-Parameter und ein JSON-Body-Template. Der AI Agent sammelt Parameterwerte aus der Konversation, und das Quickchat-Backend führt die HTTP-Anfrage serverseitig aus.

Eine HTTP Request Action besteht aus:

• Einer Endpoint-URL mit {{parameter}}-Platzhaltern (z. B. https://api.hubapi.com/crm/v3/objects/contacts)
• Einer HTTP-Methode (GET, POST, PATCH, PUT, DELETE)
• Headers (einschließlich serverseitig eingesetzter Authorization Tokens)
• Einem JSON-Body-Template mit Parameterplatzhaltern
• Query-Parametern mit Platzhaltern
• Einer Menge typisierter Parameter (String, Number, Boolean, Float) mit Beschreibungen, Pflichtkennzeichnungen und Standardwerten

Zur Ausführungszeit bestimmt die KI anhand des Konversationskontexts, welche Parameter gefüllt werden. Das Backend fügt Parameterwerte in URL, Headers, Body und Query String ein und ersetzt {{param_name}}-Platzhalter. Anschließend führt es die HTTP-Anfrage aus und gibt die Antwort zur Interpretation an die KI zurück.

Ein detailliertes Beispiel findest du in unserem HubSpot AI Actions-Leitfaden.

Remote MCP Actions

Remote MCP Actions verbinden den AI Agent mit einem externen MCP-Server. Statt einzelne HTTP-Endpoints zu definieren, gibst du die URL des MCP-Servers und optionale Authentifizierungsdaten an (ein Bearer Token und/oder benutzerdefinierte Headers). Das Quickchat-Backend agiert als MCP-Client: Es verbindet sich mit dem Remote-Server, entdeckt verfügbare Tools über den standardmäßigen tools/list-Protokollaufruf und stellt sie dem KI-Modell bereit.

Die Konfiguration erfordert:

• Die MCP-Server-URL (ein HTTPS-Endpoint, der den MCP Streamable HTTP- oder SSE-Transport bereitstellt)
• Einen optionalen Authentifizierungstoken
• Optionale benutzerdefinierte Headers
• Eine Liste entdeckter Tools mit einzelnen Aktiv/Inaktiv-Schaltern
• Eine Standard-Tool-Aktivierungseinstellung (ob neu entdeckte Tools standardmäßig aktiv sind)

Nach dem Verbinden steht jedes vom MCP-Server bereitgestellte Tool dem AI Agent während Konversationen zur Verfügung. Die KI sieht die Tool-Namen und Beschreibungen aus der tools/list-Antwort des MCP-Servers und kann sie bei Bedarf aufrufen. Die Tool-Auswahl kann mit der allowed_tools-Konfiguration eingeschränkt werden, mit der du bestimmte Tools vom Server aktivieren oder deaktivieren kannst.

Dieser Ansatz ist besonders nützlich, wenn du Dienste integrierst, die bereits MCP-Server veröffentlichen (wie Shopifys MCP), weil du dich mit dem bestehenden Server verbinden kannst, statt einzelne HTTP-Aktionen für jeden Endpoint zu bauen.

Wann du welchen Ansatz in Quickchat verwenden solltest

Verwende HTTP Request Actions, wenn:

• Du mit einem bestimmten REST-API-Endpoint integrierst
• Du genaue Kontrolle über das Anfrageformat möchtest (Headers, Body-Struktur, Query Params)
• Die API keinen veröffentlichten MCP-Server hat
• Du serverseitige Credential-Injection benötigst (z. B. OAuth Tokens für HubSpot, Zendesk usw.)

Verwende Remote MCP Actions, wenn:

• Der Dienst einen MCP-Server veröffentlicht
• Du mehrere Tools aus einem einzelnen Dienst in einer Aktion verbinden möchtest
• Du dynamische Tool Discovery möchtest (die für die KI verfügbaren Tools können sich ändern, wenn der MCP-Server aktualisiert wird)
• Du ein Multi-Agent-System baust, in dem eine KI über MCP an eine andere delegiert

Vor- und Nachteile

GPT Actions

Vorteile:

• Vertraute Technologie. Wenn du eine bestehende REST-API hast, hast du bereits den größten Teil dessen, was du brauchst. Das Schreiben einer OpenAPI-Spezifikation ist gut dokumentiert, und das Tooling ist ausgereift.
• Das OpenAPI-Format ist weit verbreitet. Spezifikationen können aus vielen Webframeworks automatisch generiert werden (FastAPI, Express mit swagger-jsdoc, Spring Boot mit springdoc).
• OpenAI übernimmt die HTTP-Anfrageausführung, TLS-Terminierung und Fehlerbehandlung auf seiner Infrastruktur.
• OAuth 2.0-Unterstützung ist mit automatischer Token-Aktualisierung integriert.

Nachteile:

• An OpenAIs Ökosystem gebunden. Eine Aktion, die du für einen Custom GPT baust, kann ohne Neuimplementierung nicht mit Claude, Gemini oder einem anderen Modellanbieter wiederverwendet werden.
• Deine API muss öffentlich erreichbar sein. Keine Unterstützung für lokale Ressourcen oder Ressourcen in privaten Netzwerken.
• Keine dynamische Tool Discovery. Das Hinzufügen eines neuen Endpoints erfordert eine Aktualisierung der OpenAPI-Spezifikation und eine Neukonfiguration des GPT.
• Nur unidirektional. Deine API kann außerhalb von HTTP-Antworten keine Updates oder Benachrichtigungen an das Modell zurückschieben.
• Alle Daten laufen über OpenAIs Server, was bei sensiblen Workloads ein Problem sein kann.
• Rate Limits und Ausführungs-Timeouts werden von OpenAI kontrolliert, nicht von dir.

MCP

Vorteile:

• Anbieteragnostisch. Derselbe MCP-Server funktioniert mit Claude, Cursor, Quickchat AI und jedem anderen Client, der das Protokoll implementiert.
• Unterstützt lokale Ressourcen. Ein über stdio laufender MCP-Server kann auf Dateien, Datenbanken und Dienste auf dem lokalen Rechner zugreifen, ohne etwas im Internet freizugeben.
• Dynamische Tool Discovery. Die KI kann den Server zur Laufzeit nach verfügbaren Tools abfragen. Tools können hinzugefügt, entfernt oder aktualisiert werden, ohne den Client neu zu konfigurieren.
• Bidirektionale Kommunikation. Server können Clients über Änderungen informieren (z. B. eine Datei wurde geändert, ein neuer Datensatz wurde erstellt).
• Zustandsbehaftete Sitzungen. Die Verbindung bleibt über mehrere Tool-Aufrufe innerhalb einer Konversation bestehen und ermöglicht Workflows, die Kontext aus früheren Aufrufen benötigen.
• Offene Spezifikation. Jeder kann das Protokoll einsehen, implementieren oder erweitern.

Nachteile:

• Jüngeres Ökosystem. Das Protokoll wurde Ende 2024 veröffentlicht, daher befinden sich Tooling, Dokumentation und Community-Wissen im Vergleich zu OpenAPI noch in der Entwicklung.
• Erfordert den Betrieb eines MCP-Servers. Bei Remote-Deployments bedeutet das, einen zusätzlichen Dienst zu hosten (auch wenn er leichtgewichtig sein kann).
• Keine standardisierte Authentifizierungsspezifikation (Stand Anfang 2026). Implementierungen variieren zwischen tokenbasierter Authentifizierung, benutzerdefinierten Headers und OAuth-Erweiterungen. Die MCP Authorization-Spezifikation entwickelt sich noch.
• Das JSON-RPC-Framing fügt eine Abstraktionsschicht hinzu, die Teams, die REST gewohnt sind, ungewohnt vorkommen kann.
• Die Client-Unterstützung variiert. Nicht alle KI-Anwendungen unterstützen alle MCP-Transports oder Features.

Wann du welchen Ansatz verwenden solltest

Die Wahl hängt von deinen Einschränkungen ab:

Wähle GPT Actions, wenn:

• Du ausschließlich für ChatGPT oder die OpenAI API baust.
• Du bereits eine öffentliche REST-API mit einer OpenAPI-Spezifikation hast.
• OAuth 2.0 von der Plattform für dich übernommen werden soll.
• Du den einfachsten Weg von „bestehende API“ zu „von KI aufrufbares Tool“ suchst.

Wähle MCP, wenn:

• Deine Tools mit mehreren KI-Anbietern funktionieren müssen.
• Du lokale Ressourcen oder Ressourcen in privaten Netzwerken einer KI zugänglich machen möchtest, ohne sie öffentlich zu machen.
• Du dynamische Tool Discovery, bidirektionale Kommunikation oder zustandsbehaftete Sitzungen benötigst.
• Du eine Multi-Agent-Architektur baust, in der verschiedene KI-Systeme koordinieren müssen.

Verwende beides, wenn:

• Du eine bestehende REST-API hast, die du als GPT Action für ChatGPT-Nutzer bereitstellen möchtest, aber zusätzlich einen MCP-Server für Claude, Cursor und andere Clients veröffentlichen willst. Die zugrunde liegende Geschäftslogik kann gemeinsam genutzt werden. Der Protokolladapter ist eine dünne Schicht darüber.

Der Konvergenztrend

GPT Actions und MCP sind aus unterschiedlichen Designphilosophien entstanden (HTTP-nativ vs. protokollnativ), aber die Lücke wird kleiner.

OpenAI fügte im März 2025 MCP-Unterstützung zum Agents SDK hinzu, wodurch OpenAI-basierte Agenten neben traditionellem Function Calling eine Verbindung zu MCP-Servern herstellen können. Das ersetzt GPT Actions nicht (sie bleiben der Weg, um Tool Calling zu Custom GPTs in ChatGPT hinzuzufügen), zeigt aber, dass OpenAI MCP als tragfähigen Standard für Agent-zu-Tool-Kommunikation anerkennt.

Auf MCP-Seite unterstützt das Protokoll inzwischen Streamable HTTP-Transport, wodurch Remote-MCP-Server stärker wie traditionelle HTTP-Dienste wirken. Ein MCP-Server hinter einem Streamable HTTP-Endpoint ist architektonisch nicht weit von einer REST-API entfernt, verwendet intern aber weiterhin JSON-RPC statt REST-Konventionen.

Das wahrscheinliche Ergebnis ist, dass beide Muster nebeneinander bestehen. OpenAPI-Schemas bleiben der Standardweg, um REST-APIs zu beschreiben, und GPT Actions (oder ähnliche Mechanismen) bleiben im OpenAI-Ökosystem die einfachste Brücke zwischen diesen APIs und KI-Modellen. MCP wird als anbieterübergreifender Standard für Tool-Integration wachsen, besonders in agentischen und Multi-Modell-Architekturen. Plattformen wie Quickchat AI, die sowohl HTTP Request Actions als auch Remote MCP Actions unterstützen, geben dir die Flexibilität, den Ansatz zu verwenden, der zu deiner konkreten Integration passt.

Weitere Lektüre

• MCP-Spezifikation
• Wie Model Context Protocol funktioniert: MCP erklärt
• MCP vs. HTTP
• Gib deinem AI Agent Live-Tools von einem Remote-MCP-Server: praktischer Build
• OpenAI Actions-Dokumentation
• OpenAPI-Spezifikation
• MCP-Server-Verzeichnis
• Herausforderungen beim Bau eines AI Agent auf Shopify MCP