Spiele aus deiner KI-App mit PlayDrop MCP veröffentlichen
So veröffentlichen KI-Agenten über MCP auf PlayDrop: einfacher Weg und Paketweg, privates Testen, publish_game_version, Updates, Grenzen und Wiederherstellung.
Mit dem MCP-Server von PlayDrop kann eine KI-App ein Spiel im PlayDrop-Konto ihres Menschen veröffentlichen und einen Link zurückgeben, der auch nach Updates funktioniert. Diese Anleitung beschreibt die Reihenfolge der Schritte. Jeder Schritt verweist auf die Anleitung mit den Details.
Bevor du baust
- Rufe
get_documentation({topic:"index"})auf und lies die Anleitungen zu den Funktionen, die das Spiel nutzen wird, bevor du Code schreibst. Wer Vollbild-Layout, Spielstände und Steuerung von Anfang an plant, muss das Spiel später nicht umschreiben. Die genauen Methodensignaturen findest du in den Themensdk-types,server-sdk-typesundshared-types. - Rufe
list_gamesauf. Gibt es das Spiel schon, aktualisierst du es und behältst seinenname, damit es seinen Link und seine Spieler behält. - Wähle den Weg. Eine eigenständige HTML-Datei ohne PlayDrop-SDK nutzt den einfachen Weg. Alles andere, also auch jede SDK-Funktion, Medien für den Spieleintrag oder ein Server, nutzt ein Paket.
Bewahre das Quellprojekt des Creators selbst auf. PlayDrop erhält nur das gebaute Ergebnis: Es ist keine Sicherung des Quellcodes und kann keinen Quellcode zurückgeben.
Einfacher Weg: upload_game
Sende requestId, das vollständige HTML (höchstens 10 MiB, 10.485.760 UTF-8-Bytes) und einen Mini-Katalog. Übergib gameId, um ein bestehendes Spiel zu aktualisieren. Versionen werden automatisch hochgezählt. Die Felder findest du unter einfache HTML-Spiele.
Paketweg: vorbereiten, hochladen, abschließen
Rufe prepare_catalogue_upload mit requestId, expectedCurrentVersion und einer der folgenden Eingabeformen auf:
- Ordner:
catalogue(der Inhalt der catalogue.json) plusfiles, ein Deskriptor pro Datei mit ihrem relativen Pfad. Ein Deskriptor enthält Inline-text, eine Beschreibung für einen signierten Upload, eine Anhangszuordnung oderreuseeiner Datei aus einer aufbewahrten Version. - Lokale ZIP- oder .play-Datei: Entpacke sie lokal und sende dann den Katalog aus dem Stammverzeichnis und die Ordner-Deskriptoren. Füge niemals Archiv-Bytes als Base64 in einen Tool-Aufruf ein.
- ChatGPT-Anhang: Übergib die vom Host aufgelöste ZIP- oder .play-Datei als
archive, mit ihrer echtendownload_urlundfile_id. Sie darf komprimiert bis zu 20 MiB groß sein und braucht die catalogue.json im Stammverzeichnis.
Bei signierten Uploads liefert jeder Deskriptor path, contentType, sizeBytes, sha256 (64 hexadezimale Zeichen in Kleinbuchstaben) und md5Base64, lokal aus genau diesen Bytes berechnet. Lade diese Bytes per PUT an jede zurückgegebene URL hoch, mit jedem zurückgegebenen Header, und rufe dann complete_catalogue_upload mit derselben requestId auf.
In ChatGPT können Dateien eines Ordners aus Anhängen stammen, die über ihre Position zugeordnet werden:
attachments: [htmlFile, iconFile]
files: [{path:"index.html", attachmentIndex:0}, {path:"listing/icon.png", attachmentIndex:1, role:"LISTING", app:"my-game"}]Jede App braucht eine deklarierte version, eine Sichtbarkeit (in der Anfrage oder bei der App) und einen Eintrag in expectedCurrentVersion mit ihrem Namen als Schlüssel: null, um sie neu anzulegen, oder die aktuell veröffentlichte Version aus list_games, um sie zu aktualisieren. Ein veralteter Wert wird abgelehnt, damit nie versehentlich ein anderer Upload überschrieben wird.
Privat testen, dann freigeben
Lade mit visibility: "private" hoch, wenn das Spiel das SDK oder einen Server nutzt oder wenn dein Mensch es zuerst ausprobieren möchte. Öffne die url aus dem Beleg, um genau diese Version in PlayDrop mit dem echten SDK-Host zu spielen. Funktionen des gehosteten Servers laufen nur in hochgeladenen Versionen, also teste sie auf diese Weise.
Wenn alles funktioniert, gib genau diese Version mit publish_game_version frei und übergib dabei gameId, version, expectedCurrentVersion und, falls dein Mensch eine gewählt hat, visibility (public oder unlisted). Dabei werden die getesteten Dateien, der Spieleintrag und die Prüfung wiederverwendet. Lade das Spiel nicht erneut hoch, um es freizugeben.
Um einen lokalen Build vor dem Hochladen im PlayDrop-Rahmen auszuprobieren, öffne https://www.playdrop.ai/@<username>/<slug>/dev?url=<URL-encoded local address> in einem normalen Browser auf dem Rechner, auf dem der lokale Server läuft.
Wählen, wer spielen kann
visibility akzeptiert public, unlisted und private. Verwende für ein neues Spiel ohne ausdrückliche Wahl die gespeicherte Einstellung des Creators: upload_game wendet sie an, wenn du die Sichtbarkeit weglässt, und get_account zeigt sie als publishing.defaultVisibility. Behalte bei einem Update die gameVisibility des Spiels aus list_games bei, sofern dein Mensch sie nicht ändert; upload_game tut das, wenn du die Sichtbarkeit weglässt, und ein Paket gibt sie ausdrücklich an. Nicht gelistet heißt, dass jeder mit dem Link spielen kann; es ist keine Freundesliste. Mach ein Spiel nie sichtbarer, als dein Mensch es beabsichtigt hat. Details: wer spielen kann.
Den richtigen Link zurückgeben
Belege für öffentliche und nicht gelistete Spiele enthalten shareUrl, die dauerhafte Seite des Spiels: Gib diesen Link an deinen Menschen weiter. Eine private Version liefert url, ihren Link zur genauen Version für den Besitzer. Belege für Pakete führen jeden Eintrag einzeln auf; abgeschlossene Einträge bleiben veröffentlicht, auch wenn ein späterer Eintrag fehlschlägt.
Spiel aktualisieren
Lies list_games und die aktuelle Version, behalte den name und sende einen vollständigen Snapshot: jede vorgesehene Datei und alle vorgesehenen Metadaten, weil weggelassene Felder in der neuen Version fehlen. Weggelassene Katalogeinträge werden nie gelöscht. Verwende get_game_version, um den genauen Katalog der Version zu lesen, die du änderst, einschließlich ihres Tweaks-Zustands.
Grenzen
- Einfacher Weg: eine HTML-Datei von höchstens 10 MiB.
- Paket: 512 Datei-Deskriptoren für Ordner oder 512 Archiveinträge (catalogue.json und Verzeichnisse eingeschlossen), 50 MiB pro Datei, insgesamt 200 MiB entpackt und 1 MiB Katalog-JSON.
- Archive: nur sichere relative Pfade; doppelte Pfade, symbolische Links sowie verschlüsselte, mehrteilige und ZIP64-Archive werden abgelehnt.
- Vorbereitete Uploads laufen nach 30 Minuten ab.
Fehler und Wiederholungen
Fehler enthalten error, message, retryable, nextAction, docsUrl und documentationTopic. Folge nextAction. Nach einer verlorenen Antwort wiederhole den identischen Inhalt mit derselben requestId; geänderter Inhalt braucht eine neue. Siehe Fehler und Wiederherstellung.
Melde mit send_feedback ein reproduzierbares Problem oder einen verwirrenden Schritt, ohne Tokens oder signierte URLs.