Apporter du contexte via MCP
C'est le premier des deux cas d'usage MCP : l'assistant de chat lit depuis un outil externe et utilise ce qu'il trouve pour nourrir le contenu qu'il rédige. Tu es en train de rédiger quelque chose dans un Epic Glowtify — un email, un post, une publicité — et tu veux que l'IA s'appuie sur des données réelles tirées d'une de tes autres apps avant de générer. Pense aux chiffres de MRR Stripe dans un récap trimestriel, à une vraie citation client d'Intercom dans un témoignage, ou aux dernières notes de release de Linear dans un email de lancement.
La surface publiée reste un canal natif Glowtify. MCP permet juste à l'assistant de jeter un œil aux données dont il a besoin pendant qu'il rédige.
Quand ça vaut le coup
Quelques scénarios concrets où un context provider fait vraiment la différence :
- Email de récap trimestriel — récupère le MRR et les top deals depuis Stripe et HubSpot pour que les chiffres dans l'email soient les vrais chiffres.
- Témoignage client — cite un feedback utilisateur réel depuis Linear ou Intercom plutôt que de paraphraser de mémoire.
- Annonce LinkedIn — référence les vrais chiffres de signups depuis ton outil d'analytics, pas un vague "des milliers d'utilisateurs".
- Email de lancement produit — récupère les release notes que tu as écrites dans Notion ou Linear et laisse l'IA les traduire en langage marketing.
- Campagne de relance commerciale — vérifie le statut du deal dans ton CRM en amont pour éviter que le message ne contredise où en est vraiment la relation.
Quelles apps sont de bons context providers
Le catalogue Composio est profond — voici les catégories qui ont du sens pour les flows de contexte :
- CRM — HubSpot, Salesforce, Pipedrive
- Project trackers — Linear, Jira, Asana, Trello
- Docs et knowledge bases — Notion, Confluence, Google Docs
- Communication — Slack, Gmail
- Analytics et billing — Stripe, Mixpanel, PostHog, Google Analytics (via MCP si tu le veux dans le chat — le connecteur natif reste la bonne réponse pour les dashboards)
Si la donnée que tu cherches vit ailleurs, parcours composio.dev/toolkits — il y en a plusieurs centaines d'autres.
Brancher un context provider en 4 étapes
- Va dans Connectors → onglet MCP → parcours le catalogue ou cherche l'app voulue.
- Clique sur Connect → suis le flow OAuth Composio → accorde uniquement les scopes read. Sois délibéré ici — voir la section read-only plus bas.
- Ouvre un Epic → démarre une conversation → active l'app MCP dans le picker MCP du chat. Maximum 3 apps actives par conversation.
- Dans ton brief ou ton message de chat, demande la donnée explicitement. Par exemple "récupère les deals ouverts depuis HubSpot avant de rédiger" ou "vérifie les derniers tickets de support sur Zendesk pour identifier les plaintes principales". Un brief vague = un appel d'outil vague (ou pas d'appel du tout).
Comment l'assistant décide d'appeler l'outil
Le modèle utilise les signaux de ton brief et du reste du chat pour décider s'il invoque un outil. Une demande spécifique ("récupère les 5 deals les plus récents depuis HubSpot") déclenche presque toujours l'appel. Un brief vague ("écris un truc bien sur notre croissance") presque jamais — le modèle ne sait pas vers quel outil se tourner.
Si tu as branché l'outil et que l'assistant ne l'a pas utilisé alors que tu t'y attendais, reformule ton prompt pour l'appeler explicitement. Les majuscules aident : "UTILISE l'outil HubSpot pour récupérer les deals ouverts en premier."
Le read-only, ton ami
Quand tu fais l'OAuth dans Composio, tu choisis ce que l'assistant est autorisé à faire en ton nom. Pour les cas d'usage de contexte, accorde le scope le plus restrictif qui permet au read de fonctionner — et rien de plus.
Exemples concrets : pour HubSpot, choisis uniquement crm.objects.deals.read. Pour Notion, donne un accès lecture sur la database spécifique, pas tout le workspace. Pour Gmail, vise readonly, pas modify. Si l'app expose des scopes granulaires, utilise-les.
C'est une petite habitude qui évite toute une classe d'incidents "attends, pourquoi l'assistant vient de modifier ça ?".
Quand NE PAS utiliser un context provider
Quelques cas où MCP est le mauvais outil :
- La donnée est déjà dans ton Business DNA. Voix de marque, ICP, propositions de valeur — ne re-fetch pas ce que Glowtify connaît déjà.
- La donnée change toutes les minutes. La génération est asynchrone ; au moment où le post publie, un snapshot d'analytics live est déjà périmé. Mieux vaut écrire un copy plus evergreen.
- Tu n'en as besoin qu'une fois. Pour un draft one-shot, un copier-coller direct dans le brief est plus rapide qu'un branchement OAuth.
Pièges classiques
- Trop d'outils activés. Le plafond est de 3 par chat, mais même 3 peut perdre le modèle. Choisis le un ou deux qui comptent pour l'Epic en cours — pas "tout ce dont je pourrais potentiellement avoir besoin".
- L'outil renvoie trop de données. L'assistant tronque les réponses longues. Sois précis : "les 5 deals les plus récents" bat "tous les deals ouverts".
- OAuth expiré. Composio le signale dans le chat ; reconnecte-toi depuis la page des connecteurs et relance le message.
- L'outil n'est pas invoqué. Le modèle a jugé que ton brief ne le nécessitait pas. Rends la demande explicite — nomme l'outil, nomme ce qu'il doit récupérer.
Articles liés
- Outils externes (MCP) — Vue d'ensemble — les deux cas d'usage MCP en un coup d'œil
- Utiliser MCP comme destination de publication supplémentaire — l'autre cas d'usage (flow write)
- Setup et dépannage MCP — connecter des apps Composio et corriger les erreurs courantes
- Modifier un Epic — la surface de chat où les outils MCP deviennent disponibles