Mike Bild
post

MCP: Wenn Software Fähigkeiten anbietet

MCP macht Softwarefähigkeiten für Agenten adressierbar. Gute Oberflächen bleiben wichtig, aber Arbeit bekommt eine zweite Schnittstelle.

≈ 10 Min. Lesezeit
SoftwareKIArchitektur
Markdown In Claude öffnenIn ChatGPT öffnen

Diesen Beitrag anhören (12 Min.)

MP3 herunterladen

Current thinking — Juli 2026. Dieser Artikel beschreibt meinen aktuellen Stand. Ich erwarte, dass sich Teile davon mit der Zeit ändern.

In den letzten Monaten habe ich viele Gespräche über Agenten geführt, in denen es zuerst um Modelle ging. Welches Modell ist am klügsten? Welches schreibt den besseren Code? Welches halluziniert weniger? Das sind legitime Fragen, aber sie verdecken schnell den wichtigeren Punkt: Ein Modell, das nur Text erzeugt, bleibt in der Rolle eines sehr guten Gesprächspartners. Wert entsteht erst, wenn ein System Arbeit erledigen kann.

„KI nimmt dir nicht den Job – aber jemand, der KI nutzt, tut es.“

— Richard Baldwin, Ökonom, World Economic Forum, Genf 2023

Jensen Huang wiederholt diesen Satz seit 2025 fast wörtlich auf jeder Bühne, die er betritt. Beide sprechen über Menschen und Arbeitsmärkte. Mich interessiert die Ebene darunter, denn für Software gilt derselbe Satz.

Um Apple und Safari kursieren gerade Gerüchte und Interpretationen. Ich behandle sie hier bewusst nicht als Beleg. Der Artikel hängt nicht an einer möglichen Browser-Integration. Die wichtigere Beobachtung ist ohnehin allgemeiner: Software beginnt, ihre Fähigkeiten so zu beschreiben, dass Agenten sie benutzen können.

Für Information zahlt kaum jemand, für Arbeit schon

Man sieht es am Preis. Der AI Index Report 2025 der Stanford University weist aus, dass die Inferenzkosten für ein Modell auf GPT-3.5-Niveau zwischen November 2022 und Oktober 2024 um mehr als das 280-fache gefallen sind: von rund 20 Dollar auf sieben Cent je Million Token. Was in zwei Jahren so billig wird, ist nicht das, wofür jemand dauerhaft Geld ausgibt. Eine Antwort zu erzeugen kostet inzwischen fast nichts.

Auf der anderen Seite der Rechnung stehen andere Zahlen. Foundation Capital veranschlagt die jährlichen Ausgaben von Unternehmen für Gehälter und ausgelagerte Dienstleistungen auf rund 4,6 Billionen Dollar. Salesforce setzt im selben Zeitraum etwa 35 Milliarden um, während weltweit 1,1 Billionen allein in Vertriebs- und Marketinggehälter fließen. Der Markt für erledigte Arbeit ist um Größenordnungen größer als der Markt für die Werkzeuge, mit denen Menschen sie erledigen.

Ajay Agrawal, Joshua Gans und Avi Goldfarb haben das schon 2018 sauber hergeleitet: KI senkt die Kosten der Vorhersage. Wertvoll wird dadurch alles, was Vorhersage erst brauchbar macht – Urteil und Handlung. In meinen Alltag übersetzt: Für die Auskunft, wie man eine Revision veröffentlicht, zahlt niemand. Für eine veröffentlichte Revision, geprüft, freigegeben und zurückrollbar, zahlt man sehr wohl.

Damit ist es eine Architekturfrage. Ein Chatbot kann mir erklären, wie ich einen Artikel veröffentliche. Ein Agent kann den Entwurf prüfen, eine Vorschau bauen, fehlende Metadaten melden und eine freigegebene Revision veröffentlichen. Zwischen beiden liegt nicht nur ein besseres Modell. Zwischen beiden liegt eine Schnittstelle zu Softwarefähigkeiten. Genau deshalb ist MCP interessant.

Nicht die App, sondern die Fähigkeit

Das Model Context Protocol ist ein offener Standard, mit dem KI-Anwendungen externe Systeme anbinden können. Die offizielle Dokumentation beschreibt MCP als Verbindung zwischen AI-Anwendungen und Datenquellen, Tools und Workflows. Die Spezifikation spricht von Hosts, Clients und Servern: Eine LLM-Anwendung ist der Host, darin sitzt ein Client, und ein Server stellt Kontext oder Fähigkeiten bereit.

Das klingt zunächst nach Integrationsinfrastruktur. In der Praxis steckt darin aber eine größere Verschiebung. Eine Anwendung ist dann nicht mehr nur eine Oberfläche für Menschen. Sie wird zugleich zu einer Menge adressierbarer Fähigkeiten für Agenten.

Früher war der Weg klar:

flowchart LR
  Human[Mensch] --> UI[Benutzeroberfläche]
  UI --> App[Anwendung]
  App --> Result[Ergebnis]

Der Mensch öffnet eine Oberfläche, sucht die richtige Stelle, füllt Felder aus, klickt auf Vorschau, klickt auf Veröffentlichen, prüft danach Feed und Suche. Die Anwendung ist das sichtbare Bündel aus Bedienung, Fachlogik und Zustand.

Mit einem Agenten verschiebt sich der Pfad:

flowchart LR
  Human[Mensch] --> Agent[Agent]
  Agent --> Validate[validate_markdown]
  Agent --> Preview[create_preview]
  Agent --> Publish[publish_revision]
  Agent --> Rollback[rollback_release]
  Agent --> Search[rebuild_search_index]

Die Oberfläche verschwindet dadurch nicht. Aber sie ist nicht mehr der einzige Zugang zur Arbeit. Ein Agent muss nicht wissen, wo der Button sitzt. Er muss wissen, welche Fähigkeit existiert, welche Eingaben sie erwartet, welche Ergebnisse zurückkommen und welche Regeln gelten.

Das ist der Kern: MCP macht Softwarefähigkeiten für Agenten adressierbar.

Ein Publishing-System als Beispiel

Nehmen wir ein kleines Publishing-System. Der Ablauf ist vertraut: Markdown kommt hinein, eine Vorschau wird gebaut, jemand prüft sie, danach wird eine Revision veröffentlicht. Im Fehlerfall braucht es Rollback. Nach dem Release müssen Index, Feed und Cache stimmen.

In einer klassischen Oberfläche sind diese Schritte oft an Seiten und Buttons gebunden. Für Menschen ist das sinnvoll. Eine gute GUI zeigt Kontext, verhindert Fehler und macht Zustände sichtbar. Für einen Agenten ist dieselbe Oberfläche dagegen Umweg und Fehlerquelle. Er müsste klicken, warten, aus HTML lesen, interpretieren, wieder klicken. Das ist Automatisierung auf der falschen Ebene.

Als MCP-Fähigkeiten sähe dasselbe System anders aus:

const publishRevision = defineTool({
  name: "publish_revision",
  description: "Publish an approved content revision",
  inputSchema: {
    type: "object",
    properties: {
      site: { type: "string" },
      revisionId: { type: "string" },
      reason: { type: "string" }
    },
    required: ["site", "revisionId", "reason"]
  }
});

Der wichtige Teil ist nicht die konkrete Syntax. Der wichtige Teil ist die Verschiebung: Aus einem Bedienpfad wird eine benannte Fähigkeit. publish_revision ist nicht „klicke auf den grünen Button“. Es ist eine fachliche Operation mit Eingaben, Ergebnis, Rechten und Fehlern.

Sobald die Operation so vorliegt, kann ein Agent damit arbeiten. Er kann vorher validate_markdown aufrufen, bei Warnungen zurückfragen, eine Vorschau anfordern, den Freigabestand prüfen und erst danach veröffentlichen. Der Agent bedient dabei keinen Bildschirm. Die Anwendung reicht ihm Arbeitsschritte.

Warum der HTML-Vergleich reizvoll ist

In dem Vortrag, der den Anstoß für diesen Text gegeben hat, fiel sinngemäß die These: MCP könnte für Agenten eine Rolle spielen, die HTML für das Web hatte. Ich merke, dass mich dieser Vergleich reizt, weil er die Größenordnung gut ausdrückt. Gleichzeitig bremse ich mich an genau dieser Stelle. HTML war nicht nur ein technisches Format, sondern Teil eines riesigen sozialen, wirtschaftlichen und browsergetriebenen Ökosystems. Ich kann im Juli 2026 nicht seriös behaupten, dass MCP ähnlich grundlegend wird. Ich kann nur sagen: Der Gedanke ist stark genug, dass ich ihn nicht einfach wegwischen möchte.

Als Analogie ist der Vergleich trotzdem nützlich. HTML hat Inhalte in eine Form gebracht, die Browser allgemein darstellen konnten. MCP bringt Fähigkeiten in eine Form, die Agenten allgemein entdecken und aufrufen können. Das ist nicht dasselbe. Aber in beiden Fällen entsteht Wert dadurch, dass nicht jede Integration als Einzelstück gebaut werden muss.

Anthropic hat MCP Ende 2024 genau mit diesem Problem eingeführt: Jede neue Datenquelle brauchte vorher eine eigene Anbindung. Die Spezifikation standardisiert den Austausch über JSON-RPC und beschreibt unter anderem Resources, Prompts und Tools. Besonders die Tools sind für die Architekturfrage spannend, weil sie aus Software ausführbare Fähigkeiten machen.

Damit ist MCP nicht automatisch die Lösung. Ein Standard nimmt Integrationsarbeit weg, aber er nimmt keine Produktverantwortung weg. Schlechte Fähigkeiten bleiben schlecht, auch wenn sie standardisiert angeboten werden.

Die Entbündelung passiert an den Rändern

Ich glaube nicht, dass Anwendungen einfach in kleine MCP-Dienste zerfallen und danach keine Produkte mehr sind. Das wäre zu grob. Eine gute Anwendung bündelt mehr als Funktionen: Sie bündelt Verständnis, Bedienung, Datenmodell, Rechte, Feedback und Verantwortung.

Aber an den Rändern entsteht eine neue Form von Entbündelung. Fähigkeiten, die bisher nur über eine Oberfläche erreichbar waren, werden einzeln adressierbar. Ein Publishing-System ist weiterhin ein Publishing-System. Aber seine Arbeitsschritte können auch von einem Agenten genutzt werden:

  • Markdown prüfen
  • Vorschau erzeugen
  • Links testen
  • Revision veröffentlichen
  • Release zurückrollen
  • Suchindex neu bauen

Das ist keine Microservice-Romantik. Es geht nicht darum, alles kleinzuschneiden. Es geht darum, die richtigen Fähigkeiten explizit zu machen. Eine Fähigkeit ist dann gut geschnitten, wenn sie fachlich verständlich, technisch prüfbar und betrieblich verantwortbar ist.

Der falsche Schnitt wäre ein generisches run_sql oder click_button. Der bessere Schnitt ist eine Operation, die die Fachabsicht trägt: publish_revision, rollback_release, create_preview. Der Agent soll nicht an der Datenbank vorbei arbeiten. Er soll innerhalb der Regeln arbeiten, die das System ohnehin braucht.

Tool-Zugriff ist eine Berechtigung

Genau hier wird die Sache ernst. Ein Agent, der Text schreibt, kann Unsinn produzieren. Ein Agent, der Tools aufruft, kann Wirkung erzeugen. Er kann Daten lesen, Dateien ändern, Releases auslösen oder externe Systeme benachrichtigen. Deshalb ist Tool-Zugriff kein Komfortfeature. Tool-Zugriff ist eine Berechtigung.

Die MCP-Spezifikation sagt selbst, dass solche Fähigkeiten Sicherheits- und Vertrauensfragen mitbringen: Nutzer müssen Datenzugriff und Operationen verstehen und kontrollieren können, Tools sind mit Vorsicht zu behandeln, Hosts müssen Zustimmung vor Tool-Aufrufen einholen. Das ist kein Anhang. Das ist die Mitte des Themas.

In einem produktiven System reicht deshalb eine Tool-Definition nicht aus. Daneben gehört eine Policy:

type ToolPolicy = {
  tool: string;
  allowedRoles: string[];
  requiresApproval: boolean;
  maxRuntimeMs: number;
};

type ToolAuditEntry = {
  tool: string;
  inputHash: string;
  decision: "allowed" | "blocked" | "approved";
  actorId: string;
  runId: string;
};

Damit wird aus „der Agent darf veröffentlichen“ eine überprüfbare Regel. Wer durfte welchen Aufruf machen? Welche Eingabe wurde verwendet? War eine Freigabe nötig? Wurde der Aufruf ausgeführt oder blockiert? Ohne diese Fragen ist die Architektur nur Demo.

Prompt Injection gehört in dieselbe Betrachtung. Wenn ein externer Markdown-Text den Agenten dazu bringen kann, ein Tool anders zu verwenden, ist nicht der Text schuld. Dann ist die Grenze falsch gezogen. Externe Inhalte sind Daten, keine Instruktionen. Die Tool-Policy darf nicht aus dem Dokument kommen, das der Agent gerade prüft.

Was mit GUIs passiert

Die stärkste Version der Zukunftsthese lautet: Wenn Agenten Software bedienen, werden GUIs zweitrangig. Ich halte das für teilweise richtig und teilweise überzogen.

Routinepfade werden sich verschieben. Wenn ich einem Agenten sagen kann, er soll einen Entwurf prüfen, eine Vorschau bauen und mir nur die Abweichungen zeigen, dann will ich dafür nicht durch fünf Masken klicken. Das gilt besonders für wiederkehrende Arbeit, die gut beschrieben und sauber begrenzt ist.

Aber GUIs bleiben wichtig. Menschen brauchen Oberflächen für Exploration, Kontrolle, Ausnahmefälle und Vertrauen. Eine Vorschau ist eine GUI. Ein Diff ist eine GUI. Ein Audit-Log ist eine GUI. Ein Freigabedialog ist eine GUI. Gerade wenn Agenten mehr ausführen, werden gute Kontrolloberflächen wichtiger, nicht unwichtiger.

Die Rolle verschiebt sich. Die GUI ist nicht mehr zwingend der einzige Ort, an dem Arbeit ausgelöst wird. Sie wird stärker zum Ort, an dem Menschen Arbeit verstehen, prüfen und korrigieren.

Was ich daraus mitnehme

MCP ist für mich weniger eine spektakuläre Technik als ein guter Anlass, Software anders zu beschreiben. Nicht nur: Welche Daten hat mein System? Nicht nur: Welche Oberfläche biete ich an? Sondern: Welche Arbeit kann mein System sicher, nachvollziehbar und prüfbar erledigen?

Das ist eine Architekturfrage. Wer Fähigkeiten nur als dünne Hülle um interne Funktionen veröffentlicht, baut wahrscheinlich neue Risiken. Wer sie fachlich schneidet, mit Rechten versieht und auditiert, schafft dagegen eine robuste Grundlage für Agenten.

Nicht jede Anwendung braucht dafür sofort einen MCP-Server. Viele Systeme sind mit einer guten API, einem CLI oder einer klaren Oberfläche besser bedient. Aber die Richtung ist erkennbar: Software, die von Agenten genutzt werden soll, muss ihre Fähigkeiten explizit machen.

Der Satz „MCP ist das HTML für Agenten“ ist mir zu groß. Der kleinere Satz reicht: MCP standardisiert, wie Agenten Softwarefähigkeiten finden und aufrufen können. Wenn sich dieser Satz durchsetzt, verändert er bereits genug.

Baldwins Satz gilt am Ende nicht nur für Menschen. Eine Anwendung wird nicht dadurch überflüssig, dass es KI gibt. Sie wird von der Anwendung überholt, deren Fähigkeiten ein Agent tatsächlich nutzen kann.

Weiterführende Quellen

Kommentare