Arthur Ria
7621b87c49
Deux angles morts mesurés sur le tenant LIMAGRAI2512. L4.1 — QueryType est figé à 0 (Reading) en dur dans api-service.js : le modèle Writing est inatteignable. Ce n'est pas une limite de l'API, QueryType 1 répond correctement sur Context.Products — il manque le paramètre. D3 reste vrai en revanche : en Writing les statuts sont des énumérations, donc le défaut doit rester 0. L4.2 — Application vient de WMS_APPLICATION, partagé par tous les profils, sans surcharge possible. Le MCP n'interroge que EasyWMS alors que /AD/api/Application/GetAll en déclare 9. CustomApp porte le spécifique client (153 workflows, 54 queries, 11 entités préfixés CST_) et est entièrement invisible ; avec AGV, Notifications, GalileoFaults et Common, ce sont 260 workflows hors périmètre. Côté API AD le correctif est simple, l'application n'étant qu'un champ du payload — vérifié, ["CustomApp", tenant, 5, 0] renvoie bien les workflows CST_. Il faudra en revanche indexer les caches par application. Côté QueryExecute c'est non résolu : passer Application "CustomApp" ne change pas le contexte de lecture, les entités CST_ ne répondent ni au singulier ni au pluriel et aucune n'apparaît dans les 232 entités du Metadata EasyWMS. Elles sont définies dans EasyBuilder (FromMetadata: false). Consigné comme question ouverte, sans solution promise. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WMS MCP Server
Serveur MCP qui donne à Claude un accès en lecture à un WMS EasyWMS (Mecalux), pour le diagnostic et l'analyse.
Concrètement, dans Claude Desktop :
« Combien de commandes sont bloquées en statut Release sur LIMAGRAIN ? » « Trouve les workflows qui touchent au réapprovisionnement. » « Cherche
Order 4711dans les logs. » « Quels paramètres sont surchargés sur l'entrepôt 2 ? »
Architecture : 100 % API REST. Aucun accès direct à Oracle — voir D1 dans DECISIONS.md.
Ce que le serveur expose
23 outils répartis en 8 familles :
| Famille | Outils |
|---|---|
| Requêtes WMS | query_wms_entities, count_wms_entities, get_entity_schema, search_wms_data |
| API brutes | call_query_api, execute_command |
| Workflows | search_workflows, get_workflow_details, list_workflow_categories |
| Application Dictionary | get_application_summary, get_ad_elements, search_ad_elements, get_ad_element_details, list_ad_types |
| Métadonnées | get_entity_metadata, generic_search |
| Configuration | get_system_parameters |
| Profils | list_wms_profiles, get_current_wms_profile, switch_wms_profile |
| Logs | read_recent_logs, list_log_files, search_logs |
6 resources de contexte : wms://entities, wms://entity-schemas,
wms://query-examples, workflows://overview, api://catalog, logs://guide.
Multi-WMS. Plusieurs backends (clients, tenants) coexistent dans un seul
serveur ; Claude bascule à la demande avec switch_wms_profile.
Installation
Prérequis : Node.js 18+ et un accès réseau au WMS (VPN si nécessaire).
npm install
Copiez .env.example en .env et renseignez au moins un profil :
WMS_API_AUTH=Basic R05BOklFNGU3aXFoZHQ=
WMS_APPLICATION=EasyWMS
WMS_API_PATH=/ApplicationService/api
WMS_TOKEN_PATH=/EasySTS/OAuth/Token
WORKFLOW_API_PATH=/AD/api
WMS_PROFILES=AD
DEFAULT_WMS_PROFILE=AD
AD_HOST=10.255.255.2
AD_USERNAME=...
AD_PASSWORD=...
AD_TENANT=AD
AD_SAAS=false
Vérifiez la connectivité — le test est en lecture seule :
npm test
Sortie attendue : 4/4 tests reussis. En cas d'échec, voir
MONITORING.md §7.
Brancher Claude Desktop
Éditez %APPDATA%\Claude\claude_desktop_config.json :
{
"mcpServers": {
"wms": {
"command": "node",
"args": ["D:\\chemin\\vers\\mcp-wms-api\\src\\index.js"]
}
}
}
Puis fermez et rouvrez complètement Claude Desktop. Les logs du serveur
apparaissent dans %APPDATA%\Claude\logs\.
Ajouter un WMS
- Ajoutez son nom à
WMS_PROFILES(séparateur : virgule). - Définissez
<NOM>_HOST,<NOM>_USERNAME,<NOM>_PASSWORD,<NOM>_TENANT. - Mettez
<NOM>_SAAS=truesi le WMS est hébergé dans le cloud Mecalux — les outils de log seront alors désactivés pour ce profil, à dessein.
Les URL se construisent à partir du host : rien d'autre à dupliquer. Testez
avec npm test -- <NOM>.
Compiler un exécutable Windows
npm run build
Produit dist/wms-mcp-server.exe (~76 Mo, autonome, cible node22-win-x64).
Placez le .env à côté de l'exe : en mode packagé, c'est là qu'il est lu,
et aucun credential n'est embarqué dans le binaire (D7). Les avertissements
Cannot find module '@modelcontextprotocol/sdk/…' pendant le build sont
normaux et sans effet (D18).
Déploiement type sur la VM :
C:\WMS\mcp\wms-mcp-server.exe
C:\WMS\mcp\.env
Documentation
| Fichier | Contenu |
|---|---|
| CLAUDE.md | Architecture, inventaire des outils, conventions de code |
| DECISIONS.md | Pourquoi le code est ainsi + pièges vérifiés en production |
| MONITORING.md | Superviser le serveur MCP : logs, token, caches, symptômes |
| ROADMAP.md | Travaux planifiés par lot, et ce qui a été écarté |
| docs/logs.md | Accès aux logs du WMS |
| docs/ | Références EasyWMS (API, entités) |
Sécurité
.envetdist/sont ignorés par git — ne les committez jamais.- La validation TLS est désactivée pour accepter les certificats auto-signés des WMS on-premise (D15).
- ⚠️ L'historique git contient un ancien fichier de configuration avec des mots
de passe en clair (commit
b59cbb3). Ces credentials sont à considérer comme compromis — voir D20.