sad-mcp 0.1.25 → 0.1.27

package/dist/index.js

@@ -1,13 +1,19 @@
 #!/usr/bin/env node
 import { Server } from "@modelcontextprotocol/sdk/server/index.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
+import { readFileSync } from "fs";
+import { join, dirname } from "path";
+import { fileURLToPath } from "url";
 import { registerToolHandlers } from "./tools.js";
 import { registerPromptHandlers } from "./prompts.js";
 import { trackServerStart } from "./tracking.js";
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+const pkg = JSON.parse(readFileSync(join(__dirname, "..", "package.json"), "utf-8"));
 async function main() {
     // Connect to Claude Desktop IMMEDIATELY — no blocking auth here
     // Auth happens lazily on first Drive API call
-    const server = new Server({ name: "sad-mcp", version: "0.1.7" }, {
+    const server = new Server({ name: "sad-mcp", version: pkg.version }, {
         capabilities: {
             tools: {},
             prompts: {},
@@ -18,7 +24,7 @@ async function main() {
     trackServerStart();
     const transport = new StdioServerTransport();
     await server.connect(transport);
-    console.error("SAD MCP server started.");
+    console.error(`SAD MCP server v${pkg.version} started.`);
 }
 main().catch((err) => {
     console.error("SAD MCP failed to start:", err);

package/dist/prompts.js

@@ -22,8 +22,8 @@ const SKILLS = [
     },
     {
         id: "bpmn-diagram",
-        name: "BPMN Diagram",
-        description: "Create BPMN business process diagrams as interactive HTML/SVG files",
+        name: "BPMN Process Analysis",
+        description: "Analyze a business process and produce a structured BPMN 1.1 model for review",
     },
 ];
 // Internal skills: loadable via GetPrompt but not shown in ListPrompts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sad-mcp",
-  "version": "0.1.25",
+  "version": "0.1.27",
   "description": "MCP server for Software Analysis and Design course materials at BGU",
   "type": "module",
   "bin": {

package/skills/bpmn-diagram/SKILL.md

@@ -1,125 +1,215 @@
 ---
 name: bpmn-diagram
-description: Create BPMN (Business Process Model and Notation) diagrams as interactive HTML/SVG files. Use this skill when the user asks to create, model, or visualize a business process, workflow diagram, BPMN diagram, or process map. This is Phase 1 — structural modeling. It outputs a text model for user review before rendering.
+description: Analyze a business process and produce a structured BPMN 1.1 model for review. Outputs an HTML page with visual summary and embedded JSON model. Use when the user describes a process and wants it modeled.
 ---
 
-# BPMN Diagram Creation — Phase 1: Structural Model
+# BPMN Process Analysis
 
-This skill creates professional BPMN 1.1 diagrams in two steps. **This is Step 1 — you will build a structural text model only. No HTML, no SVG, no code.**
+Analyze a business process description and produce a structured BPMN 1.1 model. The output is an HTML page that presents the model for user review, with the machine-readable JSON model embedded for later use.
 
-After the user approves the model, you will use the `bpmn-render` prompt to generate the visual diagram.
+**You are producing an analysis, not a diagram. Do not generate any visual diagram, SVG, or drawing.**
 
-## CRITICAL RULES
+## Critical Modeling Rules
 
-1. **GATEWAYS have types**: Every gateway must be classified as XOR (exclusive), AND (parallel), or OR (inclusive). This determines the marker (X / + / O) drawn inside the diamond later.
+1. **CUSTOMERS / EXTERNAL PARTIES get their own POOL**: If a customer, patient, citizen, or external company (e.g., חברת אשראי, ספק) acts independently — they are a SEPARATE POOL with message flows. They are NOT a lane. The only exception: if the organization fully controls the participant's actions within its system (e.g., customer using a bank app).
 
-2. **CUSTOMERS / EXTERNAL PARTIES get their own POOL**: If a customer, patient, citizen, or external company (e.g., חברת אשראי, ספק) acts independently — they are a SEPARATE POOL with message flows. They are NOT a lane. The only exception: if the organization fully controls the participant's actions within its system (e.g., customer using a bank app).
+2. **DATA STORES are mandatory**: If any task involves "block account", "generate invoice", "credit account", "update record", "register", "look up", or any read/write to persistent state — a Data Store is required.
 
-3. **DATA STORES are mandatory**: If any task involves "block account", "generate invoice", "credit account", "update record", "register", "look up", or any read/write to persistent state — a Data Store is required with data associations to the relevant tasks.
+3. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the model. Never omit a participant.
 
-4. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the model. Never omit a participant.
+4. **GATEWAYS have types**: Every gateway must be classified as XOR (exclusive — one path), AND (parallel — all paths), or OR (inclusive — one or more paths).
 
-## Step 1 — Identify Participants
+## Analysis Steps
 
-List every actor/role mentioned. For each, classify as POOL or LANE:
+### Step 1 — Identify Participants
 
-- **POOL** (separate): The participant acts independently and communicates with the organization from outside. Examples: customer calling to cancel, patient arriving at a clinic, citizen filing a complaint, external company (credit card company, supplier, contractor).
-- **LANE** (within org pool): Internal role within the organization, OR the organization fully dictates how the participant performs activities within its system.
+List every actor/role. Classify each as POOL or LANE:
+
+- **POOL**: Acts independently, communicates from outside. Examples: customer calling to cancel, patient arriving at clinic, citizen filing complaint, external company (credit card, supplier, contractor).
+- **LANE**: Internal role, OR the organization controls how they perform activities within its system.
 - **The test**: "Does the organization orchestrate this participant's actions, or do they act independently?" Independent → POOL.
 
-## Step 2 — Identify Tasks
+### Step 2 — Identify Tasks
 
-List every action/task. For each task, specify which lane or pool it belongs to.
+List every action/task. Assign each to a specific lane or pool.
 
 Look for implied activities — phrases like "is expected to be in phone contact" or "will coordinate directly" describe real tasks, not annotations.
 
-## Step 3 — Identify Gateways (with type!)
+### Step 3 — Identify Gateways
 
-List every decision point. For each gateway specify:
-- **Type**: XOR (only one path taken), AND (all paths taken in parallel), or OR (one or more paths)
+List every decision point. For each:
+- **Type**: XOR, AND, or OR
 - **Question/condition**: What is being decided
-- **Branches**: The possible outcomes and where each leads
-- **Merge**: Where branches reconverge — merge gateways must also be listed with their type
-
-## Step 4 — Identify Data Stores
+- **Branches**: Possible outcomes and where each leads
+- **Merge**: Where branches reconverge (merge gateways must also specify type)
 
-Scan all tasks for persistent storage operations.
+### Step 4 — Identify Data Stores
 
-**Trigger words**: "system", "database", "account", "record", "registry".
-**Action verbs**: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status".
+Scan tasks for persistent storage. **Trigger words**: "system", "database", "account", "record", "registry". **Action verbs**: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status".
 
-If ANY task reads/writes shared persistent state → Data Store required. A system = a data store. An account = a data store.
+Any task that reads/writes shared persistent state → Data Store required. A system = a data store. An account = a data store.
 
-List each data store with its name and which tasks connect to it (read/write).
+### Step 5 — Identify Data Objects
 
-## Step 5 — Identify Data Objects
+List transient data flowing between tasks (e.g., "בקשת ביטול", "חשבונית זיכוי"). These are documents, not persistent systems.
 
-List specific pieces of data flowing between tasks (e.g., "בקשת ביטול", "חשבונית זיכוי"). These are transient documents, not persistent systems.
+### Step 6 — Identify Flows
 
-## Step 6 — Identify Flows
-
-- **Sequence flows** (within a pool): The order of tasks within each pool
+- **Sequence flows** (within a pool): Task ordering within each pool
 - **Message flows** (between pools): Every communication between separate pools. Check bidirectional — every message expecting a response needs a return flow.
 - **Data associations**: Connections between tasks and data stores / data objects.
 
-## Step 7 — Identify Events
+### Step 7 — Identify Events
 
 - **Start events**: One per pool
 - **End events**: One or more per pool (different outcomes)
-- **Intermediate events**: For passive waiting (not tasks) — when a participant waits for a signal/message from another participant
+- **Intermediate events**: For passive waiting — when a participant waits for a signal/message
 
-## Step 8 — Verify Completeness
+### Step 8 — Verify Completeness & Note Assumptions
 
 - Every pool has a complete flow: start → tasks/gateways → end
 - External parties have their full process modeled, not just a single task
-- Every message that expects a response has a return message flow
-
-## Required Output Format
-
-Output the model in this exact format:
-
+- List any assumptions you made about the process
+- List any open questions where the description was ambiguous
+
+## Output Format
+
+Generate a **single self-contained HTML file** with two parts:
+
+### Part 1: Visual Presentation (what the user sees)
+
+A clean, RTL Hebrew page with these sections:
+
+1. **Header**: Process title in Hebrew, "ניתוח תהליך BPMN 1.1" subtitle
+2. **Structure Overview card**: Shows number of pools and lanes as a simple hierarchy:
+   ```
+   🏊 מאגרים (Pools):
+   ├── לקוח (מאגר חיצוני — פועל באופן עצמאי)
+   └── חברת אישימוטו (מאגר ארגוני)
+       ├── שירות לקוחות
+       ├── שימור לקוחות
+       └── הנהלת חשבונות
+   ```
+3. **Workflow per pool/lane card**: For each pool and lane, show the task flow as a numbered list with gateway branches indented:
+   ```
+   שירות לקוחות:
+   1. קבלת פנייה ובדיקת תאריך
+   2. ⬦ XOR: כמה ימים מאז הרכישה?
+      ├── ≤ 7 ימים → 3. ביטול מנוי → 4. חסימת חשבון
+      ├── 7-14 ימים → העברה לשימור לקוחות
+      └── > 14 ימים → 5. הודעה על דחיית הבקשה
+   ```
+4. **Gateways card**: Table of all gateways with type, question, and branches
+5. **Data Stores card**: Each store with its connected tasks (reads/writes)
+6. **Data Objects card**: Each object with source and target
+7. **Message Flows card**: Between which pools, what's communicated, direction
+8. **Assumptions & Open Questions card**: Yellow/orange highlight for attention
+9. **Footer**: "כשהמודל מאושר, ניתן לבקש: 'צייר את דיאגרמת ה-BPMN'"
+
+**Styling guidelines:**
+- Use `Noto Sans Hebrew` from Google Fonts
+- `lang="he"` and `dir="rtl"` on the HTML element
+- Dark theme: `#1a1a2e` background, `#16213e` cards, white/light text
+- Color-coded cards: pools in blue, gateways in amber, data stores in green, messages in purple, assumptions in orange
+- Clean, modern look with rounded corners and subtle shadows
+
+### Part 2: JSON Model (embedded, machine-readable)
+
+Embed the structured model in a `<script type="application/json" id="bpmn-model">` tag. This is not visible to the user but available for later processing.
+
+**JSON Schema:**
+
+```json
+{
+  "title": { "he": "שם התהליך", "en": "Process Name" },
+  "pools": [
+    {
+      "id": "pool-id",
+      "name": "שם המאגר",
+      "type": "external",
+      "reason": "why this is a separate pool",
+      "lanes": []
+    },
+    {
+      "id": "org-id",
+      "name": "שם הארגון",
+      "type": "organization",
+      "reason": "main organization",
+      "lanes": [
+        { "id": "lane-id", "name": "שם המסלול" }
+      ]
+    }
+  ],
+  "tasks": [
+    {
+      "id": "task-id",
+      "name": "שם המשימה",
+      "pool": "pool-id",
+      "lane": "lane-id-or-null",
+      "description": "optional details"
+    }
+  ],
+  "gateways": [
+    {
+      "id": "gw-id",
+      "type": "XOR",
+      "role": "split",
+      "question": "מה השאלה?",
+      "pool": "pool-id",
+      "lane": "lane-id-or-null",
+      "branches": [
+        { "label": "תיאור הענף", "target": "task-or-gw-id" }
+      ]
+    }
+  ],
+  "dataStores": [
+    {
+      "id": "ds-id",
+      "name": "שם מאגר הנתונים",
+      "reads": ["task-id-1"],
+      "writes": ["task-id-2"]
+    }
+  ],
+  "dataObjects": [
+    {
+      "id": "do-id",
+      "name": "שם מסמך/נתון",
+      "from": "task-id",
+      "to": "task-id"
+    }
+  ],
+  "events": [
+    {
+      "id": "event-id",
+      "type": "start",
+      "pool": "pool-id",
+      "lane": "lane-id-or-null",
+      "name": "תיאור האירוע"
+    }
+  ],
+  "sequenceFlows": [
+    { "from": "element-id", "to": "element-id", "label": "optional" }
+  ],
+  "messageFlows": [
+    { "from": "pool-id", "to": "pool-id", "description": "מה מועבר" }
+  ],
+  "assumptions": [
+    "הנחה שנעשתה..."
+  ],
+  "openQuestions": [
+    "שאלה שדורשת הבהרה..."
+  ]
+}
 ```
-STRUCTURAL MODEL:
-
-POOLS:
-- [Pool name] — [reason: acts independently / external company]
-  Tasks: [task1] → [task2] → ...
-  Start: [description]
-  End(s): [description(s)]
-
-ORGANIZATION POOL: [org name]
-  LANE: [lane name]
-    Tasks: [task1] → [task2] → ...
-  LANE: [lane name]
-    Tasks: ...
-  Start: [description]
-  End(s): [description(s)]
-
-GATEWAYS:
-- [G1] Type: XOR | Question: [question] | In: [lane/pool] | Branches: [branch1 → ..., branch2 → ...]
-- [G2] Type: XOR (merge) | In: [lane/pool] | Merges: [branches from G1]
-
-DATA STORES:
-- [Store name] — reads: [task X, task Y] | writes: [task Z]
-
-DATA OBJECTS:
-- [Object name] — from: [task X] → to: [task Y]
-
-MESSAGE FLOWS:
-- [Pool A] → [Pool B]: [what is communicated]
-- [Pool B] → [Pool A]: [response]
-```
-
-## After Outputting the Model
 
-Present the model and ask the user:
+## After Generating the Output
 
-**"הנה המודל המבני של התהליך. האם לעבור לשלב הבא ולייצר את הדיאגרמה, או שיש שינויים?"**
+Tell the user in the conversation (not in the HTML):
 
-When the user confirms, use the **`bpmn-render`** prompt to generate the visual diagram. Pass it the approved structural model.
+**"יצרתי ניתוח מבני של התהליך. אפשר לעיין בקובץ ה-HTML ולבדוק שהמודל נכון. כשהמודל מאושר, אפשר לבקש ממני לצייר את דיאגרמת ה-BPMN."**
 
 ## Hebrew Language Guidelines
 
-Use the **male grammatical form** (זכר) for all roles and participants:
+Use the **male grammatical form** (זכר) for all roles:
 - ✅ רופא, אח, מטופל, לקוח, מנהל, עובד, משתמש, סטודנט
 - ❌ אחות, מטופלת, לקוחה, מנהלת, מזכירה