Planifier avec Claude, ChatGPT et Cursor : le serveur MCP de WhenToMeet

On n'a pas livré d'assistant IA dans WhenToMeet. Tu en as déjà un.

Si tu utilises Claude, ChatGPT ou Cursor, l'assistant que tu paies déjà est plus utile que n'importe quel chatbot qu'on pourrait caser dans une barre latérale. Ce qui lui manque, c'est la permission de toucher à ton calendrier. C'est ce que le serveur MCP lui donne.

MCP en un paragraphe

MCP — le Model Context Protocol — est une petite spec pour exposer des tools à un client LLM. Le client se connecte à un serveur, lit une liste de tools avec des entrées typées, et les appelle quand la conversation en a besoin. C'est la prise, pas la lampe. WhenToMeet fait tourner le serveur ; l'assistant que tu choisis est le client.

L'endpoint est POST /api/mcp. Transport HTTP sans état. Mêmes clés API que REST v1.

Installation

Dans ton client MCP — Claude Desktop, ChatGPT avec connectors, Cursor ou un autre — tu ajoutes une entrée serveur qui pointe sur https://whentomeet.com/api/mcp avec ta clé API comme Bearer token. La forme exacte de la config varie par client ; docs.whentomeet.io a les snippets copier-coller pour les plus courants.

Une fois la connexion établie, l'assistant voit sept tools :

• list_polls — tes scheduling polls et direct events
• get_poll — un événement avec ses slots et les votes des participants
• create_poll — créer un nouveau scheduling event
• list_bookings — rendez-vous réservés via tes booking pages
• list_calendar_events — un flux unifié de tous les calendriers connectés
• check_conflicts — est-ce que ce créneau entre en conflit avec quelque chose
• get_user_profile — ton tier, ton fuseau, tes préférences

C'est toute la surface aujourd'hui.

Des prompts qui marchent vraiment

Les prompts génériques produisent des appels génériques. Ceux-ci marchent :

« Qu'est-ce qu'il y a dans mon calendrier mardi prochain entre 10h et 16h ? Utilise list_calendar_events avec cette plage. »

« Je veux un bloc de focus de 2 heures demain matin. Vérifie mon calendrier avec check_conflicts et propose trois heures de début libres. »

« Crée un scheduling poll nommé ‹ Planification Q3 › avec six slots d'une heure entre le 2026-05-04 et le 2026-05-06, heures de bureau uniquement. »

« Résume mes bookings des 30 derniers jours — qui a réservé quoi et combien de no-shows. »

« Rédige une agenda pour le standup de demain à partir de ce qu'il y a dans mon calendrier cette semaine. »

Le motif : nomme le tool si tu veux le contrôle, décris le résultat sinon. Claude et GPT sont bons pour choisir le bon tool à partir de la description.

Ce qu'il ne peut toujours pas faire

La surface MCP n'est pas tout le produit. À l'heure où on écrit, l'assistant ne peut pas :

• Voter à ta place sur le poll d'une autre personne
• Éditer ou annuler un événement existant
• Lire ou changer les réglages d'une booking page
• Faire quoi que ce soit qui nécessite OAuth dans un calendrier externe en ton nom — ça se passe une fois dans notre UI, et après le serveur MCP voit les données unifiées

Ce sont des trous qu'on comblera selon ce que les gens demandent vraiment. Si le tool que tu veux n'est pas là, dis-le-nous.

Rate limits et clés

Le serveur MCP utilise les mêmes clés que REST v1 et les mêmes limites par clé. Un usage conversationnel normal — une douzaine d'appels de tool par session — est loin du plafond. Si tu fais tourner un batch, utilise directement les endpoints REST ; ils sont faits pour ça.

L'accès API est gated pour Pro. Génère une clé dans les réglages, colle-la dans la config de ton client MCP, et c'est bon.

Pourquoi on a fait comme ça

On aurait pu construire un panneau de chat dans l'app. Ça aurait bien démo-é. Mais l'assistant que tu utilises déjà est meilleur, déjà dans ton workflow, et a déjà un contexte qu'on n'aura jamais. Lui donner une surface propre sur ton calendrier vaut plus que de te donner une version dégradée de Claude dans WhenToMeet.

Les docs de setup complètes et la référence des tools actuelle vivent sur docs.whentomeet.io.