Plateforme Runway Dev

Workflow durable pour intégrer les produits Runway Dev dans une application. MCP fournit l'état du compte en temps réel, le SDK est le chemin d'intégration applicatif, et llms.txt pointe vers les guides de configuration actuels et les références API.

Quand l'utiliser : Construction, modification, débogage ou vérification d'une intégration Runway, incluant les travaux commencés depuis le Dev Portal.

À ne pas utiliser pour : génération de média ponctuelle depuis l'agent ou actions CLI REST directes.

Avant de commencer

1. Connectez Dev MCP si les outils manquent. Serveur : https://dev.runwayml.com/mcp. OAuth via compte développeur Runway — ne mettez jamais de clé API dans la config MCP. Terminez la connexion dans le navigateur de l'utilisateur ; n'automatisez pas OAuth. Docs : https://docs.dev.runwayml.com/guides/mcp
2. Récupérez https://docs.dev.runwayml.com/llms.txt et suivez les docs liées — n'inventez pas d'endpoints ou de noms de champs.
3. Inspectez l'espace de travail. Projet existant → trouvez sa limite backend et son point d'intégration orienté utilisateur ; demandez où connecter Runway si ce n'est pas clair. Projet vide → demandez ce qu'il faut construire ; proposez une petite app web avec des entrées visibles et une sortie.
4. Utilisez le SDK officiel. Installez @runwayml/sdk pour Node ou runwayml pour Python si le projet ne l'a pas déjà.

Contexte MCP

1. whoami — vérifiez l'identité.
2. list_projects — choisissez un projet ; ne devinez jamais un projectId.
3. Pour la génération : list_models avec l'endpoint cible. Respectez les inputConstraints de chaque modèle ; ne réutilisez pas les valeurs d'un autre modèle.
4. get_credit_balance avant un test facturable.

Clé API (SDK uniquement)

MCP utilise OAuth. Les appels SDK de génération utilisent RUNWAYML_API_SECRET en env côté serveur ou dotenv — jamais côté client, jamais en chat, jamais en dur. Demandez à l'utilisateur de l'ajouter quand l'appel SDK est imminent.

Requêtes SDK

1. Construisez une requête SDK valide à partir des docs API liées par llms.txt et les contraintes MCP list_models.
2. Chaînez le helper d'attente directement depuis l'appel de création : await client.<operation>.create({...}).waitForTaskOutput() en Node ou client.<operation>.create(...).wait_for_task_output() en Python. N'attendez pas create() avant d'appeler le helper.
3. Capturez la TaskFailedError du SDK et affichez ses détails de tâche. Soumettez une seule fois ; n'ajoutez pas de boucle de polling manuel ou de renvoi automatique.
4. Utilisez MCP get_task uniquement pour inspecter ou déboguer une tâche existante en dehors du flux SDK de l'application.
5. Connectez la sortie réussie à l'interface utilisateur ou au consommateur destiné de l'application. Persistez les sorties si l'app en a besoin après l'expiration des URLs signées (~24–48h).

Terminologie

Erreurs

• Erreur de validation → affichez le message, corrigez le champ à partir des contraintes MCP ou des docs, réessayez une fois.
• Auth/permission → arrêtez ; demandez à l'utilisateur de s'authentifier ou choisir un projet accessible.
• Rate limit → respectez l'intervalle de retry.
• Tâche FAILED → signalez les détails de l'échec ; ne renvoyez pas automatiquement.
• Outil MCP manquant → n'inventez pas de fallbacks REST pour la gestion de compte.

Compétences de surface

Utilisez +runway-dev avec la compétence de surface appropriée ou les compétences quand toutes deux sont installées. Les compétences de surface répètent leur setup minimal pour rester utiles quand installées seules. Généralement une surface correspond à l'objectif de l'utilisateur ; chargez-en plus quand la tâche traverse les surfaces.