Appelez le serveur MCP e-mail
directement depuis curl ou un script
Pas de client, pas de SDK. Un seul point de terminaison Streamable HTTP qui parle JSON-RPC 2.0, authentifié par une clé bearer à portée limitée que vous pouvez révoquer en un clic.
Envoyez en POST du JSON-RPC 2.0 à https://mcpemails.com/api/mcp avec un en-tête Authorization Bearer contenant une clé API de votre tableau de bord. Les méthodes prises en charge sont initialize, tools/list, tools/call, prompts/list et prompts/get.
Comment un script ou un client HTTP brut se connecte : une clé API à portée limitée
Un script ou un client HTTP brut n'exécute pas le flux OAuth dans le navigateur auprès d'un serveur MCP distant, il s'authentifie donc avec un jeton bearer. Créez une clé API dans votre tableau de bord, cochez uniquement les autorisations dont l'agent a besoin, et placez-la dans le script ou le client HTTP comme en-tête Authorization: Bearer. Les connexions par clé et les connexions OAuth atteignent le même point de terminaison et reçoivent le même catalogue d'outils ; seule change la manière d'obtenir le jeton.
La seule valeur dont vous avez besoin
Tout ce qui figure sur cette page sert à faire entrer cette URL dans curl and the raw API.
| Champ | Valeur |
|---|---|
| URL du serveur MCP | https://mcpemails.com/api/mcp |
| Transport | Streamable HTTP (MCP 2025-06-18) |
| Authentification | Authorization: Bearer, avec une clé API à portée limitée issue de votre tableau de bord. |
Comment connecter curl and the raw API à votre boîte
Quatre étapes. Les deux premières sont les mêmes pour tous les clients, les suivantes sont propres à celui-ci.
Créez un compte gratuit et connectez une boîte
Inscrivez-vous sur mcpemails.com, sans carte bancaire, puis allez dans Dashboard, Inboxes, Connect Inbox. Outlook et Microsoft 365 se connectent via la connexion Microsoft ; Gmail, iCloud, Fastmail, Yahoo, Zoho et Yandex demandent un mot de passe d'application ; tout le reste se connecte en IMAP et SMTP standard. Le plan gratuit inclut une boîte, pour toujours.
Créez une clé API à portée limitée
Dans Dashboard, API Keys, cliquez sur Create key. Donnez-lui un nom et cochez uniquement les autorisations dont cet agent a besoin : read:email, search:email, send:email, manage:folders, delete:email, manage:drafts, manage:contacts, schedule:email et manage:automations. La clé se présente sous la forme mcpe_ suivi de 64 caractères hexadécimaux et ne s'affiche qu'une fois : copiez-la avant de fermer la fenêtre.
Appelez le point de terminaison
Envoyez en POST un corps JSON-RPC 2.0 à https://mcpemails.com/api/mcp avec la clé dans l'en-tête Authorization. Commencez par tools/list pour voir le catalogue, puis inbox_list pour découvrir les identifiants de vos boîtes.
Traitez la réponse
Les résultats reviennent en JSON-RPC 2.0. Les résultats réussis portent aussi un objet typé structuredContent, pour qu'un script n'ait pas à analyser de la prose.
curl -X POST https://mcpemails.com/api/mcp \
-H "Authorization: Bearer mcpe_YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Vous ne savez pas quelle boîte connecter en premier ? Voir le tableau de compatibilité des fournisseurs
Ce qui fait trébucher avec curl
Envoyez la clé dans l'en-tête, pas dans la query string
Une clé passée en ?key= ou ?api_key= est encore acceptée pour les intégrations antérieures à l'en-tête, mais ne doit pas être utilisée pour quoi que ce soit de nouveau. Les identifiants dans l'URL subsistent dans l'historique du navigateur, les logs de proxy, les en-têtes referrer et les systèmes de supervision, dont aucun n'est sous votre contrôle. L'en-tête Authorization est la voie prise en charge.
Les appels sortants acceptent une clé d'idempotence, et réessayer sans est un vrai risque
Send, reply, forward, l'envoi de brouillon et l'envoi planifié acceptent une clé d'idempotence facultative, respectée pendant 24 heures. Un timeout réseau sur un envoi est ambigu par nature : l'e-mail est peut-être bien parti. Avec une clé d'idempotence, la nouvelle tentative est sûre. Sans elle, une nouvelle tentative est un second e-mail.
Les opérations longues sont vraiment longues
Un search-and-move sur une grande boîte a été observé en production autour de 152 secondes, et le proxy accorde jusqu'à 270 secondes avant d'abandonner de lui-même. Réglez un timeout client en conséquence plutôt que les quelques secondes habituelles, sinon vous annulerez des opérations sur le point de réussir.
Pas de push, dans aucun sens
Pas de webhooks, pas d'événements déclenchés par le serveur, pas d'URL de callback à enregistrer. Réagir au nouveau courrier signifie interroger régulièrement, par exemple email_read avec action: "list" et les non-lus uniquement, à l'intervalle dont votre workflow a besoin. Les limites sont de 100 par minute, 1 000 par heure et 10 000 par jour et par clé.
Limites à connaître
- Les requêtes sont limitées à 100 par minute, 1 000 par heure et 10 000 par jour et par clé, en plus du plafond d'actions facturables de votre plan.
- Le serveur fonctionne uniquement en requête-réponse. Il n'y a ni webhooks ni événements déclenchés par le serveur, donc un nouveau message ne réveille jamais votre agent de lui-même. Pour réagir au courrier entrant, interrogez la boîte à intervalles réguliers.
- Le courrier est récupéré en direct chez votre fournisseur à chaque appel et n'est jamais stocké. Seul le jeton OAuth ou le mot de passe d'application chiffré est conservé, donc un jeton révoqué ou un mot de passe de boîte modifié coupe l'accès immédiatement.
curl and the raw API et l’e-mail : vos questions
Puis-je l'utiliser sans client MCP ?
Oui. C'est un point de terminaison HTTPS ordinaire qui parle JSON-RPC 2.0 : curl, une tâche cron, un service backend ou n'importe quelle bibliothèque HTTP peut l'appeler. Authentifiez-vous avec une clé API bearer issue de Dashboard, API Keys. Le catalogue d'outils est identique à celui que voit un client MCP.
Quelles méthodes JSON-RPC sont prises en charge ?
initialize, tools/list, tools/call, prompts/list et prompts/get. Les résultats réussis portent un objet typé structuredContent à côté du contenu lisible, et c'est lui qu'un script doit lire.
Comment rendre les nouvelles tentatives sûres ?
Passez une clé d'idempotence sur les opérations sortantes. Send, reply, forward, l'envoi de brouillon et l'envoi planifié en acceptent une et la respectent pendant 24 heures : relancer la même requête après un timeout ne peut donc pas produire un second e-mail. Les lectures peuvent naturellement être relancées sans risque.
Quelles sont les limites de débit ?
100 requêtes par minute, 1 000 par heure et 10 000 par jour et par clé, en plus du plafond d'actions facturables de votre plan. Les appels en échec et inbox_list ne sont pas facturés.
Mes e-mails sont-ils stockés sur vos serveurs ?
Non. Chaque message est récupéré en direct chez votre fournisseur pour la requête qui l'a demandé, puis transmis directement à votre client. Seul le jeton OAuth ou le mot de passe d'application chiffré est conservé, pour que les appels suivants puissent s'authentifier. Supprimer la boîte dans le tableau de bord, ou révoquer l'accès chez votre fournisseur, coupe la connexion aussitôt.
Pilotez votre boîte par script
Un point de terminaison, une clé à portée limitée. Une boîte gratuite pour toujours, sans carte bancaire.