UTCP vs. MCP: Was der Herausforderer taugt

Ein Agent soll eine REST-API nutzen. Mit MCP baut oder installiert jemand einen MCP-Server, der die API einpackt, und der Agent spricht mit diesem Server. UTCP, das Universal Tool Calling Protocol, fragt: Warum der Umweg? Der Dienst beschreibt seine Schnittstelle in einer JSON-Datei, und der Agent ruft die API danach selbst auf. Kein Wrapper, kein zusätzlicher Prozess.

Der Gedanke ist vernünftig. Trotzdem ist UTCP gut ein Jahr nach dem Start ein Randphänomen, und daran wird sich so bald wenig ändern. Interessanter als das Protokoll ist ein Ableger aus demselben Umfeld, der gar nicht gegen MCP antritt. Hier die Einordnung, damit ihr die Frage "Sollten wir statt MCP nicht lieber UTCP nehmen?" schnell beantworten könnt.

Wer MCP noch nicht kennt, liest zuerst unseren Grundlagenartikel MCP: Wie KI-Tools miteinander reden.

Zwei Wege zum selben Werkzeug

flowchart TB
  subgraph mcp["MCP"]
    direction TB
    A1["Agent"] --> S1["MCP-Server<br/>(Wrapper)"] --> P1["API des Dienstes"]
  end
  subgraph utcp["UTCP"]
    direction TB
    A2["Agent"] -->|"1. Manual laden"| M2["UTCP-Manual<br/>(JSON)"]
    A2 -->|"2. direkter Aufruf"| P2["API des Dienstes"]
  end
  mcp ~~~ utcp

Bei MCP steckt die Logik im Server: Er kennt die API, hält die Zugangsdaten und entscheidet, was er dem Agenten anbietet. Bei UTCP steckt sie im Client des Agenten. Er liest die Beschreibung, setzt die Zugangsdaten ein und spricht die API in ihrem eigenen Protokoll an. Diese Verschiebung ist der Kern des ganzen Vergleichs, im Guten wie im Schlechten.

Wie UTCP funktioniert

Die Beschreibung heißt Manual. Ein Dienst kann sie als Datei mitliefern oder unter einem Endpunkt wie /utcp anbieten. Jedes Tool darin hat einen Namen, eine Beschreibung, ein JSON-Schema für die Eingaben und ein sogenanntes Call Template. Das Call Template sagt dem Client, wie der Aufruf aussieht. Das Beispiel aus der Spezifikation, gekürzt um das Ausgabeschema:

{
  "manual_version": "1.0.0",
  "utcp_version": "1.0.1",
  "tools": [
    {
      "name": "get_user",
      "description": "Retrieve user information by ID",
      "inputs": {
        "type": "object",
        "properties": {
          "user_id": {"type": "string", "description": "User identifier"}
        },
        "required": ["user_id"]
      },
      "tool_call_template": {
        "call_template_type": "http",
        "url": "https://api.example.com/users/{user_id}",
        "http_method": "GET"
      }
    }
  ]
}

Neben http gibt es Call Templates für Kommandozeilenbefehle (cli), Server-Sent Events, Textdateien und, wichtig für später, für MCP-Server. Im Python-SDK kommen WebSocket und GraphQL als Plugins dazu. gRPC nennt das Projekt seit dem Start als Ziel, ein Plugin dafür gibt es in den SDKs für Python und TypeScript bislang nicht. Liegt statt eines Manuals nur eine OpenAPI-Beschreibung vor, wandelt der Client sie laut Doku automatisch um.

Zugangsdaten stehen im Manual nur als Platzhalter, etwa ${API_KEY}. Der Client füllt sie aus seiner Konfiguration oder aus Umgebungsvariablen. Unterstützt werden API-Keys, Basic Auth und OAuth2 mit Client Credentials.

Zum Projekt selbst:

• Start: Die GitHub-Organisation entstand im Juni 2025, die offizielle Vorstellung folgte am 15.07.2025.
• Träger: keine Firma und keine Stiftung. Das Projekt beschreibt sich als vollständig von der Community getragen. Eine formale Governance ist nicht beschrieben.
• Lizenz: Die SDKs für Python, TypeScript, Go und Rust stehen unter MPL-2.0.
• Version: Die SDKs für Python und TypeScript tragen seit Mitte September 2026 die Version 1.2.0. Die Spezifikation selbst ist noch bei 1.1, eine Version 1.2 ist nicht veröffentlicht.
• Entwicklung: Im Python-SDK stammen 234 von rund 260 Commits von einer Person (GitHub, 09.11.2026). Von Januar bis April 2026 gab es dort keinen einzigen Commit, im September dafür über sechzig.

Wo MCP heute steht

MCP hat in diesem Jahr genau die Stellen angefasst, an denen UTCP ansetzt. Die aktuelle Spezifikation 2026-07-28 hat einen zustandslosen Kern ohne Sitzung, Tool-Listen lassen sich cachen und kommen in fester Reihenfolge, damit Prompt-Caches stabil bleiben. Die Details stehen in unserem MCP-Artikel.

Die Roadmap vom 22.08.2026 spricht das Kontextproblem offen an: Wer einen Server mit hundert Tools anbindet, bezahlt laut Roadmap mit Tokens für den ganzen Katalog, bevor überhaupt eine Frage gestellt ist. Geplant ist deshalb "progressive discovery". Ein Server soll zunächst nur einen kleinen Einstieg anbieten und weitere Tools erst zeigen, wenn das Gespräch konkreter wird.

Getragen wird MCP seit Dezember 2025 von der Agentic AI Foundation unter dem Dach der Linux Foundation, die laut eigener Angabe vom 22.10.2026 über 300 Mitglieder hat.

Der direkte Vergleich

Die Zeile zum Kontextverbrauch verdient einen eigenen Abschnitt, denn mit genau diesem Argument wirbt das UTCP-Projekt.

Das eigentliche Thema: Kontextkosten

Die meisten Agenten laden alle Tool-Beschreibungen in den Kontext, bevor sie loslegen. Bei vielen angebundenen MCP-Servern sind das schnell zehntausende Tokens, die Geld kosten und das Modell ablenken. Im Artikel CLI statt API haben wir das mit Zahlen von Mario Zechner beschrieben.

UTCP löst dieses Problem durch den Protokollwechsel allein nicht. Auch ein Manual landet als Tool-Liste beim Modell. Gelöst wird es an anderer Stelle, und zwar mit Ansätzen, die alle auf MCP aufsetzen:

• Tool Search: Anthropic lädt Tool-Beschreibungen erst nach einer Suche. In Anthropics eigenem Beispiel mit mehreren MCP-Servern sank der Verbrauch von rund 77.000 auf 8.700 Tokens. Die Trefferquote bei der Tool-Auswahl stieg für Opus 4.5 von 79,5 auf 88,1 Prozent (Anthropic, 24.11.2025).
• Code statt Einzelaufrufe: Das Modell schreibt Code, der die Tools aufruft, und nur das Ergebnis kommt zurück in den Kontext. Anthropic nennt für ein Beispiel einen Rückgang von 150.000 auf 2.000 Tokens und weist selbst darauf hin, dass dafür eine abgesicherte Ausführungsumgebung nötig ist (Anthropic, 04.11.2025). Cloudflare packt seine gesamte API mit über 2.500 Endpunkten in einen MCP-Server mit zwei Tools und rund 1.000 Tokens. Ein klassischer MCP-Server dafür bräuchte laut Cloudflare 1,17 Millionen Tokens (Cloudflare, 20.02.2026).
• Progressive Discovery in der MCP-Roadmap, siehe oben.

Alle drei Zahlenangaben sind Herstellerangaben aus eigenen Beispielen, keine unabhängigen Messungen. Die Richtung ist trotzdem eindeutig.

Bemerkenswert: Das bekannteste Projekt aus der UTCP-Organisation ist kein Protokoll, sondern Code Mode, eine Bibliothek nach genau diesem Prinzip. Mit rund 1.650 GitHub-Sternen hat es mehr als doppelt so viele wie das Python-SDK von UTCP. Code Mode stellt dem Agenten ein einziges Tool bereit, das TypeScript-Code ausführt, und bindet darüber UTCP-Manuals und MCP-Server an. Für Clients wie Claude Desktop, die nur MCP sprechen, gibt es Code Mode selbst als MCP-Server. Die Entwicklung im UTCP-Umfeld geht also weg von "UTCP statt MCP" hin zu "eine Schicht über beidem".

Verbreitung, nüchtern betrachtet

Paket-Downloads sind ein grober Indikator, weil CI-Läufe und Mirrors mitzählen. Der Abstand ist aber so groß, dass es darauf nicht ankommt (Downloads der letzten 30 Tage, Stand 09.11.2026):

Dazu passt das Bild bei den Integrationen. Für AWS Strands Agents gibt es ein UTCP-Paket, das laut Strands-Doku von der Community gepflegt und vom Strands-Team weder betreut noch unterstützt wird. Die Adapter für LangChain und Pydantic AI kommen aus dem UTCP-Umfeld und werden kaum heruntergeladen. Die Showcase-Seite des Projekts nennt als produktiven Einsatz genau ein Werkzeug: Hexis von Bevel Software, der Firma, bei der einer der drei UTCP-Admins und das Distribution-Team des Projekts arbeiten. Und Hexis selbst ist von außen über MCP erreichbar.

Unabhängige Berichterstattung ist dünn. Die ausführlichste stammt von Nordic APIs aus dem Januar 2026. Der Autor hält keinen der beiden Ansätze für grundsätzlich überlegen, sieht MCP aber bei der Herstellerunterstützung klar vorn. Die meisten anderen Vergleiche im Netz geben die Selbstdarstellung des Projekts wieder. Angaben wie "~100ms vs ~150ms" auf der UTCP-Vergleichsseite kommen ohne Messmethode und taugen nicht als Argument.

Wer die Schlüssel hält

Für Teams, die Agenten im Unternehmen betreiben, ist die Sicherheitsfrage wichtiger als die Latenz. Bei UTCP hält der Agent-Client die Zugangsdaten für jedes Backend selbst. Das spart eine zentrale Stelle, an der alle Schlüssel liegen. Es heißt aber auch, dass Rechte, Protokollierung und Freigaben bei jedem Backend einzeln geregelt werden müssen.

Die Projektdoku ist an dieser Stelle selbstkritisch. Sie warnt vor CLI-Aufrufen als Hochrisiko, vor Manipulation über eingesetzte Variablen und vor Manuals aus fremden Quellen (Security-Doku). Seit September und Oktober 2026 erzwingen die Clients strengere Regeln: nur HTTPS oder lokale Adressen, Prüfung jeder Weiterleitung, keine lokalen Adressen aus fremden Manuals. Das sind sinnvolle Härtungen, aber sie zeigen auch, wie viel Verantwortung beim Client liegt.

Simon Willison hat im September in der Hacker-News-Debatte "MCP was always a bad idea?" aufgezählt, was Firmen für kontrollierbare Agenten brauchen: festgelegte Zugriffsrechte, Authentifizierung ohne API-Keys im Agenten, eine Oberfläche zum Verbinden weiterer Dienste und Audit-Logs. Sein Fazit zu MCP: "MCP makes all of that so much easier to provide". UTCP erwähnt er nicht, das Argument trifft das Modell aber direkt.

Für den DSGVO-Alltag heißt das nach unserer Einschätzung: Ohne zentrale Schicht müsst ihr Protokollierung und Auftragsverarbeitung für jeden direkt angesprochenen Dienst einzeln nachweisen. Mit MCP-Gateway und Server habt ihr dafür eine Stelle. Das ist keine Eigenschaft des Protokolls, sondern der Architektur. Wie ihr MCP selbst absichert, steht in MCP absichern. Dass auch MCP-Code Lücken hat, zeigt unsere Meldung zu den fünf Lücken im TypeScript-SDK.

Brücken in beide Richtungen

Ganz getrennt sind die Welten ohnehin nicht:

• UTCP ruft MCP auf. Mit dem Call Template mcp beschreibt ein Manual einen MCP-Server als Tool-Quelle. Ein UTCP-Client kann also bestehende MCP-Server weiter nutzen.
• UTCP-Tools als MCP-Server. Die Brücke utcp-mcp stellt UTCP-Manuals als MCP-Server bereit. So erreichen sie Claude Desktop, Cursor oder VS Code. Das ist derzeit der praktische Weg, UTCP in gängigen Clients überhaupt einzusetzen.

Wer ein Manual für seine API schreibt, verbaut sich also nichts. Wer dafür einen MCP-Server abschaltet, verliert dagegen fast alle Clients.

Was das für euer Team heißt

UTCP hat eine richtige Beobachtung gemacht: Nicht jede API braucht einen eigenen Server, und Tool-Beschreibungen kosten Kontext. Die Antworten darauf entstehen aber gerade innerhalb des MCP-Ökosystems, teils mit Werkzeugen aus dem UTCP-Umfeld selbst.