Mike Bild
Blog

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.

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

Diesen Beitrag anhören (16 Min.)

MP3 herunterladen

Aktualisierung: Die Produktpassagen dieses Artikels wurden am 17. August 2026 gegen die genannten Repository-Stände geprüft und entsprechend überarbeitet.

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

Das Beispiel ist kein Gedankenexperiment. Stand August 2026 stellt ContentKit unter /mcp eine domänenorientierte Werkzeugoberfläche bereit, die über dieselbe Veröffentlichungsdomäne läuft wie REST und das Web-Cockpit. WikiKit, WatchKit und WorkKit bieten ebenfalls Remote-MCP und liefern jeweils ein eigenes Web-Cockpit mit dem Produkt aus. 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. Bei ContentKit greifen Cockpit, HTTP und MCP 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. Bei ContentKit und WikiKit sind Werkzeuge, die der aktuelle Principal nicht verwenden darf, gar nicht erst in der Liste sichtbar. Der Agent entdeckt also nur Fähigkeiten, die seine Scopes hergeben. Und wo dort 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 vom Cockpit 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 den hier beschriebenen Remote-MCP-Zugängen sind diese Aufgaben verteilt: Die Zustimmung des Nutzers vor einem Tool-Aufruf ist nach der MCP-Spezifikation Sache des Hosts, während die Produkte jeden Aufruf serverseitig gegen die Scopes des Principals prüfen.

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 Cockpit 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 Cockpits passiert

Die stärkste Version der Zukunftsthese lautet: Wenn Agenten Software bedienen, werden GUIs zweitrangig. Ich halte das für falsch, und die genannten Produkte widersprechen ihr in der Praxis: Jedes von ihnen liefert Stand August 2026 ein eigenes Web-Cockpit aus.

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. Das Cockpit dient dazu, dass ein Mensch versteht, was ein Agent getan hat, und dort eingreift, wo sein Urteil gefragt ist. Bei ContentKit und WikiKit kommt hinzu, dass menschliche Freigaben nicht vom Agenten geliefert werden – sie bleiben ein eigener Schritt außerhalb seiner Reichweite.

Cockpit und MCP konkurrieren also nicht um dieselbe Aufgabe. Das Cockpit 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. Für die hier beschriebenen Produkte gilt Stand August 2026: 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

Wie fandest du diesen Beitrag?

Kommentare