Donnez un numéro WhatsApp à un agent LangChain

Comment un agent LangChain charge-t-il les outils WhatsApp ?

Par MCPAdapter, le client MCP de LangChain, qui transmet les outils d'un serveur MCP à create_agent comme des outils LangChain ordinaires. Il faut langchain[mcp] en version 1.4.0 ou supérieure, et la fonctionnalité est en bêta.

L'authentification est déléguée à FastMCP. Passer auth="oauth" sur le client exécute le flux OAuth 2.1 complet : découverte, enregistrement dynamique du client, redirection navigateur et échange de token. C'est ce qu'attend le serveur MCP d'EasyCoexistence, donc aucune clé à créer ni à coller. Par défaut, les tokens restent en mémoire et chaque exécution répète l'étape navigateur ; un fournisseur OAuth FastMCP doté d'un stockage de tokens les conserve d'une exécution à l'autre.

Une fois chargés, l'agent voit les outils avec leurs descriptions : list_numbers en premier, car tous les autres outils prennent un connection_id qui en provient, puis send_message, send_template, list_templates, get_number_health et le reste.

from fastmcp.client import Client
from langchain.agents import create_agent
from langchain.mcp import MCPAdapter

URL = "https://easycoexistence.com/api/mcp"

async def build_agent(model: str):
    async with MCPAdapter(Client(URL, auth="oauth")) as adapter:
        tools = await adapter.list_tools()
        return create_agent(model, tools)

Comment un message WhatsApp entrant parvient-il à l'agent ?

Par le webhook, car MCP ne peut pas le faire. Le protocole fonctionne en requête et réponse, donc rien ne permet à un serveur de réveiller un client quand un client écrit.

Définissez la destination du webhook du numéro sur une route de votre propre application, avec un long secret aléatoire dans le chemin de l'URL. La route répond au GET de vérification de Meta avec le challenge brut, accepte chaque POST, renvoie 200 aussitôt et met le traitement en file. Un worker extrait ensuite l'expéditeur et le texte du payload et invoque l'agent avec ces valeurs, en prenant le numéro de l'expéditeur comme identifiant de fil pour que la mémoire reste propre à chaque client.

Vérifiez le secret dans l'URL plutôt que l'en-tête X-Hub-Signature-256. Meta signe avec l'app secret du Tech Provider, qui n'est jamais partagé : le client ne peut donc pas valider cet en-tête.

L'agent doit-il envoyer par MCP ou par la Cloud API ?

Les deux fonctionnent, et la différence tient à l'endroit où résident les règles. Les outils MCP portent les règles de WhatsApp dans leurs descriptions : send_message ne fonctionne que dans la fenêtre de 24 heures, et send_template sert à joindre quelqu'un qui n'a pas écrit. Un modèle qui lit ces descriptions choisit le bon outil la plupart du temps, ce qui aide quand l'agent décide librement.

Un outil simple de votre cru, qui envoie à l'endpoint messages de la Cloud API avec le token du numéro, est plus simple quand la mission de l'agent est étroite, par exemple répondre toujours à la personne qui vient d'écrire. Le contrôle de la fenêtre se trouve alors dans votre code, là où doit vivre une règle qui ne doit jamais être enfreinte. Un texte libre envoyé hors fenêtre renvoie l'erreur 131047, et le client ne voit rien.

Erreurs courantes

• Attendre de MCP qu'il livre les messages entrants. Sans route webhook, l'agent n'entend jamais ses clients.
• Laisser les tokens OAuth en mémoire sur un serveur. Chaque redémarrage exige une connexion dans le navigateur ; conservez-les avec un stockage de tokens.
• Utiliser un seul fil pour tous les clients. Indexez la mémoire de l'agent sur le numéro de l'expéditeur.

Questions fréquemment posées

Poursuivre la lecture