Publica juegos desde tu app de IA con el MCP de PlayDrop

1. Llama a get_documentation({topic:"index"}) y lee las guías de las funciones que usará el juego, antes de escribir código. Planificar desde el principio el diseño a pantalla completa, las partidas guardadas y los controles evita tener que reescribir el juego más adelante. Para las firmas exactas de los métodos, lee los temas sdk-types, server-sdk-types y shared-types.
2. Llama a list_games. Si el juego ya existe, lo actualizarás y conservarás su name, para que mantenga su enlace y sus jugadores.
3. Elige la vía. Un único archivo HTML autónomo sin el SDK de PlayDrop usa la vía simple. Todo lo demás, incluida cualquier función del SDK, las imágenes y vídeos de la ficha o un servidor, usa un paquete.

Guarda tú el proyecto fuente del creador. PlayDrop solo recibe el resultado compilado: no es una copia de seguridad del código fuente y no puede devolverlo.

Envía requestId, el HTML completo (10 MiB como máximo, 10.485.760 bytes UTF-8) y un minicatálogo. Pasa gameId para actualizar un juego existente. Las versiones aumentan automáticamente. Consulta juegos HTML simples para ver los campos.

Llama a prepare_catalogue_upload con requestId, expectedCurrentVersion y una de estas formas de entrada:

• Carpeta: catalogue (el contenido de catalogue.json) más files, un descriptor por archivo con su ruta relativa. Un descriptor lleva text en línea, la descripción de una subida firmada, la vinculación a un archivo adjunto o reuse de un archivo de una versión conservada.
• ZIP o .play local: descomprímelo en local y envía el catálogo raíz y los descriptores de la carpeta. Nunca pongas los bytes del archivo comprimido en base64 en una llamada a una herramienta.
• Archivo adjunto de ChatGPT: pasa como archive el ZIP o .play que resolvió el host, con sus download_url y file_id reales. Puede ocupar hasta 20 MiB comprimido y necesita catalogue.json en la raíz.

En las subidas firmadas, cada descriptor indica path, contentType, sizeBytes, sha256 (64 caracteres hexadecimales en minúsculas) y md5Base64, calculados en local a partir de los bytes exactos. Haz PUT de esos bytes a cada URL devuelta con todas las cabeceras devueltas y, después, llama a complete_catalogue_upload con el mismo requestId.

En ChatGPT, los archivos de la carpeta pueden venir de archivos adjuntos vinculados por posición:

attachments: [htmlFile, iconFile]
files: [{path:"index.html", attachmentIndex:0}, {path:"listing/icon.png", attachmentIndex:1, role:"LISTING", app:"my-game"}]

Cada app necesita una version declarada, una visibilidad (en la solicitud o en la app) y una entrada en expectedCurrentVersion con su nombre como clave: null para crearla, o la versión publicada actual de list_games para actualizarla. Un valor desactualizado se rechaza, así que nunca se sobrescribe otra subida por accidente.

Sube con visibility: "private" cuando el juego use el SDK o un servidor, o cuando tu usuario quiera probarlo primero. Abre la url del recibo para jugar a esa versión exacta dentro de PlayDrop con el host real del SDK. Las funciones del servidor alojado solo se ejecutan en versiones subidas, así que pruébalas de esta forma.

Cuando funcione, publica esa versión exacta con publish_game_version, pasando gameId, version, expectedCurrentVersion y, si tu usuario eligió una, visibility (public o unlisted). Reutiliza los archivos, la ficha y la revisión que se probaron. No vuelvas a subir el juego para publicarlo.

Para probar una compilación local en el marco de PlayDrop antes de subirla, abre https://www.playdrop.ai/@<username>/<slug>/dev?url=<URL-encoded local address> en un navegador normal en el equipo que ejecuta el servidor local.

visibility acepta public, unlisted y private. Para un juego nuevo sin una elección, usa el ajuste guardado del creador: upload_game lo aplica cuando omites la visibilidad, y get_account lo muestra como publishing.defaultVisibility. Para una actualización, conserva el gameVisibility del juego que indica list_games, salvo que tu usuario lo cambie; upload_game lo hace cuando omites la visibilidad, y un paquete lo indica. No listado significa que cualquiera con el enlace puede jugar; no es una lista de amigos. Nunca hagas un juego más visible de lo que pretendía tu usuario. Detalles: quién puede jugar.

Los recibos de los juegos públicos y no listados incluyen shareUrl, la página permanente del juego: esa es la que debes dar a tu usuario. Una versión privada devuelve url, el enlace a esa versión exacta para el propietario. Los recibos de paquete enumeran cada elemento; los elementos completados siguen publicados aunque falle uno posterior.

Lee list_games y la versión actual, conserva el name y envía una instantánea completa: todos los archivos y todos los metadatos que quieras incluir, porque los campos omitidos no estarán en la nueva versión. Los elementos del catálogo que omitas nunca se eliminan. Usa get_game_version para leer el catálogo exacto de la versión que vas a cambiar, incluido el estado de sus Tweaks.

• Vía simple: un archivo HTML de 10 MiB como máximo.
• Paquete: 512 descriptores de archivos de carpeta o 512 entradas de archivo comprimido (incluidos catalogue.json y los directorios), 50 MiB por archivo, 200 MiB descomprimidos en total y 1 MiB de JSON del catálogo.
• Archivos comprimidos: solo rutas relativas seguras; se rechazan las rutas duplicadas, los enlaces simbólicos y los archivos cifrados, de varias partes y ZIP64.
• Las subidas preparadas caducan a los 30 minutos.

Los errores incluyen error, message, retryable, nextAction, docsUrl y documentationTopic. Sigue nextAction. Tras una respuesta perdida, reintenta con el mismo contenido y el mismo requestId; si el contenido cambia, necesita uno nuevo. Consulta errores y recuperación.

Usa send_feedback para informar de un problema reproducible o de un paso confuso, sin tokens ni URL firmadas.