MCP vs. API: Wann MCP oder direktes HTTP für KI-Tools

Wenn du einen KI-Agenten mit externen Tools und APIs verbindest, gibt es zwei grundlegende Ansätze: Model Context Protocol (MCP) als Abstraktionsschicht verwenden oder eine API direkt über HTTP aufrufen. Beide funktionieren. Sie treffen unterschiedliche Abwägungen bei Flexibilität, Komplexität, Leistung und Portabilität.

Dieser Beitrag vergleicht beide Ansätze mit konkreten Codebeispielen, einer Latenzanalyse und einem Entscheidungsrahmen für die Auswahl.

Die zwei Ansätze

Direkte HTTP-Integration

Die KI-Anwendung (oder ihr Backend) ruft externe APIs direkt über standardmäßige HTTP-Anfragen auf. Der Entwickler schreibt Code, der Anfragen erstellt, Authentifizierung verarbeitet, Antworten parst und Ergebnisse zurück an das LLM übergibt.

┌──────┐     ┌────────┐                        ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘     │        │◀─── JSON response ─────│             │
             │        │                        └─────────────┘
             │        │── result as context ──▶ LLM
             │        │◀── formatted answer ───
             └───┬────┘
                 │
                 ▼
           User gets answer

MCP-Integration

Die KI-Anwendung verbindet sich mit einem MCP-Server, der die externe API kapselt. Die Anwendung verwendet das MCP-Protokoll, um verfügbare Tools zu erkennen, sie nach Namen aufzurufen und Ergebnisse zu erhalten. Der MCP-Server übernimmt die tatsächlichen HTTP-Aufrufe an die externe API.

┌──────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
             │                   │              └────────────┘     └──────────┘
             │                   │── result as context ──▶ LLM
             │                   │◀── formatted answer ───
             └─────────┬─────────┘
                       │
                       ▼
                 User gets answer

Der wichtigste Unterschied: Bei direktem HTTP enthält die KI-Anwendung den API-Integrationscode. Bei MCP enthält ihn der MCP-Server, und die KI-Anwendung ruft Tools nur nach Namen auf.

Du kannst die MCP-Seite dieses Diagramms nutzen, ohne den Server selbst zu bauen: Quickchat AI hostet für jeden AI Agent einen streamable-HTTP-MCP-Server, und deinen Agenten in einen MCP-Server umzuwandeln bedeutet nur, eine URL in die KI-App einzufügen.

Codevergleich

Vergleichen wir beide Ansätze anhand eines praktischen Beispiels: Repositories eines GitHub-Benutzers abrufen.

Direkte HTTP-Integration

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Repositories für einen GitHub-Benutzer abrufen."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

Um dies in ein LLM zu integrieren, brauchst du außerdem:

• Eine Tool-Definition in dem Format, das das LLM erwartet (OpenAI-Function-Calling-Schema, Claude-Tool-Use-Schema usw.)
• Code, der den Tool-Aufruf des LLM parst, get_user_repos ausführt und das Ergebnis wieder in die Konversation einfügt
• Fehlerbehandlung für HTTP-Fehler, Rate Limits und abgelaufene Authentifizierung

MCP-Server

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """Die 10 zuletzt aktualisierten Repositories für einen GitHub-Benutzer abrufen.

    Args:
        username: GitHub-Benutzername, der nachgeschlagen werden soll
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "unbekannt"
            lines.append(f"- {r['name']} ({lang}, {stars} Sterne): {r['description'] or 'Keine Beschreibung'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

Die MCP-Version kapselt API-Aufruf, Authentifizierung und Antwortformatierung im Server. Jeder MCP-kompatible Client kann dieses Tool verwenden, ohne etwas über die GitHub-API wissen zu müssen.

Was sich für die KI-Anwendung ändert

Leistungsvergleich

MCP fügt eine Schicht zwischen der KI-Anwendung und der externen API hinzu. Diese Schicht hat Kosten.

Latenz

Bei stdio transport (lokale MCP-Server) ist der Overhead minimal: Prozessstart beim Start (einmalig, typischerweise unter 100ms) und Interprozesskommunikation pro Nachricht (unter einer Millisekunde auf modernen Systemen). In der Praxis dominiert der externe API-Aufruf die Gesamtlatenz.

Bei remote MCP servers (Streamable HTTP oder SSE) kommt ein HTTP-Roundtrip zwischen Client und MCP-Server hinzu, plus der HTTP-Roundtrip des MCP-Servers zur externen API. Wenn MCP-Server und externe API am selben Ort liegen, ist dieser Overhead gering (einstellige Millisekunden). Wenn sie in unterschiedlichen Regionen liegen, addiert er sich. Der Transport ist jedoch selten das, was ein Benutzer spürt: Beim Aufbau eines Help-Center-Agenten auf Notions gehostetem MCP-Server dauerten 248 Tool-Aufrufe im Durchschnitt 2.7 Sekunden pro Aufruf. Fast die gesamte Zeit entfiel auf die Suche in Notion und das Rendern von Seiten, nicht auf den Zwischenschritt.

Für die meisten Anwendungsfälle mit KI-Agenten, bei denen die LLM-Inferenz 500ms-5s dauert, ist der MCP-Overhead vernachlässigbar.

Verbindungsverwaltung

Direktes HTTP: Deine Anwendung verwaltet Verbindungen zu jeder externen API. Das bedeutet, Connection Pools, Retry-Logik und Rate Limiting pro API zu behandeln.

MCP: Deine Anwendung verwaltet eine Verbindung pro MCP-Server. Der Server verwaltet die Verbindung zur externen API. Wenn du 10 Tools über 3 MCP-Server verteilt hast, verwaltest du 3 Verbindungen statt 10.

Wann du MCP verwenden solltest

Mehrere Tool-Integrationen

Wenn deine KI-Anwendung eine Verbindung zu mehr als 5 externen Diensten benötigt, reduziert MCP den Integrationsaufwand. Statt für jeden Dienst eigene API-Clients zu schreiben und zu warten, verbindest du dich mit MCP-Servern, von denen viele als Open-Source-Projekte verfügbar sind.

Portabilität zwischen KI-Plattformen

Wenn du MCP-Server für deine Tools baust, funktionieren diese Server mit jedem MCP-Client: Claude Desktop, Cursor, Windsurf, eigenen Anwendungen und Plattformen wie Quickchat AI. Bei direktem HTTP müsstest du Tool-Definitionen für das Format jeder Plattform neu implementieren.

Dynamische Tool-Erkennung

MCP unterstützt Tool-Erkennung zur Laufzeit über tools/list. Eine KI-Anwendung kann sich mit einem Server verbinden und erkennen, welche Tools verfügbar sind, ohne hartcodierte Konfiguration. Das ist nützlich für Szenarien, in denen sich Tools häufig ändern oder vom Benutzer konfiguriert werden können.

Trennung von Verantwortlichkeiten

Wenn unterschiedliche Teams unterschiedliche Tools besitzen, bietet MCP eine klare Grenze. Das Team, dem die Salesforce-Integration gehört, baut und wartet den Salesforce-MCP-Server. Das KI-Anwendungsteam verbindet sich damit, ohne die Salesforce-API verstehen zu müssen. Änderungen an der Salesforce-API werden im MCP-Server behandelt, ohne die KI-Anwendung anzufassen.

Wann du direktes HTTP verwenden solltest

Eine oder zwei Integrationen

Wenn dein KI-Agent nur eine API aufrufen muss (zum Beispiel eine Datenbankabfrage), ist der Aufwand für den Betrieb eines MCP-Servers unnötig. Ein direkter HTTP-Aufruf ist einfacher und hat weniger bewegliche Teile.

Du musst die Anfrage auch nicht von Hand schreiben. Der API Action Builder in Klartext liest eine dokumentierte REST-API, generiert Methode, URL, Parameter und Beschreibung und lässt dich anschließend die echte Antwort testen, bevor du sie aktivierst.

Maximale Kontrolle über Anfragen

MCP-Server abstrahieren die HTTP-Details. Wenn du präzise Kontrolle über den Aufbau der Anfrage brauchst (bestimmte Header, Query-Parameter, Request-Signing oder nicht standardmäßige Authentifizierung), gibt dir direktes HTTP diese Kontrolle, ohne gegen eine Abstraktionsschicht arbeiten zu müssen.

Latenzkritische Operationen

Wenn jede Millisekunde zählt (z. B. bei Echtzeit-Voice-Agents, bei denen Tool-Aufrufe innerhalb strikter Zeitbudgets abgeschlossen sein müssen), entfernt der Verzicht auf die MCP-Schicht einen Hop.

Nicht-KI-HTTP-Aufrufe

Wenn der HTTP-Aufruf nicht von einem KI-Agenten ausgelöst wird (z. B. ein Backend-Cron-Job, der Daten synchronisiert), ist MCP irrelevant. MCP ist speziell für die Kommunikation zwischen KI und Tool entwickelt. Normale Backend-Dienste sollten normale HTTP-Clients verwenden.

Hybrider Ansatz

Viele Produktionssysteme verwenden beides. Das Muster:

• MCP für Tool-Integrationen, die der KI-Agent während Konversationen aufruft (CRM-Abfragen, Ticketerstellung, Knowledge-Base-Abfragen)
• Direktes HTTP für interne Backend-Operationen, Webhooks und System-zu-System-Kommunikation

So funktioniert Quickchat AI intern. Die Plattform unterstützt sowohl HTTP Request Actions (direkte API-Aufrufe mit Parameter-Templating) als auch Remote MCP Actions (Verbindungen zu externen MCP-Servern). Du wählst für jede Integration den passenden Ansatz:

Einen detaillierten Vergleich, wie das in der Praxis funktioniert, einschließlich der Unterschiede zwischen OpenAIs GPT Actions und MCP, findest du unter GPT Actions vs MCP.

Entscheidungsrahmen

Verwende dieses Flussdiagramm zur Auswahl:

1. Ruft der KI-Agent das Tool auf? Wenn nein (es ist eine Backend-Operation), verwende direktes HTTP.
2. Wie viele externe Tools brauchst du? Bei 1-2 ist direktes HTTP einfacher. Bei 3+ solltest du MCP in Betracht ziehen.
3. Gibt es einen vorgefertigten MCP-Server für den Dienst? Wenn ja, spart seine Verwendung Entwicklungszeit.
4. Muss die Integration über mehrere KI-Plattformen hinweg funktionieren? Wenn ja, bietet MCP Portabilität.
5. Ist Latenz kritisch (Budget unter 100ms für Tool-Aufrufe)? Wenn ja, benchmarke den MCP-Overhead und entscheide entsprechend.
6. Besitzen unterschiedliche Teams unterschiedliche Integrationen? Wenn ja, hilft das Server-pro-Integration-Modell von MCP bei Zuständigkeitsgrenzen.

In der Praxis wird MCP zunehmend zur Standardwahl, wenn du einen KI-Agenten baust, der mit externen Diensten interagieren muss. Das Ökosystem vorgefertigter Server ist groß genug, dass du oft ohne eigenen Servercode starten kannst.

Weitere Lektüre

• Deinen AI Agent mit einem Remote-MCP-Server verbinden: Gib deinem Agenten Live-Tools, Schritt für Schritt
• So funktioniert Model Context Protocol. MCP erklärt: Einführung in MCP
• GPT Actions vs MCP: Vergleich mit OpenAIs Ansatz
• MCP-Spezifikation: Die offizielle Protokollspezifikation
• HubSpot AI Actions: Beispiel für HTTP-basierte AI Actions in der Praxis
• Der OpenAI-Hugging-Face-Vorfall, was tatsächlich passiert ist: Der Vorfall Schritt für Schritt erklärt und was Hacking wirklich bedeutet