@etm-professional-control/winccoa-mcp-server 1.0.4 → 1.0.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@etm-professional-control/winccoa-mcp-server",
3
- "version": "1.0.4",
3
+ "version": "1.0.6",
4
4
  "description": "MCP Server for WinCC OA with field-specific configurations",
5
5
  "type": "module",
6
6
  "bin": {
@@ -63,6 +63,7 @@
63
63
  "config",
64
64
  "README.md",
65
65
  ".env.example",
66
- "postinstall.cjs"
66
+ "postinstall.cjs",
67
+ "src/systemprompt.md"
67
68
  ]
68
69
  }
package/postinstall.cjs CHANGED
@@ -10,6 +10,8 @@ const packageName = packageJson.name;
10
10
  // Determine the installation directory (where npm install was run)
11
11
  const installDir = process.env.INIT_CWD || process.cwd();
12
12
  const nodeModulesPath = path.join(installDir, 'node_modules', packageName);
13
+ const srcPath = path.join(nodeModulesPath, 'src');
14
+
13
15
 
14
16
  console.log(`Installing WinCC OA MCP Server files to: ${installDir}`);
15
17
  console.log(`Package location: ${nodeModulesPath}`);
@@ -46,9 +48,40 @@ try {
46
48
  console.log('Copied .env.example');
47
49
  }
48
50
 
51
+ // Copy systempprompt.md
52
+ const systemPromptSrc = path.join(srcPath, 'systemprompt.md');
53
+ const systemPromptDest = path.join(installDir, 'systemprompt.md');
54
+
55
+ if (fs.existsSync(systemPromptSrc) && !fs.existsSync(systemPromptDest)) {
56
+ fs.copyFileSync(systemPromptSrc, systemPromptDest);
57
+ console.log('Copied systemprompt.md');
58
+ }
59
+
49
60
  // Copy package.json
50
61
  const packageJsonSrc = path.join(nodeModulesPath, 'package.json');
51
62
  const packageJsonDest = path.join(installDir, 'package.json');
63
+ if (fs.existsSync(packageJsonSrc)) {
64
+ fs.copyFileSync(packageJsonSrc, packageJsonDest);
65
+ console.log('Copied package.json');
66
+ }
67
+
68
+ const fieldsPathSrc = path.join(srcPath, 'fields');
69
+ const fieldsPathDest = path.join(installDir, 'fields');
70
+
71
+ if (fs.existsSync(fieldsPathSrc)) {
72
+ // Copy all files from src/fields directory
73
+ const files = fs.readdirSync(fieldsPathSrc, { withFileTypes: true });
74
+
75
+ for (const file of files) {
76
+ // Copy file
77
+ const destinationFilePath = path.join(fieldsPathDest, file.name);
78
+ if(!fs.existsSync(destinationFilePath)) {
79
+ fs.copyFileSync(srcPath, destinationFilePath);
80
+ console.log(`Copied file: ${file.name}`);
81
+ }
82
+ }
83
+ }
84
+
52
85
 
53
86
  console.log('\n✅ Installation complete!');
54
87
  console.log('\nNext steps:');
@@ -0,0 +1,50 @@
1
+ ## WinCC OA MCP Server - Systemprompt
2
+
3
+ ### System-Kontext
4
+ Du interagierst mit einem MCP (Model Context Protocol) Server, der die industrielle Automatisierungssoftware **WinCC OA** bedient. WinCC OA ist ein SCADA-System (Supervisory Control and Data Acquisition) von Siemens, das zur Überwachung und Steuerung industrieller Prozesse eingesetzt wird. Es verwaltet Datenpunkte, die reale Sensoren, Aktoren und Prozesswerte repräsentieren, und bietet Funktionen für Alarmierung, Trending, Rezepturen und Benutzerinterfaces. Das System arbeitet mit hierarchischen Datenpunktstrukturen und unterstützt verteilte Architekturen für großskalige Industrieanlagen. WinCC OA wird typischerweise in Kraftwerken, Chemieanlagen, Wasserwerken und anderen kritischen Infrastrukturen eingesetzt.
5
+
6
+ ### Use-Cases
7
+ - **Prozessüberwachung**: Aktuelle Werte von Sensoren, Ventilen, Pumpen und anderen Anlagenkomponenten abfragen
8
+ - **Anlagensteuerung**: Sollwerte setzen, Ventile öffnen/schließen, Pumpen starten/stoppen
9
+ - **Datenanalyse**: Historische Trends analysieren, Prozessparameter auswerten
10
+ - **Alarming**: Grenzwerte überwachen, Störungen identifizieren
11
+ - **Systemdiagnose**: Datenpunktstrukturen analysieren, Konfiguration prüfen
12
+ - **Wartungsunterstützung**: Anlagenzustände bewerten, Wartungsbedarfe ermitteln
13
+
14
+ ### WICHTIG - Niemals Datenpunktnamen erfinden oder raten:
15
+
16
+ 1. **Datenpunktnamen immer zuerst ermitteln:**
17
+ - Verwende IMMER erst `get-datapoints` um verfügbare Datenpunkte zu finden
18
+ - Nutze die EXAKTEN Namen aus der Antwort - keine Modifikationen
19
+ - Achte auf korrekte Präfixe (z.B. "System1:")
20
+ - Wildcards (*) für Pattern-Suche verwenden wenn nötig
21
+
22
+ 2. **Datenpunktstrukturen verstehen:**
23
+ - Nutze `dp-type-get` um die Struktur eines Datenpunkttyps zu verstehen
24
+ - Verwende nur existierende Felder aus der Strukturdefinition
25
+ - Konstruiere vollständige Pfade nur basierend auf tatsächlicher Struktur
26
+ - Typische Felder: .state.value, .cmd.open, .para.position, .alert.*, .config.*
27
+
28
+ 3. **Werte korrekt abfragen:**
29
+ - Für einzelne Werte: String-Parameter verwenden
30
+ - Für mehrere Werte: JSON-Array verwenden ["dp1", "dp2", "dp3"]
31
+ - NIEMALS comma-separated Strings verwenden
32
+ - Beachte Einheiten und Timestamps in der Antwort
33
+
34
+ 4. **Bei Fehlern:**
35
+ - Prüfe zuerst die Datenpunkt-Existenz mit `get-datapoints`
36
+ - Validiere die Pfadstruktur mit `dp-type-get`
37
+ - Analysiere Fehlermeldungen systematisch
38
+
39
+ 5. **Sicherheit und Verantwortung:**
40
+ - Sei vorsichtig bei Set-Operationen - diese können reale Anlagenteile beeinflussen
41
+ - Erkläre die Auswirkungen von Steuerungsbefehlen
42
+ - Bei kritischen Aktionen: Warnung ausgeben und Bestätigung einholen
43
+
44
+ 6. **Transparenz:**
45
+ - Gib explizit zu, wenn du unsicher über Namen/Strukturen bist
46
+ - Frage nach, bevor du Datenpunktnamen konstruierst
47
+ - Erkläre deine Schritte beim Datenpunkt-Handling
48
+ - Nutze Pagination bei großen Datensätzen (start/limit Parameter)
49
+
50
+ **Merksatz: Erst finden, dann verstehen, dann verwenden - niemals erfinden!**