Le serveur MCP officiel de MuleSoft ne lit pas vos logs, alors j’en ai écrit un qui le fait

MuleSoft a un serveur MCP officiel. Il crée des squelettes de projet, génère des flows, déploie des apps. Ce qu’il ne sait pas faire, c’est la seule chose dont j’ai besoin quand ça casse en prod : lire les logs.

Alors j’ai écrit mulewatch. C’est un serveur MCP open source qui ouvre vos logs Anypoint, en direct et archivés, à Claude, Cursor ou n’importe quel client MCP. En lecture seule. Une ligne pour le lancer : npx -y mulewatch.

J’en ai d’abord écrit une version pour mon travail. Celle-ci, c’est la version nettoyée, qui marche chez tout le monde.

Construire ou exploiter

Le serveur officiel sert à construire des apps Mule, et il le fait bien. Mais il attend un projet Mule local ouvert dans votre IDE. Quand un flow plante en prod, vous n’en avez en général aucun d’ouvert. Vous avez Runtime Manager dans un onglet du navigateur.

mulewatch couvre l’autre moitié du travail : comprendre ce qui s’est passé. Logs, apps déployées, instances API Manager, assets Exchange. Rien qui écrive.

Les logs en direct oublient vite

Les logs que vous voyez dans Runtime Manager sont un live tail : un petit tampon circulaire par app. Sur une app chargée, une ligne en sort en quelques minutes, quel que soit le startTime que vous passez. Si le problème date d’hier soir, il a déjà disparu.

Le vrai historique se trouve dans l’API Anypoint Monitoring Archive. Elle range les logs dans des fichiers de 10 minutes, qui arrivent environ 10 minutes après la fin de chaque fenêtre, et les garde longtemps. Il faut qu’Anypoint Monitoring soit activé sur l’org.

Le plus amusant : trouver le bon réplica

Voilà le piège. L’archive n’est pas indexée par app. Elle est indexée par réplica, sous la forme {appName}_{replicaId}, et chaque redéploiement crée de nouveaux réplicas. Impossible, donc, de demander simplement « les logs d’order-sync-api du 9 août ». Il faut savoir quel pod tournait ce jour-là.

L’app sur laquelle j’ai testé comptait 669 entités de réplica dans l’archive. L’API autorise 60 requêtes par minute. Les sonder toutes, c’est environ 11 minutes d’attente avant de lire la moindre ligne.

En fait, on n’en a presque jamais besoin. Un pod vit en général jusqu’au redéploiement suivant, donc le réplica qui tourne en ce moment a sans doute aussi écrit les logs récents. Voici ce que fait mulewatch :

1. Récupérer les ID de réplica dans les logs en direct et les essayer en premier.
2. Aucun fichier pour cette date ? L’app a été redéployée depuis. Se replier sur un scan de tous les réplicas qu’elle a eus, plafonné par maxEntities.

Sur ce test, une recherche sur la date du jour a sondé 1 réplica, trouvé 127 fichiers d’archive et analysé 2 859 lignes de log. Une date antérieure au dernier redéploiement est retombée sur le scan complet, comme il se doit. Le client reste aussi sous la limite de débit et temporise quand il reçoit un 429 : une longue recherche ralentit au lieu d’échouer.

En lecture seule, exprès

Je ne veux pas qu’un LLM redémarre des apps Mule en production. Il n’y a donc dans mulewatch aucun outil pour déployer, arrêter, redémarrer ou appliquer une policy. Aucun. Si vous en avez besoin, utilisez le serveur officiel à côté.

Vous pouvez aussi restreindre tout le serveur aux environnements de confiance :

ANYPOINT_ALLOWED_ENVIRONMENTS=Dev,Sandbox

Tout ce qui n’est pas dans la liste est refusé, raison à l’appui. Couplez ce réglage à une connected app qui ne voit que ces environnements, et la prod est deux fois hors d’atteinte.

Le piège qui vous attend

Les environnements sont rattachés aux business groups, pas à l’org racine. Les identifiants d’une connected app pointent sur l’org racine, qui n’a souvent aucun environnement. Votre premier appel revient donc vide et vous croyez vos identifiants invalides. Ils ne le sont pas.

Appelez anypoint_list_business_groups, récupérez le bon id, renseignez ANYPOINT_ORG_ID. C’est réglé.

Même logique pour les scopes : Anypoint répond à un scope manquant par un simple 403, sans explication. mulewatch l’intercepte et vous dit quel scope il vous manque sans doute.

Essayez-le

Créez une connected app (« acts on its own behalf »), donnez-lui des scopes en lecture, et ajoutez ceci à Claude Desktop, Cursor ou OpenClaw :

{
  "mcpServers": {
    "mulewatch": {
      "command": "npx",
      "args": ["-y", "mulewatch"],
      "env": {
        "ANYPOINT_CLIENT_ID": "your_connected_app_client_id",
        "ANYPOINT_CLIENT_SECRET": "your_connected_app_client_secret"
      }
    }
  }
}

Ou dans Claude Code :

claude mcp add mulewatch --env ANYPOINT_CLIENT_ID=... --env ANYPOINT_CLIENT_SECRET=... -- npx -y mulewatch

Lancez d’abord anypoint_whoami pour voir à quoi il est connecté. Ensuite, demandez simplement : « montre-moi les lignes ERROR d’order-sync-api en Prod hier entre 1 h et 3 h du matin »

Le projet en est à la v0.1, sous licence Apache-2.0, sur npm et dans le registre MCP. Tout est testé sur une org réelle, sauf API Manager, parce que mon app de test n’avait pas le scope View APIs Configuration. Si vous utilisez MuleSoft, essayez-le et dites-moi ce qui casse. Les issues et les PR sont ouvertes sur GitHub.

MuleSoft et Anypoint Platform sont des marques de Salesforce. mulewatch est un projet indépendant.

Texte brut: mulewatch-anypoint-logs-mcp.md · Flux Atom · Toutes les notes