Serveur MCP webhook pour agents IA

En résumé

Le serveur MCP de Hook0 est un process local qui expose ton compte Hook0 à un assistant compatible MCP sous forme de 17 outils. Neuf lisent tes applications, types d'event, souscriptions, events et tentatives de livraison. Huit écrivent : déclarer un type d'event, brancher une souscription, émettre un event, rejouer une livraison en échec.

L'essentiel

Installation: cargo install hook0-mcp
Outils: 17 (9 en lecture, 8 en écriture)
Clients: Claude Desktop, Cursor, Windsurf, Cline, et tout client MCP
Transport: stdio par défaut, SSE si tu le fais tourner en service
Cible: Hook0 Cloud, ou ton instance via HOOK0_API_URL
Pour le brider: HOOK0_READ_ONLY=true et un service token atténué
Licence: Code source ouvert (SSPL-1.0), sans rétention open-core

Ils livrent leurs webhooks avec Hook0

1,481 Étoiles GitHub

Deux directions

Webhooks et agents pointent dans deux sens différents

On en parle souvent comme d'un seul sujet. Ce n'est pas le même problème, et ça ne se règle pas avec le même outil.

Un agent qui reçoit des webhooks

Quelque chose se passe dans Stripe, GitHub ou un CRM, et un agent doit réagir. Le travail est entrant : un endpoint public ou un tunnel, la vérification de signature, la déduplication, et ne pas relancer deux fois le même agent. L'outillage de ce côté-là est bien couvert.

Un agent qui pilote ce que tu envoies

Cette fois c'est toi qui émets. Tes clients souscrivent à order.completed et comptent le recevoir. Le travail est sortant : déclarer les types d'event, brancher les souscriptions, comprendre pourquoi une tentative a échoué, la rejouer une fois le récepteur réparé. C'est ce côté-là que le serveur MCP de Hook0 expose à ton assistant.

Si tu édites un produit auquel d'autres systèmes souscrivent, c'est la deuxième direction qui te coûte des tickets de support.

MCP ou webhook

Deux protocoles, deux étages

On les compare parce que les deux transportent des events. Ils ne travaillent pas au même étage, et une installation qui tient la route utilise les deux.

Un webhook: Une requête HTTP que ton produit envoie vers une URL déclarée par un client, quand quelque chose se passe chez toi. Unidirectionnelle, de machine à machine, signée pour que le récepteur puisse s'y fier, relancée quand il est indisponible. C'est le plan de données : il déplace l'event.
MCP: Le Model Context Protocol, la façon dont un assistant découvre et appelle des outils. Requête/réponse, conduit par une personne dans une conversation, exécuté en local. C'est un plan de contrôle : il pilote ce qui déplace l'event.
Les deux ensemble: Ton produit continue d'émettre ses events via l'API REST ou un SDK, sans rien changer. MCP sert quand tu dois déclarer un nouveau type d'event, réorienter une souscription, ou comprendre pourquoi la livraison d'hier a échoué, sans ouvrir le dashboard.

Serveur MCP

Ce que l'assistant peut vraiment faire

Dix-sept outils, répartis entre lecture et écriture. C'est la liste livrée, pas une roadmap. Chacun est documenté, avec son prompt d'exemple, dans la référence MCP.

Outil	Ce qu'il fait	Ce que tu tapes
Lecture (9 outils)
`list_organizations`	Lister les organisations auxquelles tu as accès	« Montre mes organisations »
`list_applications`	Lister les applications d'une organisation	« Quelles applis j'ai ? »
`get_application`	Lire le détail d'une application	« Détaille l'appli X »
`list_event_types`	Lister les types d'event déclarés sur une application	« Quels types d'event sont déclarés ? »
`list_subscriptions`	Lister les souscriptions webhook et leur configuration	« Montre tous mes webhooks »
`get_subscription`	Lire la configuration d'une souscription	« Montre la config du webhook… »
`list_events`	Lister les events émis par une application	« Montre les events récents »
`get_event`	Lire un event, payload compris	« Montre l'event abc123 »
`list_request_attempts`	Lister les tentatives de livraison d'un event	« Montre l'historique de livraison de l'event X »
Écriture (8 outils)
`create_application`	Créer une application	« Crée une appli Order Service »
`delete_application`	Supprimer une application	« Supprime l'appli de test »
`create_event_type`	Déclarer un nouveau type d'event	« Ajoute le type order.completed »
`create_subscription`	Créer une souscription webhook vers une URL	« Crée un webhook vers https://… »
`update_subscription`	Modifier ou désactiver une souscription existante	« Désactive le webhook de… »
`delete_subscription`	Supprimer une souscription	« Retire le webhook de staging »
`ingest_event`	Émettre un event, le côté envoi, depuis l'assistant	« Envoie un event user.created de test »
`retry_delivery`	Rejouer une livraison en échec	« Rejoue la livraison échouée de l'event X »

S'y ajoutent huit URI de ressources sous hook0:// pour les accès directs, et trois prompts guidés pour les enchaînements qu'on répète : créer une souscription, déboguer une livraison, monter une application.

Référence complète des outils, avec la configuration pour Claude Desktop, Cursor, Windsurf et Cline

Mise en route

Trois étapes avant ton premier prompt

Le serveur est un binaire Rust que tu installes une fois. Rien de nouveau ne tourne côté Hook0.

1. Installer le serveur

Il est publié sur crates.io et compile en un seul binaire.
```
cargo install hook0-mcp
```
2. Créer un service token

Dans le dashboard Hook0, section service tokens de ton organisation. Atténue-le aux applications que l'assistant doit atteindre avant de le coller où que ce soit.
3. Le déclarer dans ton assistant

Claude Desktop lit claude_desktop_config.json. Cursor, Windsurf et Cline prennent le même bloc dans leur propre fichier de configuration.
```
{
  "mcpServers": {
    "hook0": {
      "command": "hook0-mcp",
      "env": {
        "HOOK0_API_TOKEN": "ton-service-token-ici"
      }
    }
  }
}
```

Redémarre l'assistant et demande-lui ce que tu irais autrement chercher à la souris : « pourquoi ma dernière livraison de webhook a échoué ? »

Chemins des fichiers de configuration par assistant, variables d'environnement et mode SSE

Garde-fous

Confier ton infrastructure de livraison à un agent

L'accès en écriture à des webhooks de production ne se donne pas à la légère. Trois contrôles sont livrés avec le serveur, et ils se combinent.

Mode lecture seule

Mets HOOK0_READ_ONLY=true et le serveur n'annonce que les neuf outils de lecture. L'assistant peut enquêter sur une livraison en échec sans rien pouvoir modifier au passage.

Tokens atténués

Le mode lecture seule restreint la liste d'outils ; le token, lui, garde les droits qu'on lui a donnés. L'atténuation limite un token à des applications précises et peut porter une expiration, appliquée côté API et non côté client. Utilise les deux : ils couvrent des défaillances différentes.

Il tourne là où tu le lances

Le serveur MCP est un process local qui parle à l'API Hook0. L'assistant voit ce que retournent les outils qu'il appelle, et rien d'autre n'est transmis ailleurs. Pointe HOOK0_API_URL vers ton instance et les mêmes outils pilotent un déploiement auto-hébergé.

En dessous

L'agent est une interface, pas la garantie

Le langage naturel change la façon dont tu pilotes la livraison des webhooks. Il ne livre rien par lui-même. Voilà ce qui livre.

Signé, relancé, journalisé

Chaque tentative porte une signature HMAC-SHA256. Les relances sont en deux phases et configurables : un souscripteur indisponible pendant une heure ne te coûte pas cette heure d'events. Chaque tentative est journalisée, ce qui transforme le « pourquoi ça a échoué » en consultation plutôt qu'en supposition.

Un data plane européen, sur toutes les offres

Payloads, base de données et sauvegardes tournent sur l'infrastructure de Clever Cloud SAS en France, dans l'EEE, y compris sur l'offre gratuite. Le CDN devant est Cloudflare, Inc. (USA), divulgué dans la liste publique des sous-traitants avec son mécanisme de transfert. Le détail sur l'infrastructure webhook européenne.

Un code que tu peux emporter

Hook0 est à code source ouvert (SSPL-1.0), sans rétention open-core : le service hébergé fait tourner le code que tu peux faire tourner. Le serveur MCP, l'API et le portail souscripteur se comportent pareil face à une instance auto-hébergée.

Questions

Avant de pointer un assistant sur ta production

Comment utiliser des webhooks avec des outils MCP ?

Installe hook0-mcp, crée un service token Hook0, et déclare le serveur dans le fichier de configuration de ton assistant. À partir de là, il dispose de dix-sept outils sur ton compte : lister l'existant, déclarer un type d'event, créer une souscription vers une URL, émettre un event de test, rejouer une livraison en échec. Ton application, elle, continue d'émettre ses vrais events via l'API REST ou un SDK, et ce chemin ne bouge pas.

Quelle est la différence entre MCP et un webhook ?

Un webhook est une requête HTTP que ton produit envoie vers une URL déclarée par un client, unidirectionnelle et de machine à machine, signée pour que le récepteur puisse s'y fier. MCP est la façon dont un assistant découvre et appelle des outils, en requête/réponse, conduit par une personne dans une conversation. Le webhook déplace l'event ; MCP pilote le système qui le déplace. La plupart des installations qui utilisent les deux ne touchent pas au chemin webhook et réservent MCP au travail d'exploitation.

L'assistant voit-il le contenu de mes events ?

Il voit ce que retournent les outils qu'il appelle, et lire un event retourne son payload. Rien n'est transmis à un tiers par Hook0 : le serveur MCP est un process local qui parle directement à l'API Hook0. Si les payloads doivent rester hors de la conversation, atténue le token aux applications qui ne portent pas de données sensibles.

Quels assistants fonctionnent avec ?

Claude Desktop, Cursor, Windsurf et Cline sont documentés avec leur fichier de configuration, et tout client compatible MCP marche de la même façon. ChatGPT ne supporte pas MCP nativement à ce jour.

Qu'est-ce qui empêche un agent de supprimer une souscription de production ?

Deux choses, et elles se combinent utilement. Le mode lecture seule retire les outils d'écriture de la liste que l'assistant peut voir. L'atténuation de token restreint ce que le token lui-même peut toucher, appliquée côté API, de sorte qu'une erreur du client ne peut pas la dépasser. Les ressources supprimées ne sont pas restaurables automatiquement : c'est la raison de mettre les deux avant de pointer un assistant sur la production.

Que deviennent les events quand l'endpoint d'un souscripteur est indisponible un moment ?

Hook0 relance la livraison sur un calendrier en deux phases, configurable, plutôt que de l'abandonner au premier échec, et enregistre chaque tentative avec sa réponse. Une fois le récepteur réparé, tu rejoues ce qui a échoué, depuis le dashboard, depuis l'API, ou en demandant à l'assistant de relancer cette livraison. L'event n'est pas perdu pendant que l'endpoint est injoignable.

Comment le récepteur vérifie-t-il un payload envoyé par Hook0 ?

Chaque tentative porte une signature HMAC-SHA256 calculée depuis le payload et le secret de la souscription. Le récepteur la recalcule et la compare avant d'agir sur l'event, ce qui empêche une requête forgée de déclencher un traitement. Le schéma de signature et un extrait de vérification sont dans la documentation Hook0.

Est-ce que ça marche avec Hook0 auto-hébergé ?

Oui. Mets HOOK0_API_URL sur ton instance et les dix-sept outils se comportent à l'identique. Le produit entier est à code source ouvert (SSPL-1.0) sans rétention open-core : le déploiement auto-hébergé fait tourner le même logiciel que le cloud.

Est-ce un Agent Skill ou un plugin ?

Non. C'est un serveur MCP, installé avec cargo install hook0-mcp et déclaré dans la configuration de ton assistant. Il tourne en stdio par défaut, ou en SSE si tu préfères le faire tourner en service.

Ai-je besoin du serveur MCP pour envoyer des webhooks ?

Non. L'API REST et les SDK restent le chemin normal pour que ton application émette ses events, et rien de tout ceci ne les affecte. Le serveur MCP s'adresse à la personne qui exploite l'installation : déclarer un type d'event, brancher une souscription, comprendre pourquoi une livraison a échoué à seize heures.

Tu as mieux à construire

Arrête d'écrire ton infra webhooks. Livre des fonctionnalités. Démarrage en quelques minutes.

Authentification Monitoring

Démarrer gratuitement Guide de démarrage rapide

Sans carte bancaire

Setup en 5 minutes

Résiliation à tout moment

Ton agent sait lire les webhooks. Il sait aussi les envoyer.