Strukturierter Input und gestalteter Output in Claude

Am 10. November hat Anthropic die Unterstützung der MCP Apps Extension in Claude angekündigt. Das Model Context Protocol (MCP) ist der offene Standard, über den Agents die Tools anderer Anwendungen nutzen. Mit seiner Extension MCP Apps bringt ein Tool eine eigene interaktive View mit, die Claude direkt im Chat anzeigt. Die Extension steht in populären Frameworks zur Verfügung.

Für .NET nutzt der Proof of Concept dieses Artikels das Package für MCP Apps aus dem offiziellen C# SDK. Für Node und TypeScript liefert das SDK der Extension selbst Helpers für den MCP Server. Das offizielle Python SDK bringt die Extension eingebaut mit. FastMCP unterstützt sie in Python über seine Interactive Tools. Im offiziellen Go SDK sind laut seinen Maintainern alle Primitives für MCP Apps vorhanden.

Für mich ist das ein lang erwartetes Feature. Ich experimentiere mit MCP Apps, seit die Extension zum ersten Mal angekündigt wurde. Einen echten Business Case gab es dafür lange nicht, weil den AI Chat Clients die Unterstützung fehlte.

Meine gesamte Büroarbeit habe ich an AI ausgelagert. Ein Use Case davon ist die Verwaltung meiner Eingangs- und Ausgangsrechnungen in Vouchers AI , über den Connector der Anwendung in Claude. Connectors verbinden Claude mit dem MCP Server einer Anwendung. Für die Verbindung zu meinen Mails in Microsoft 365 nutze ich Work IQ, den Layer von Microsoft über Mail, Kalender, Chats und Dateien eines Microsoft 365 Tenants. Mit der MCP Apps Extension wird mein Data Handling in der Claude App strukturierter.

Beim Buchen von Eingangsrechnungen sucht Claude die Rechnungen im Postfach, liest jeden Anhang, prüft die Buchhaltung auf ein Duplikat, schlägt ein Konto vor und zeigt eine Vorschau der Buchung. Dann fragt der Agent, ob er buchen soll, und wartet auf ein Ja im Textfeld. Bei sechs Rechnungen kommt diese Frage sechs Mal, jedes Mal mit einem Ja im Text als Antwort.

Dieser Artikel und ein Proof of Concept sind gemeinsam entstanden. Ich habe Vouchers AI um drei Views erweitert, ausgewählt nach meiner tatsächlichen Nutzung, und sie in claude.ai getestet. Eine der drei legt alle Rechnungen auf einen Bildschirm, jede mit ihrem eigenen Button zum Buchen.

MCP Apps im Chat mit Claude

Eine MCP App besteht aus einem Tool, einer View mit einer Adresse, die mit ui:// beginnt, und dem HTML dieser View. Ruft Claude das Tool auf, holt Claude die View vom MCP Server und zeigt sie in einer Sandbox, einem abgeschirmten Frame, direkt beim Ergebnis des Tools. Über Claude spricht die View mit dem MCP Server. Dabei ruft die View dessen Tools selbst auf, lädt neue Daten und meldet dem Modell, was in ihr geschehen ist.

Die bestehenden Tools bleiben dabei, wie sie waren. Claude Code zeigt keine View und ruft dasselbe Tool als Text auf. In meiner Buchhaltung bucht, sucht und berichtet Claude Code deshalb weiter über die bisherigen Tools. Jedes der drei neuen Tools nennt sie in seiner Description, dem Text, nach dem Claude ein Tool auswählt. Das zählt bei mir doppelt: 640 der 1.073 Tool Calls, die ich ausgewertet habe, kamen aus Claude Code.

Die Regel dahinter stammt aus einem früheren Versuch. Auf einem ähnlichen MCP Server listete claude.ai ein Tool mit Formular als Interactive UI tool und meldete beim direkten Tool Call „Tool not found“. Seitdem gilt bei mir: Eine View ist nie der einzige Weg zu einer Funktion. Ein einfaches Tool erledigt dieselbe Arbeit mit einem Tool Call. Welche Arbeit eine View bekommt, entscheidet die Häufigkeit.

Use Cases aus drei Monaten Tool Calls

Eine View lohnt sich dort, wo dieselbe Arbeit oft wiederkehrt. Wie oft das geschieht, zeichnet der MCP Server selbst auf: Jeder Tool Call an meinen MCP Server schreibt eine Zeile in eine Tabelle, mit Tool, Zeitpunkt, Dauer, Ergebnis und Client. Ruft der Agent ein Tool auf, heißt dieser Schritt Tool Call; der Client ist die Anwendung, in der der Agent läuft. Von August bis November kamen so 1.073 Tool Calls zusammen.

182 davon kamen über den Connector in claude.ai, 251 ohne Namen eines Clients. Claude Desktop nutzt denselben Connector wie claude.ai, deshalb lassen sich die beiden in der Tabelle nicht trennen. Die Auswertung fasst die Tool Calls zu Sessions zusammen, mit einer neuen Session nach 30 Minuten Pause. Das ergab 62 Sessions, im Median mit acht Tool Calls, die längste mit 201.

Die Reihung nach Tool Calls ist eindeutig. Ganz vorn steht das Buchen von Lieferantenrechnungen aus dem Postfach, mit 434 Tool Calls an 30 Tagen in 37 Sessions. Danach folgen das Suchen und Prüfen von Belegen mit 308 Tool Calls an 31 Tagen in 45 Sessions und die Zahlen einer Periode mit 247 Tool Calls an 15 Tagen in 21 Sessions. Ausgangsrechnungen kamen auf 31 Tool Calls an zwei Tagen, Todos auf 10 an fünf Tagen. Routinen, die an 18 Tagen nach Zeitplan liefen, arbeiten unbeaufsichtigt. Eine View sähe dort niemand, deshalb zählen sie für diese Auswahl nicht.

Aufschlussreicher als die Summe ist die Reihenfolge. Beim Buchen folgte 103 Mal das Lesen eines Rechnungsdokuments direkt auf das Lesen des vorigen. Zwischen Vorschau und Buchung stand ein Ja im Text, eine Rechnung nach der anderen. Bei der Suche folgte 90 Mal eine Suche auf eine Suche und 82 Mal ein Beleg im Detail auf den nächsten. Die Zahlen einer Periode bilden die größte Gruppe unter den Tool Calls aus claude.ai und ohne Namen eines Clients. Insgesamt folgte 86 Mal ein Tool Call für die Zahlen einer Periode direkt auf den vorigen.

Wo derselbe Tool Call Schlag auf Schlag wiederkehrt, blättert ein Mensch im Text durch Daten, die auf einen Bildschirm passen. Aus den drei häufigsten Arbeiten wurden deshalb drei Views: eine Buchungsübersicht, eine Belegsuche und eine Periodenübersicht.

Drei Views für die häufigste Arbeit

Hinter jeder der drei Views steht ein eigenes Tool. Sobald ein Prompt nach dieser Arbeit fragt, öffnet Claude die passende View über ihr Tool.

Die Buchungsübersicht

Die Buchungsübersicht öffnet Claude, nachdem der Agent die Rechnungen aus dem Postfach gelesen hat. Jede Rechnung erscheint als eigene Karte mit dem Konto als Auswahl und mit Datum, Text, Buchungstext, Netto und Umsatzsteuer als Felder, die sich ändern lassen. Ein mögliches Duplikat steht direkt auf der Karte. Jede Änderung schickt die Zeile erneut durch die Vorschau der Buchung.

Der Button Buchen auf jeder Karte ruft das bestehende Tool zum Buchen auf, passend zum Booking Mode, dem Setting, das festlegt, ob ein Beleg direkt geschrieben wird oder auf ein Ja wartet. Nach einer Buchung meldet die View dem Modell, welche Belege gebucht sind, damit Claude keinen davon ein zweites Mal bucht. Die Entscheidung je Rechnung fällt mit einem Klick auf ihrer eigenen Karte.

Die Belegsuche

Die Belegsuche hat ein Suchfeld, einen Filter für das Jahr und eine Liste der Treffer. Ein Klick auf einen Treffer öffnet die Details des Belegs mit seinen Buchungszeilen in einem Panel darunter. Eine neue Suche entsteht direkt in der View, ohne neue Nachricht an Claude.

Die Periodenübersicht

Die Periodenübersicht zeigt die Zahlen eines Jahres oder eines Monats in Kacheln: Einnahmen netto, Ausgaben netto, Ergebnis und offene Beträge. Darunter stehen Balken für jeden Monat des Jahres und die größten Kategorien bei Einnahmen und Ausgaben. Ein Klick auf einen anderen Monat lädt alle Zahlen aus der View heraus neu, über vier bestehende Tools des MCP Servers. Wie sich die drei Views in claude.ai verhalten, zeigte der Test.

Der Test in claude.ai

Nach dem Deploy listet claude.ai die drei neuen Tools des Connectors in einer eigenen Gruppe, Interactive tools, voreingestellt auf Needs approval. Daneben stehen die Gruppen Read-only tools und Other tools. Im Manual Mode fragt Claude vor dem Öffnen einer View um Erlaubnis.

Auf die Bitte um die Periodenübersicht für Oktober zeigte Claude die View im Chat, mit dem Oktober ausgewählt. Ein Klick auf September lud Kacheln, Balken und Kategorien aus der View heraus neu, ohne neue Nachricht und ohne Freigabe. In der Belegsuche brachte eine neue Suche in der View neue Treffer. Der Klick auf eine Zeile lud das Panel mit den Details und ließ die View mitwachsen.

Für die Buchungsübersicht bat der Prompt Claude, die Rechnungen des Monats aus dem Postfach zu lesen und die Übersicht zu öffnen, mit dem Zusatz: „Nichts buchen, ich buche selbst in der Übersicht.“ Claude las das Postfach und öffnete die View mit sechs Rechnungen. Jede Karte zeigte ihr Duplikat, denn alle sechs standen in der Buchhaltung. Gebucht wurde nichts. Den Button Buchen hat im Test mit echten Daten niemand gedrückt, mit Absicht.

Unter der View schrieb Claude eine eigene Analyse. Der Agent hielt fest, dass alle sechs Rechnungen gebucht sind und dass Buchen im Booking Mode Auto sofort ein Duplikat schreiben würde. Er fand ein falsch verknüpftes Todo auf einer Karte, einen Wechselkurs vom falschen Tag und eine Rechnung mit einem Datum im Oktober. Dazu nannte er die Mails, die er ausgelassen hatte: eine Auftragsbestätigung, eine Rechnung über null Euro und eine Ausgangsrechnung.

Öffnet man das Gespräch später wieder, baut Claude die View neu aus ihrem HTML auf. Die Belegsuche kam dabei kleiner zurück, mit eigener Scrollbar, und wuchs nach der nächsten Suche wieder. Was eine View beim erneuten Öffnen wieder zeigen soll, gehört deshalb auf den MCP Server.

Der Text des Agents neben der View

Claude schreibt zu jeder View Text. In der Belegsuche wiederholte der Agent die Treffer als Tabelle, auf Englisch. Im Gespräch über die Buchungsübersicht fand sein Text, was die View allein nicht zeigt, darunter das falsch verknüpfte Todo.

Dieses Todo war ein Fehler der View. Die View verknüpfte offene Todos über den Namen des Lieferanten und hängte so eine Rechnung an das Todo für eine andere, fehlende Rechnung desselben Lieferanten. Ein Klick auf Buchen hätte dieses Todo irrtümlich geschlossen. Seit der Korrektur braucht ein Todo auf der Karte seine ID in der Zeile.

Eine zweite Korrektur betraf die Periodenübersicht. In der ersten Fassung kamen ihre Balken aus einer anderen Query als die Kacheln und zeigten für einen Monat mehr als das Doppelte der Kachel darüber. Balken und Kacheln lesen inzwischen aus derselben Monatsübersicht.

Planen Sie den Text des Agents deshalb fest neben der View ein. Er prüft, was hinter den Zahlen der View steht, und fängt Fehler ab, die eine Karte allein nicht zeigt.

Die eigene Website in einer View

Kurz vor diesem Test schrieb Sean Strong von Anthropic auf X: „You can now embed your website in Claude and have it be interactable. You can do this via MCP apps, where we’ve enabled frame_domains support for verified plugins.“ Gemeint ist die Website eines Produkts, die eine View in einem Frame lädt, etwa der Editor oder das Dashboard der Anwendung. Die View deklariert dafür jede Domain der Website in frameDomains. Laden darf sie die Website, sobald Claude diese Domains für den Connector freigibt.

Ein Connector aus dem Connectors Directory braucht laut der Dokumentation von Claude ein Verified Listing, das die Domain erlaubt. Bei einem Custom Connector, den ein User über seine URL hinzufügt, fragt Claude im Gespräch, ob der User die Domains erlaubt. Diese Möglichkeit gibt Claude derzeit einem begrenzten Kreis von Organisationen, in ausgewählten Gesprächen.

Für den Test bekam der MCP Server eine vierte MCP App. Ihre View lädt die Web App der Buchhaltung in einem einzigen Frame und deklariert deren Domain in frameDomains. Nach dem Deploy kannte der Agent das neue Tool zunächst nicht: In einem neuen Chat antwortete Claude, der Connector habe kein solches Tool, und öffnete die Periodenübersicht. Erst nach Refresh tools list unter Customize > Connectors konnte Claude das Tool in einem neuen Chat aufrufen. Die View erschien dann als leeres graues Panel.

Die Console von claude.ai nannte den Grund: Die Domain der Web App sei „Not among the sites that Claude allows this connector to show“. Für meinen Custom Connector in meinem Account zeigt Claude die Website damit nicht in der View. Das deckt sich mit dem Post, der frame_domains für Verified Plugins nennt, und mit der Dokumentation von Claude. Views, die keine Website einbetten, zeigt Claude bei jedem Connector im Chat, so wie die drei Views dieses Tests auf demselben Connector.

Der erste Schritt mit MCP Apps

Drei Schritte passen in diese Woche:

1. Zählen Sie, welche Arbeit Ihre Mitarbeiter im Chat mit Ihrer Anwendung am häufigsten erledigen. Loggt Ihr MCP Server seine Tool Calls, liefert eine Auswertung nach Sessions und nach aufeinanderfolgenden Tool Calls die Reihung.
2. Wählen Sie die Arbeit, in der derselbe Tool Call Schlag auf Schlag wiederkehrt oder ein Mensch Zeile für Zeile zustimmt. Dafür lohnt sich die erste View. Die bestehenden Tools bleiben für Clients ohne MCP Apps.
3. Testen Sie die View mit einem Custom Connector in claude.ai, mit echten Daten und ohne schreibenden Klick, bis der Text des Agents und die View dasselbe sagen.

integrations.at begleitet diesen Schritt mit dem Service Komplette Integration für Unternehmen, die ihre Anwendung über einen eigenen MCP Server mit Claude verbinden.

Entstehung des Artikels

Alexander Kastil hat den Proof of Concept und diesen Artikel als ein Vorhaben in drei Teilen beauftragt. Agents in Claude Code haben die Tool Calls seiner Buchhaltung ausgewertet, die drei Views und die eingebettete Web App gebaut, deployt und in seinem Account in claude.ai getestet. Die Angaben zu Claude und zur eingebetteten Website stammen aus der Dokumentation von Claude und dem Repository der MCP Apps Extension. Der Text entstand mit AI-Unterstützung.