MCP: Wenn Software Fähigkeiten anbietet

MCP: Wenn Software Fähigkeiten anbietet

Welches Modell schreibt den besseren Code? Diese Frage greift für Agenten zu kurz. Ein Modell, das nur Text erzeugt, hat keine ausführbare Schnittstelle zur Software – es bleibt in der Rolle eines sehr guten Gesprächspartners. Für agentische Produktabläufe entsteht zusätzlicher Wert erst, wenn das System kontrolliert Arbeit ausführen kann.

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

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

Jensen Huang griff den Gedanken im Mai 2025 nahezu wörtlich auf. Beide sprechen über Menschen und Arbeitsmärkte. Mich interessiert die Ebene darunter, denn für Software gilt derselbe Satz: Software beginnt, ihre Fähigkeiten so zu beschreiben, dass Agenten sie benutzen können.

Inferenz wird billiger, ausgeführte Arbeit bleibt wertvoll#

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. Eine Antwort zu erzeugen kostet inzwischen fast nichts. Daraus folgt nicht zwingend, dass niemand mehr für Information zahlt – die Quelle belegt Inferenzkosten, nicht Zahlungsbereitschaft, und zwischen Erzeugungskosten, Produktpreis und Zahlungsbereitschaft liegen eigene Mechanismen. Meine These ist begrenzter: Ein Angebot, dessen Kern in zwei Jahren um Größenordnungen billiger wird, kann seinen Preis kaum allein auf diese Erzeugung stützen.

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 setzte im von Foundation Capital betrachteten Berichtszeitraum etwa 35 Milliarden um, während nach derselben Erhebung weltweit 1,1 Billionen allein in Vertriebs- und Marketinggehälter fließen. Unternehmensumsatz, Gehälter und ausgelagerte Dienstleistungen sind nicht direkt vergleichbar; die Zahlen illustrieren nur die unterschiedlichen Größenordnungen. Die angeführten Ausgaben für Arbeit übersteigen den genannten Softwareumsatz um ein Vielfaches; daraus lässt sich jedoch keine vollständige Marktgröße ableiten.

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, sondern vor allem 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 KI-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. Tatsächlich steckt darin eine größere Verschiebung. Eine Anwendung ist dann nicht mehr allein eine Oberfläche für Menschen. Sie ist zugleich eine Menge adressierbarer Fähigkeiten für Agenten.

Der klassische Bedienpfad sieht so aus:

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 kommt ein zweiter Pfad hinzu:

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, und sie wird auch nicht zweitrangig. 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. Was es nicht tut: die Produktdomäne ersetzen oder ihre menschliche Bedienoberfläche verdrängen.

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 an Seiten und Buttons gebunden. Für Menschen ist das sinnvoll: Eine gute GUI zeigt Kontext, kann ungültige Eingaben blockieren und macht Zustände wie Freigabestä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ähigkeit sähe derselbe Arbeitsschritt 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. Der hier beschriebene MCP-Server stellt ihm fachliche Werkzeuge mit Eingabeschema und Berechtigungsprüfung bereit.

Drei Zugänge, eine Domäne#

Ein solches Publishing-System kann unter /mcp eine domänenorientierte Werkzeugoberfläche bereitstellen, die über dieselbe Veröffentlichungsdomäne läuft wie REST und die Weboberfläche. Die MCP-Werkzeuge bleiben dabei an die Produkt-Scopes gebunden.

Entscheidend ist, was diese Konstruktion nicht ist: MCP ist kein zweites System neben dem Produkt. Weboberfläche, HTTP und MCP greifen auf dieselbe Veröffentlichungsdomäne mit ihren Revisionen und Berechtigungsgrenzen zu. Die gemeinsame Domänenlogik entscheidet, was gilt – nicht der Kanal, über den die Anfrage kam.

Das hat eine praktische Folge für die Werkzeugliste selbst. Werkzeuge, die der aktuelle Principal nicht verwenden darf, müssen gar nicht erst in der Liste erscheinen. Der Agent entdeckt also nur Fähigkeiten, die seine Scopes hergeben. Und wo eine menschliche Freigabe vorgesehen ist, liefert der Agent diese Freigabe nicht selbst – sie bleibt ein eigener Schritt außerhalb seiner Reichweite.

Diese Filterung ist mehr als Komfort, aber sie ist Sichtbarkeit, nicht der eigentliche Schutz. Ein Agent, der ein Werkzeug nicht in der Liste sieht, entdeckt es nicht auf regulärem Weg. Der Schutz vor unberechtigten Aufrufen entsteht durch die serverseitige Autorisierung; die Werkzeuge bleiben an die Scopes des jeweiligen Produkts gebunden. Ein fehlendes Release-Recht lässt sich deshalb auch nicht dadurch beschaffen, dass man von der Weboberfläche zu MCP wechselt. Der Zugang wechselt, die Berechtigung nicht.

Tool-Zugriff ist eine Berechtigung#

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, sondern eine Berechtigung. Dass ein Werkzeug auffindbar ist, ist noch keine Erlaubnis zur Wirkung; der Aufruf bleibt eine autorisierte Operation, die das System prüft. In einem Remote-MCP-Zugang sind diese Aufgaben verteilt: Die Zustimmung des Nutzers vor einem Tool-Aufruf ist nach der MCP-Spezifikation Sache des Hosts, während das Produkt jeden Aufruf serverseitig gegen die Scopes des Principals prüft.

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. Zustimmung und Zugriffskontrolle gehören deshalb in den Ausführungspfad jedes Tool-Aufrufs.

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

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

type ToolAuditEntry = {
  tool: string;
  inputHash: string;
  idempotencyKey?: string;
  decision: "allowed" | "blocked" | "approved";
  outcome: "succeeded" | "failed" | "unknown";
  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? Bei schreibenden Operationen kommt eine weitere Frage hinzu: Was passiert, wenn der Agent nach einem Timeout denselben Aufruf wiederholt? Ein Idempotenzschlüssel und ein gespeichertes Ergebnis verhindern, dass aus einem unklaren Ausgang zwei Releases oder zwei Buchungen werden.

MCP standardisiert Auffindbarkeit und Aufruf eines Tools. Es macht die Operation weder fachlich sicher noch automatisch idempotent oder auditierbar. Diese Eigenschaften muss die angebotene Fähigkeit selbst tragen.

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.

Der falsche und der richtige Schnitt#

Ich glaube nicht, dass Anwendungen in kleine MCP-Dienste zerfallen und danach keine Produkte mehr sind. Eine gute Anwendung bündelt mehr als Funktionen: Sie bündelt Verständnis, Bedienung, Datenmodell, Rechte, Feedback und Verantwortung. Aber an den Rändern werden Fähigkeiten einzeln adressierbar, die bisher an Bedienpfade gebunden waren.

Eine Fähigkeit ist 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 – ein Werkzeug, das die Fachregeln umgeht, statt sie zu tragen. Der bessere Schnitt ist eine Operation mit Fachabsicht: publish_revision, rollback_release, create_preview. Der Agent soll nicht an der Datenbank vorbeiarbeiten. Er soll innerhalb derselben Regeln arbeiten, die auch für Weboberfläche und HTTP gelten.

Ein Standard nimmt dabei Integrationsarbeit weg, aber keine Produktverantwortung. Anthropic hat MCP Ende 2024 gegen genau das Problem eingeführt, dass jede neue Datenquelle eine eigene Anbindung brauchte. Die Spezifikation standardisiert den Austausch über JSON-RPC und beschreibt Resources, Prompts und Tools. Schlechte Fähigkeiten bleiben schlecht, auch wenn sie standardisiert angeboten werden.

Was mit Bedienoberflächen passiert#

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

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 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. Die Kontrolloberfläche dient dazu, dass ein Mensch versteht, was ein Agent getan hat, und dort eingreift, wo sein Urteil gefragt ist.

Kontrolloberfläche und MCP konkurrieren also nicht um dieselbe Aufgabe. Die Kontrolloberfläche richtet sich an menschliche Bedienung und Kontrolle, MCP an agentische Aufrufe. Für beide gelten die Berechtigungsgrenzen derselben Domäne.

Was ich daraus mitnehme#

MCP ist für mich weniger eine spektakuläre Technik als ein guter Anlass, Software anders zu beschreiben. Nicht allein über die Daten, die ein System hält, und nicht allein über die Oberfläche, die es anbietet – sondern über die Arbeit, die es sicher, nachvollziehbar und prüfbar erledigen kann.

Das ist eine Architekturfrage. Wer Fähigkeiten nur als dünne Hülle um interne Funktionen veröffentlicht, baut wahrscheinlich neue Risiken. Ein fachlicher Schnitt, Rechte, Idempotenz und Auditierbarkeit schaffen eine kontrollierbare Grundlage für Agenten – eine Qualitätsgarantie sind sie nicht.

Nicht jede Anwendung braucht sofort einen MCP-Server. Viele Systeme sind mit einer guten API, einem CLI oder einer klaren Oberfläche besser bedient. Wo es passt, gilt aber: Software, die von Agenten genutzt werden soll, muss ihre Fähigkeiten explizit machen – und sie muss dieselben Berechtigungsgrenzen über jeden Zugang durchsetzen.

Baldwins Satz gilt am Ende nicht nur für Menschen. Eine Anwendung wird nicht dadurch überflüssig, dass es KI gibt. Für agentisch ausgeführte Abläufe bleibt sie aber im Nachteil, wenn ihre Fähigkeiten nicht maschinell adressierbar sind – innerhalb der Regeln, die das Produkt ohnehin braucht.

Weiterführende Quellen#

• Model Context Protocol: Einführung
• Model Context Protocol: Spezifikation 2025-06-18
• Introducing the Model Context Protocol
• Agentic AI Foundation der Linux Foundation
• WEF Growth Summit 2023: Richard Baldwin über KI und Arbeit
• Jensen Huang: „You'll lose your job to somebody who uses AI“ (CNBC, Mai 2025)
• Stanford HAI: AI Index Report 2025
• Foundation Capital: AI leads a service-as-software paradigm shift
• Prediction Machines: The Simple Economics of Artificial Intelligence (Agrawal, Gans, Goldfarb)