System monitoring application with AI-based anomaly detection for CPU and RAM usage. Collects system data, trains an Isolation Forest model to detect anomalies, performs real-time monitoring with alerts, and sends reports to Discord.
MCP_AI_Monitor has critical definition quality gaps. While tool names follow verb_noun patterns (collect_system_data, save_to_csv, detect_anomaly), descriptions are inconsistent in depth and quality. Many tools lack comprehensive parameter documentation. Input schemas are present for some tools but incomplete or poorly structured. The implementation appears to be a standalone Python application being retrofitted as an MCP server rather than a purpose-built MCP tool collection. Tools like 'collect_system_data' and 'collect_current_data' overlap in purpose, creating redundancy. Security issues are severe: Discord webhook URLs are hardcoded in source code (mcp.py lines 18-22), violating secret-injection patterns entirely. Error handling lacks actionable recovery guidance for LLMs. Output schemas are not documented in tool definitions.
Collecte les données système actuelles en détail (CPU par cœur, RAM, processus actifs) pour la surveillance en temps réel
Collecte les données d'utilisation CPU et RAM à intervalles réguliers (5 secondes par défaut)
Détecte si les données système actuelles représentent une anomalie en utilisant le modèle IA et des seuils adaptatifs
Génère un graphique de rapport montrant l'évolution CPU/RAM sur une période donnée
Récupère les informations réseau (vitesse de transfert, interfaces, connexions actives)
Récupère les informations système complètes (hostname, OS, CPU, RAM, Python version, etc.)
Hardcoded Discord webhook URLs in source code (mcp.py lines 18-22: DISCORD_HARDWARE_WEBHOOK_URL, DISCORD_NETWORK_WEBHOOK_URL, DISCORD_WEBHOOK_URL). Credentials must never be exposed in code, this is a critical security breach.
Overlapping tools with unclear distinctions: 'collect_system_data' vs 'collect_current_data' both gather system metrics but with different granularity. Tool names do not disambiguate, LLMs will struggle to choose between them.
No input schemas visible for tools: 'collect_system_data', 'get_system_info', 'get_network_info', 'load_data'. These tools either have no documented input schema or none is accessible in source code. Per HARD SCORING RULES, schema score must be 0 for these.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Récupère les processus qui consomment le plus de ressources CPU et RAM
Mémorise l'impact d'une application sur les ressources système pour améliorer la détection d'anomalies
Charge les données système depuis le fichier CSV de collecte
Prétraite les données pour l'entraînement du modèle avec statistiques descriptives
Sauvegarde les données système dans un fichier CSV avec en-têtes optionnels
Envoie une notification d'alerte locale via le système de notifications et optionnellement à Discord
Envoie un rapport de surveillance système à Discord via webhooks thématiques avec graphiques et statistiques
Entraîne un modèle Isolation Forest sur les données CPU/RAM pour détecter les anomalies
Incomplete output schema documentation. Tools return complex objects (DataFrames, dictionaries with nested structures) but provide no formal schema definition documenting fields, types, and presence guarantees. LLMs cannot plan downstream calls without knowing return structure.
No error handling guidance in any tool description. Tools offer no recovery paths, LLMs cannot determine if errors are retryable, require user action, or are fatal. Descriptions do not include dependency hints (e.g., 'call load_data() first before preprocess_data').
Parameter descriptions lack detail and constraints. 'n' parameter in get_top_processes has minimal description ('Nombre de processus à retourner'). No bounds stated (min 1, max ?), LLMs may pass invalid values like 0, -1, or 10000.
Destructive operations lack confirmation pattern. 'save_to_csv' and 'learn_application_impact' modify state but provide no dry-run or confirmation mechanism. Agents may inadvertently corrupt data or CSV files without explicit user approval.
Short, generic descriptions. Several tools have descriptions under 100 characters that lack actionable context. E.g., 'load_data' description is only ~40 chars ('Charge les données système depuis le fichier CSV de collecte'). These fail to explain WHEN to call them and WHY.
No permission gates or audit logging. Tools that write to CSV, send Discord messages, and learn application impact have no documented permission requirements or audit trails. Per pattern:scope-declaration, each tool should declare what permissions it requires.