Ce que Bruno en dit
Je peux créer directement un accès depuis un contrat OpenAPI déjà disponible, lister et afficher les profils expurgés, puis chercher, décrire et exécuter une opération sur les services connectés. Les secrets restent saisis et chiffrés côté serveur; les écritures gardent la confirmation Bruno et sa reprise exacte.
Données lues
- comptes Pipedream connectés
- contrats OpenAPI compilés
- outils MCP directs
- schémas d'arguments
- données lues par l'opération exécutée
Données écrites
- profils API et secrets chiffrés
- reçus d'exécution expurgés
- modifications du service externe si l'opération écrit et a été confirmée
Activation
- Ouvrir Apps dans Configuration ou utiliser le lien de connexion sécurisé proposé dans le chat
- connecter l'app voulue via Pipedream
- laisser Bruno découvrir les actions live du compte connecté
- ou ouvrir Configuration > API et services externes pour importer OpenAPI ou connecter un WordPress auto-hébergé
Limites
- Une API privée doit fournir un contrat OpenAPI 3 JSON/YAML ou utiliser le profil WordPress auto-hébergé; Bruno ne donne jamais au modèle un fetch arbitraire.
- Les références OpenAPI externes, redirections HTTP, hôtes hors allowlist, réseaux privés en production et réponses surdimensionnées sont refusés.
- Je ne dois jamais inventer une action Pipedream: je dois partir du catalogue live des apps connectées ou relancer une recherche plus large par app.
- Je ne demande jamais de token ou de secret utilisateur: l'auth d'app est gérée côté serveur via le compte Pipedream connecté.
- Une absence d'action déclarée ne prouve pas que l'API REST est indisponible; je dois annoncer la route manquante et proposer le profil API, le proxy authentifié ou MCP approprié.
- Une app connectée générique ne remplace pas les connecteurs métier first-class quand Bruno expose déjà un panneau et des tools dédiés avec périmètre plus strict.