MCP Apps in Claude: App-Tools, Einstiegspunkte und eingebettete Websites, und welche davon deine Nutzer wirklich bekommen

Am 10. November hat Anthropic angekündigt, dass Claude jetzt mehr von der MCP-Apps-Erweiterung unterstützt: Eine App kann sich neben der Unterhaltung oder im Vollbild öffnen, Claude kann Tools aufrufen, die in der Oberfläche der App leben, und eine App kann die eigene Website des Anbieters einbetten. Adobe, Atlassian und Box gehörten zu den Beispielen zum Start. Für Entwickler nennt der Beitrag die neuen Funktionen eine Public Preview. Die stabile Spezifikation der Erweiterung ist weiterhin 2026-01-26. Geändert hat sich, wie viel davon Claude umsetzt.

Falls dir MCP Apps noch nicht begegnet sind: Ein Tool auf deinem MCP-Server verweist auf eine ui://-Ressource, und der Host rendert dieses HTML neben dem Textergebnis, im Web in einem sandboxed iframe. Die Grundlagen habe ich im Erklärtext zum Claude-Plugin-Verzeichnis beschrieben. Hier geht es um die drei neuen Funktionen, an denen Bedingungen hängen, und um einen Satz auf der Getting-started-Seite, den man leicht überliest.

Alle drei brauchen einen Remote-Server. Einstiegspunkte und eingebettete Websites hängen außerdem davon ab, wie dein Connector im Verzeichnis gelistet ist, und App-Tools und Einstiegspunkte (sowie eingebettete Websites auf einem Custom Connector) gibt es vorerst nur für einige Organisationen. Der Connector, mit dem du testest und den du per URL hinzufügst, erfüllt mehr dieser Bedingungen als die Installation, die deine Nutzer aus einem Community-Listing bekommen, und es gibt keinen Antrag auf das Verified-Label, der die Lücke schließen würde. Ich würde also zuerst für die Community-Installation planen und jede neue Funktion als Upgrade behandeln, das die App zur Laufzeit erkennt.

Alles Folgende stammt aus Anthropics Dokumentation, gelesen am 11. November, plus Befehlen, die ich lokal ausgeführt habe. Eine MCP App habe ich selbst noch nicht in Claude laufen lassen.

Was hat Claude am 10. November bei MCP Apps hinzugefügt?

Die Getting-started-Seite nennt sechs Funktionen: Seitenleiste und Vollbild, Einstiegspunkte über die Artifacts-Seite, App-Tools, Nachrichten von der App an Claude, eingebettete Websites und Downloads. Dieser Text behandelt drei davon.

App-Tools lassen die View (eine gerenderte Instanz deiner App) Tools registrieren, die Claude aufrufen kann, um zu ändern, was auf dem Bildschirm steht. Das Beispiel der Doku ist eine Einkaufsliste: Du bittest Claude, Milch hinzuzufügen, und die Milch erscheint in der Liste. Einstiegspunkte lassen Leute deine App über die Artifacts-Seite öffnen, ohne Claude darum zu bitten, und sie in der Seitenleiste anheften. Eingebettete Websites laden deine eigene Website in einem iframe innerhalb der View, sodass der Editor oder das Dashboard deines Produkts in Claude laufen kann. Die Seitenleiste hat eine eigene Prüfung auf Organisationsebene; die Getting-started-Seite nennt sie neben Einstiegspunkten und App-Tools.

Die Ankündigung spricht von Public Preview, die Doku sagt, App-Tools und Einstiegspunkte sowie eingebettete Websites auf Custom Connectors stehen „a limited set of organizations“ zur Verfügung. Ich lese das als dieselbe Sache aus zwei Blickwinkeln: Bauen kann jeder, sehen wird es noch nicht jeder Account.

Welche MCP-Apps-Funktionen in Claude brauchen einen Remote-Server oder ein Verified-Listing?

Alle drei brauchen einen Remote-Server, nur Einstiegspunkte und eingebettete Websites hängen vom Listing im Verzeichnis ab. Die Doku verteilt das auf vier Seiten, hier steht es an einem Ort:

„Unified Claude Experience“ ist die neue gemeinsame Oberfläche für Chat und Cowork. Laut Hilfeartikel hat ein Account sie nicht, solange das Eingabefeld noch die Wahl zwischen Chat und Cowork anbietet, und bei Team und Enterprise schaltet ein Owner sie unter Organization settings, Capabilities ein.

Ein lokaler Server, also einer in claude_desktop_config.json, bekommt keine der drei Funktionen, und die Doku sagt das auf der Seite jeder Funktion. Sie weist auch darauf hin, dass die Beispielserver, die sie dir mitgibt, lokal laufen. Nach diesen Regeln können dir die Demos nur die Inline-View zeigen, nichts aus dieser Tabelle.

Warum funktioniert eine MCP App im Claude-Test und scheitert bei Nutzern, die sie aus dem Verzeichnis installieren?

Weil der Connector, mit dem du testest, und der, den deine Nutzer installieren, verschiedene Arten von Connector sind, auch wenn sie auf denselben Server zeigen. Deinen fügst du per URL hinzu, also behandelt Claude ihn als Custom Connector. Ein Nutzer, der dein Community-Listing installiert, bekommt einen Verzeichnis-Connector, und die Getting-started-Seite sagt, was das kostet:

People who install your connector from a Community listing don’t get either
one, even if both worked while you tested with a custom connector.

„Either one“ meint Einstiegspunkte und eingebettete Websites. Die Seite zu Einstiegspunkten beschreibt genau diesen Fall: Du fügst deinen Server per URL hinzu, derselbe Server hat auch ein Community-Listing, und du behältst den Einstiegspunkt, während alle, die das Listing installiert haben, keinen haben.

Was als Custom zählt, wird pro Funktion entschieden, und die Seite zu eingebetteten Websites ist strenger als die zu Einstiegspunkten:

• Für eingebettete Websites zählt ein per URL hinzugefügter Connector nur dann als Custom, wenn seine Adresse zu keinem Listing im Verzeichnis passt. Richtest du deinen Test-Connector, nachdem du ihn gelistet hast, auf deine Produktions-URL, behandelt Claude ihn als Verzeichnis-Connector: Eine Website, die beim Testen lud, ist unter einem Community-Listing blockiert.
• Claude ignoriert den Query-String, wenn es eine Adresse einem Listing zuordnet, also ist ?build=next auf demselben Pfad immer noch der gelistete Connector. Stell einen Test-Build unter eine eigene Adresse.
• Ein Pfad mit einem Großbuchstaben, %, ; oder // zählt nicht als Custom, und Claude blockiert seine Origins. Ein Connector, der vor vielen Monaten hinzugefügt wurde, zählt womöglich auch nicht als Custom; die Lösung der Doku ist, ihn zu entfernen und neu hinzuzufügen.

Der Nutzer bekommt in keinem der Fälle eine Meldung. Laut Doku wird ein Einstiegspunkt, der die Bedingungen nicht erfüllt, ohne Fehler einfach nicht auf der Artifacts-Seite gelistet, und eine blockierte eingebettete Website lässt das iframe leer: „Claude shows no message“. Die App kann es allerdings herausfinden, und darauf baut der Fallback weiter unten.

Wie wird ein Claude-Connector Verified?

Beantragen kannst du es nicht. Laut der Seite zur Connector-Verifizierung wird ein eingereichter Server automatisch gescannt und standardmäßig als Community gelistet. Anthropic kann Listings, die es als besonders nützlich einstuft, dann an eine Verified-Prüfung weitergeben, in der ein Mensch jedes Tool testet:

That escalation is assessed automatically. There’s no separate application
for the Verified label, and you don’t need to take any action.

Da niemand es beantragen kann, plane so, als bliebe dein Listing bei Community. Ist deine App nur mit deinem eingebetteten Editor nützlich, liefert ein Community-Listing eine App aus, die nicht nützlich ist. Funktioniert die Inline-View für sich und ist die eingebettete Website ein Upgrade, bekommen Community-Nutzer ein kleineres Produkt, kein kaputtes.

Auch Verified klärt die Sache nicht endgültig. Das Listing muss jeden eingebetteten Origin erlauben, ein neu deklarierter Origin lädt also erst, wenn das Listing ihn ebenfalls erlaubt.

Wie berechnest du ui.domain für eine MCP App in Claude?

Nimm die ersten 32 Hex-Zeichen des SHA-256 deiner Server-URL und häng .claudemcpcontent.com an. Deklariere diesen Wert als _meta.ui.domain an der Ressource der View, wenn die App einen eigenen OAuth-Flow durchläuft, wenn deine Website Claude das Framing erlauben muss oder wenn die eingebettete Website localStorage zwischen Ladevorgängen behalten soll. Ohne ihn wechselt der Sandbox-Host zwischen Unterhaltungen. Die Doku liefert einen Node-Einzeiler:

node -e 'const yourServerUrl = "https://example.com/mcp"; console.log(require("crypto").createHash("sha256").update(yourServerUrl).digest("hex").slice(0,32) + ".claudemcpcontent.com")'

Unter Node 22.23.4 lässt sich das Beispiel der Doku reproduzieren (c3d80a4ed901ee05b21755a88273b4a4.claudemcpcontent.com). Für den eigenen schreibgeschützten MCP-Server dieser Website ergeben die zwei Schreibweisen der URL zwei verschiedene Werte:

https://max.nardit.com/mcp    2e8c4b9cbca6508f73a038113ef1c06b.claudemcpcontent.com
https://max.nardit.com/mcp/   922f395950b978b8d99c303db3fe7e4f.claudemcpcontent.com

Die Troubleshooting-Seite warnt genau davor: Der Hash deckt den ganzen String ab, einschließlich Schema, Pfad und abschließendem Slash, also hash die URL, die unter Customize, Connectors eingetragen ist. Bei einer Abweichung erscheint ui.domain mismatch statt der App. Ein lokaler stdio-Server hat keine URL zum Hashen, ui.domain steht für ihn also gar nicht zur Verfügung.

Leg csp, domain und permissions gemeinsam unter _meta.ui an das Content-Item, das dein resources/read-Handler zurückgibt. Ist _meta.ui dort gesetzt, ignoriert Claude die Kopie am Eintrag in resources/list.

Wie bettest du deine eigene Website in eine Claude MCP App ein?

Laut der Seite zu eingebetteten Websites: den Origin an der View deklarieren, Claude das Framing der Website erlauben und einen Fallback für den Fall bauen, dass Claude sie nicht lädt. Auf den Fallback ist eine Community-Installation angewiesen.

Deklarieren. Trag jeden Origin in _meta.ui.csp.frameDomains an der ui://-Ressource der View ein:

{
  "_meta": {
    "ui": {
      "csp": {
        "frameDomains": ["https://editor.example.com"]
      }
    }
  }
}

Einträge sind https-Origins: exakt, mit Port oder als Subdomain-Wildcard. Eine Wildcard deckt die nackte Domain nicht ab, und ein Eintrag mit Pfad oder abschließendem Slash gilt als nicht deklariert. Claude lehnt seine eigenen Domains ab, ebenso IP-Adressen, Namen aus privaten Netzen und Wildcards über ein gemeinsames Suffix wie *.co.uk.

Framing erlauben. Schränkt deine Website das Framing ein, muss ihr frame-ancestors sowohl https://claude.ai als auch deinen exakten Sandbox-Host enthalten. Browser prüfen jeden Frame oberhalb der Website, ein fehlender Eintrag blockiert sie also:

Content-Security-Policy: frame-ancestors https://<your-hash>.claudemcpcontent.com https://claude.ai

Die Doku warnt vor der Abkürzung: Eine Wildcard über claudemcpcontent.com lässt die MCP App jedes anderen Connectors deine Website framen.

Fallback. Nachdem app.connect() aufgelöst ist, lies die Liste der erlaubten Origins aus und entscheide, was du zeigst:

const allowed = app.getHostCapabilities()?.sandbox?.csp?.frameDomains;

Eine leere Liste oder eine, die deinen Origin nicht abdeckt, heißt, dass Claude ihn blockiert hat: Zeig einen Button, der die Website über ui/open-link in einem neuen Tab öffnet. In diesem Zweig landet eine Community-Installation. Fehlt die Liste ganz, hat Claude nichts gemeldet, also lade das iframe und lass den Button sichtbar.

Anmelden. Claude gibt der eingebetteten Website keine Session mit, ein Login in einem anderen Tab zählt nicht, und document.requestStorageAccess() wird abgelehnt. Der dokumentierte Weg: ein Server-Tool, das vor Claude verborgen ist, weil _meta.ui.visibility nur die App enthält, und ein kurzlebiges Einmal-Token zurückgibt; die View holt es mit app.callServerTool() und schickt es an den Frame und gibt dabei dessen exakten Origin als Ziel an; die Website tauscht es gegen ein Session-Cookie, gesetzt mit SameSite=None; Secure; Partitioned.

Ein erlaubter Origin hat zwei Kosten. Eine View mit einem solchen Origin verliert Kamera, Mikrofon, Standort und Schreibzugriff auf die Zwischenablage, und die Websites, die sie einbettet, ebenso, auch wenn du sie in _meta.ui.permissions anforderst. Rechne damit, dass die anderen Views des Connectors sie auch verlieren: bei einem Verzeichnis-Connector, sobald das Listing einen Origin erlaubt, bei einem Custom Connector überall dort, wo eingebettete Websites verfügbar sind. Und die iframe-Sandbox blockiert Pop-ups, alert() und Datei-Downloads, während confirm() false zurückgibt.

Wie deklarierst du einen MCP-App-Einstiegspunkt für Claude?

Markiere das Tool, das die View öffnet: Behalte ui.resourceUri in seinem _meta und füge einen openai/ui-Schlüssel hinzu, dessen entrypoints-Liste einen globalen Eintrag enthält. Die Seite zu Einstiegspunkten zeigt es so, wie es in tools/list erscheint:

{
  "name": "open_studio",
  "title": "Example Studio",
  "description": "Open Example Studio.",
  "inputSchema": { "type": "object" },
  "_meta": {
    "ui": { "resourceUri": "ui://example/home" },
    "openai/ui": { "entrypoints": [{ "type": "global" }] }
  }
}

Der Schlüssel stammt aus OpenAIs MCP-Erweiterungen, ein für das OpenAI Apps SDK gebautes Tool trägt ihn also womöglich schon; die erste Prüfung der Doku für so ein Tool ist, ob auch ui.resourceUri vorhanden ist. Die so geöffnete View startet ohne Anfrage und ohne Unterhaltung, also muss jede Eingabe optional sein und das leere Argumentobjekt einen brauchbaren Bildschirm ergeben. Lass _meta.ui.visibility ungesetzt oder mit model darin. Und achte auf den Tool-Namen: Zwei Unterstriche oder zwei Punkte hintereinander, oder ein Punkt neben einem Unterstrich, führen dazu, dass die App gelistet wird, sich aber nicht öffnen lässt. Aktualisiere nach einer Änderung die Tool-Liste unter Customize, Connectors oder warte bis zu etwa zwei Stunden.

Wie registrierst du ein MCP-App-Tool, das Claude aufrufen kann?

Im Skript der View, mit app.registerTool, vor app.connect(). Das SDK hat zwei Funktionen mit fast gleichem Namen: registerAppTool läuft auf deinem Server und registriert das Tool, das die View öffnet; app.registerTool läuft in der View und registriert ein Tool, das Claude aufrufen kann, solange die View offen ist.

Das meiste, wovor die Seite zu App-Tools warnt, scheitert für die ganze View, nicht für ein einzelnes Tool:

• Ein schlichtes JSON-Schema-Objekt, an app.registerTool übergeben, lässt tools/list der View scheitern, was jedes Tool darin verbirgt. Die Methode will ein Schema-Objekt aus einer Bibliothek, die Standard Schema mit JSON-Schema-Ausgabe implementiert, etwa zod ab 4.2; außerdem brauchst du @modelcontextprotocol/ext-apps ab 1.7.0 (veröffentlicht am 21. April; aktuell ist mit Stand 11. November 2.0.4).
• Ein Input-Schema ohne type: "object" an der Wurzel, mehr als 64 Tools oder mehr als 1 MiB an Definitionen, und Claude kann keines der Tools der View nutzen.

Willst du JSON Schema selbst schreiben oder lädst du das SDK von einem CDN, nimm stattdessen die Handler onlisttools und oncalltool, übergib { tools: { listChanged: true } } als zweites Argument an den App-Konstruktor und validiere die Argumente, denn die Handler tun es nicht.

Ein Aufruf hat 45 Sekunden, die Zeit für die Freigabe nicht mitgerechnet; für längere Arbeit startest du sie, kehrst zurück und registrierst ein zweites Tool, das das Ergebnis meldet. Claude listet jedes Tool mit seinem Namen und der ersten Zeile seiner Beschreibung, bis zu 200 Zeichen, also mach diese Zeile vollständig.

Die Freigabe folgt der Tool-Definition. Die Abfrage nennt den Connector und den title des Tools, und Always allow gilt für das Tool in genau dieser Definition, also kann eine Änderung an Name, Titel, Beschreibung oder Schema die Abfrage zurückbringen. Halte Definitionen konstant und leg wechselnde Werte in die Ergebnisse.

Eine Asymmetrie erwähnt die Doku nebenbei: Wenn deine View die Tools deines eigenen Servers mit app.callServerTool aufruft, sieht der Nutzer überhaupt keine Abfrage. In meinem WebMCP-Text habe ich eine Tool-Liste eine Schnittstelle genannt, keine Grenze; App-Tools sind dieselbe Idee innerhalb von Claude. Die Abfrage deckt ab, worum Claude die View bittet. Was die View danach mit deinem Server macht, entscheidet dein Code, und die Autorisierung dafür gehört weiterhin auf den Server.

Wie testest du eine MCP App für Claude vor dem Release?

Solange das Listing nicht existiert, kannst du die Installation deiner Nutzer nur simulieren, also simulier sie bewusst. Ein Plan auf Basis der Doku:

1. Betreib den Server remote (ein getunnelter lokaler Server zählt als Custom), unter einem klein geschriebenen Pfad, mit einer eigenen Adresse pro Build.
2. Füg ihn als Custom Connector hinzu und teste im Web in einer Unterhaltung mit der Unified Experience, die Berechtigungseinstellung auf Manual, damit du jede Freigabe siehst.
3. Öffne die App in einer Nachricht und bitte in der nächsten um eine App-Tool-Aktion. Claude bekommt die Tools einer neuen View mit deiner folgenden Nachricht.
4. Tauchen App-Tools, Einstiegspunkte oder eingebettete Websites nicht auf und erklärt nichts anderes das, ist deine Organisation womöglich nicht im Rollout. Der Rat der Doku: die App ohne sie funktionsfähig halten und später testen.
5. Spiel den Community-Fall bewusst durch: Erzwing den Zweig mit leerem frameDomains, entferne den Einstiegspunkt und prüf, ob das, was übrig bleibt, die Installation noch wert ist.
6. Wenn das Listing live ist, richte einen per URL hinzugefügten Connector auf die gelistete Adresse. Nach der Regel zu eingebetteten Websites oben zählt er dann nicht mehr als Custom, und du siehst, was eine Installation aus dem Verzeichnis sieht.

Zum Debuggen: Das SDK loggt seine Protokollnachrichten mit console.debug, in Chrome brauchst du also die Stufe Verbose. Für eingebettete Websites sagt der Troubleshooting-Abschnitt, du sollst nach einer Konsolenzeile suchen, die mit [mcp-ext-apps-host] beginnt und frameDomains nennt: Dort meldet Claude, was es mit deinen Origins gemacht hat.

Was das MCP-Apps-Update vom November für Server-Autoren ändert

Nach der Lektüre der Doku würde ich eher um die Bedingungen herum planen als um eine einzelne API. Wie dokumentiert, hat die Inline-View keine Bedingung ans Listing, die neuen Funktionen schon. Eine App hat jetzt mehrere Formen, pro Nutzer ausgewählt durch Bedingungen, die du nicht steuerst, und der Nutzer erfährt nicht, welche Form er bekommen hat. Bau zuerst die kleinste Form: die Inline-View, ohne App-Tools, ohne eingebettete Website, lauffähig von einem lokalen Server. Füg jede Funktion als Upgrade hinzu, das sich selbst prüft: frameDomains zurückgelesen, App-Tools optional und ein brauchbarer leerer Zustand für Einstiegspunkte.

Diese Website betreibt unter /mcp einen kleinen Remote-MCP-Server: schreibgeschützte Tools, keine Anmeldung, keine UI-Ressource, seit dem 8. Oktober in Betrieb. Gäbe ich ihm eine View, würde er laut Tabelle die Remote-Server-Bedingung für alle drei Funktionen erfüllen, und ein Nutzer, der ihn als https://max.nardit.com/mcp hinzufügt, bräuchte den oben berechneten Wert 2e8c4b9c…. Mehr kann der Server darüber kaum wissen. Welche Form der App ein bestimmter Nutzer bekommt, hängt von seiner Organisation, seiner Oberfläche und davon ab, wie er den Connector installiert hat, und nichts davon erreicht den Server.