DearAgent : un serveur MCP donnant aux agents IA une boîte mail auto-hébergée

DearAgent est une API de boîte mail pour agents IA auto-hébergée sur Cloudflare Workers, avec les e-mails stockés dans D1 et les pièces jointes dans R2. Positionné comme une alternative open source à AgentMail, il expose un serveur MCP stateless en Streamable HTTP via le point de terminaison /mcp du Worker.

Pour qui ?

• Destiné aux développeurs qui veulent donner à leurs agents IA une véritable capacité de réception d'e-mails : le flux type consiste à créer une boîte de réception, attendre l'e-mail de vérification, puis lire le lien de vérification.
• Prérequis clairs : un compte Cloudflare, un domaine de premier niveau dédié pour Cloudflare Email Routing, Node 20+ et l'exécution de npx wrangler login. La réception d'e-mails est gratuite ; seul l'envoi nécessite Workers Paid.
• L'API et le MCP utilisent la même API_KEY comme unique jeton bearer : une seule clé donne tous les droits (mono-locataire), ce qui ne convient pas aux scénarios multi-utilisateurs nécessitant une isolation fine des permissions.
• À éviter si : vous n'avez pas votre propre domaine, vous ne pouvez pas assumer un déploiement auto-hébergé et sa maintenance, ou vous avez besoin d'une isolation multi-locataires. Les aspects non documentés dans les preuves officielles (rétention des données, politique de suppression, etc.) restent inconnus : à vérifier vous-même.

Première tentative en 3 minutes

Le seul chemin principal recommandé officiellement est de cloner le dépôt puis de lancer le script d'installation interactif, qui configure automatiquement D1, R2, les secrets, Email Routing/Sending, termine le déploiement et crée la règle catch-all :

git clone https://github.com/panda-sandeep/dearagent && cd dearagent
npm install
npm run setup

Prérequis : être connecté à Cloudflare via npx wrangler login, et que le domaine soit déjà utilisable pour Email Routing. Le script vous guide pour définir l'API_KEY requise (configurable aussi avec npx wrangler secret put API_KEY) ; cette clé est le seul jeton bearer de l'API et du MCP.

Pour le premier appel, il est conseillé d'utiliser l'outil en lecture seule à faible risque list_inboxes : après avoir configuré votre client MCP pour pointer vers le point de terminaison /mcp du Worker avec la clé bearer, appelez list_inboxes. Si la liste des boîtes de réception est renvoyée, le déploiement et l'authentification fonctionnent. Attention : il s'agit d'un service auto-hébergé, et non d'un service distant géré par un tiers ; create_inbox écrit dans votre propre base de données D1.

Si vous ne voulez que recevoir des e-mails, Workers Paid n'est pas nécessaire ; ce n'est qu'avant d'appeler send_message pour envoyer des e-mails qu'il faut vérifier que Workers Paid est activé, car l'envoi génère de vrais e-mails sortants (irrévocables au niveau MCP, à évaluer selon le comportement réel d'Email Sending).

Cas d'usage

Cas 1 : faire vérifier automatiquement une inscription par un agent. Appelez create_inbox pour créer une boîte de réception, entrez cette adresse dans le formulaire d'inscription du site cible, puis utilisez wait_for_message pour attendre l'arrivée de l'e-mail de vérification et lisez le lien de vérification dans le contenu de l'e-mail. C'est le flux type décrit officiellement ; les outils renvoient le contenu réel des e-mails de votre service auto-hébergé.

Cas 2 : retrouver des e-mails historiques. Appelez search_messages pour une recherche par mots-clés, ou utilisez list_threads / get_thread pour consulter les conversations, get_message pour lire un e-mail précis, et get_attachment pour récupérer une pièce jointe. Ce sont toutes des opérations de lecture sur les données déjà présentes dans votre D1/R2, adaptées au débogage des e-mails reçus précédemment par l'agent.

Les autres outils (comme send_message, reply_to_message, forward_message, list_webhooks, create_webhook) sont listés comme disponibles dans les preuves, mais leurs détails de paramètres ne sont pas documentés ; reportez-vous au README du dépôt avant utilisation.

Limites d'usage

• Nature lecture/écriture : list_*, get_*, search_messages et wait_for_message sont des requêtes ; create_inbox, create_webhook, send_message, reply_to_message et forward_message écrivent des données ou déclenchent de vraies actions sortantes — à confirmer avant appel.
• Identifiants et données : une seule API_KEY donne un accès complet, gardez-la en lieu sûr ; toutes les données d'e-mails résident dans votre propre Cloudflare D1/R2.
• Effets de bord : l'envoi d'e-mails nécessite Workers Paid et envoie réellement ; aucune mécanique de retrait après envoi n'est documentée officiellement, l'opération ne doit donc pas être considérée comme révocable.
• Points inconnus : durée de rétention des e-mails, outils de suppression, détails de traitement de la vie privée ne sont pas documentés dans les preuves officielles ; ces informations restent non confirmées et ne constituent pas une garantie d'absence de risque.