formlab-mcp 0.6.0 → 0.6.3

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "formlab-mcp",
-  "version": "0.6.0",
+  "version": "0.6.3",
   "mcpName": "io.github.juliu1980/formlab-mcp",
-  "description": "Read-only Model Context Protocol server for FormLab \u2014 lets Claude (and other MCP clients) read and analyze your FormLab data, from a local export file OR your live cloud workspace.",
+  "description": "Read-only Model Context Protocol server for FormLab — lets Claude (and other MCP clients) read and analyze your FormLab data, from a local export file OR your live cloud workspace.",
   "type": "module",
   "bin": {
     "formlab-mcp": "./index.js"
@@ -38,4 +38,4 @@
     "url": "https://github.com/juliu1980/FormLab",
     "directory": "mcp"
   }
-}
+}

package/tools/analytics.js

@@ -503,6 +503,11 @@ const _DOE_TYPE_LABELS = {
   full: 'Full-factorial', pb: 'Plackett-Burman', ccd: 'Central Composite',
   bbd: 'Box-Behnken', lhs: 'Latin Hypercube', simplex: 'Simplex-Lattice', dopt: 'D-optimal',
 };
+// The model key a design was optimised for. Only D-optimal stores one; the other
+// generators impose their own structure, so there is nothing to report.
+function _doeModelKey(d) {
+  return d && d.designType === 'dopt' ? ((d.settings || {}).doptModel || null) : null;
+}
 // Factor names come off the RECORD first so a design still reads correctly
 // after an ingredient is renamed or deleted.
 function _doeNamer(d, db) {
@@ -526,8 +531,28 @@ function _trimDoeDesign(d, db) {
     factors: (d.factors || []).map(f => ({ ingredient: f.name || nameOf(f.ingredientId), low: f.low, high: f.high, unit: f.unit || '%' })),
     constraints: (d.constraints || []).map(c => _doeConstraintText(c, nameOf)),
     mixtureMode: !!d.mixtureMode,
+    // The model the design was built for. Lives in settings, so without this a
+    // caller listing designs can see "D-optimal" but not whether it was fitted
+    // as a process or a Scheffé (mixture) model — which changes what the runs
+    // and the D-efficiency mean.
+    model: _doeModelKey(d) || null,
+    modelLabel: _DOE_MODEL_LABELS[_doeModelKey(d)] || _doeModelKey(d) || null,
     // Only D-optimal computes one; null here means "not applicable", not "failed".
     dEfficiency: Number.isFinite(d.dEfficiency) ? +d.dEfficiency.toFixed(2) : null,
+    dEfficiencyKind: Number.isFinite(d.dEfficiency)
+      ? (d.dEfficiencyKind || (/^scheffe-/.test(String((d.settings || {}).doptModel || '')) ? 'relative' : 'absolute'))
+      : null,
+    // The relative/absolute PAIR is the point: relative is the grade ("as good as
+    // this region allows"), absolute is what the rules cost. Shipping only the
+    // relative one lets a caller read 100% on a heavily restricted region and
+    // conclude the restrictions were free. Null unless the two actually differ.
+    // Both are percentages on a 0-100 scale. The absolute one goes very small on a
+    // tightly restricted region (a real mixture measured 0.027), so it keeps more
+    // decimals below 1 — toFixed(2) alone would report 0.03, and the UI's own
+    // toFixed(0) renders it "0%".
+    dEfficiencyAbsolute: Number.isFinite(d.dEfficiencyAbsolute)
+      ? +d.dEfficiencyAbsolute.toFixed(d.dEfficiencyAbsolute < 1 ? 4 : 2)
+      : null,
     droppedRuns: d.droppedRuns || 0,
     response: d.responseText || null,
     createdAt: d.createdAt,
@@ -615,7 +640,16 @@ const get_doe_design = {
     const linked = (d.formulationIds || []).map(id => formsById.get(id)).filter(Boolean);
     const out = {
       ...base,
-      balanceFactor: d.mixtureMode ? nameOf(d.balanceFactorId) : null,
+      // A balance factor is the component that absorbs the slack when the mixture
+      // is imposed on a design that knows nothing about it (the classical types).
+      // Simplex-Lattice and Scheffé D-optimal design every component on the
+      // simplex, so there is nothing to absorb and balanceFactorId is legitimately
+      // null. Passing that null to nameOf() fell through its `id || '?'` tail and
+      // answered "?", which reads as missing data rather than as "not applicable".
+      balanceFactor: d.mixtureMode && d.balanceFactorId ? nameOf(d.balanceFactorId) : null,
+      balanceFactorNote: d.mixtureMode && !d.balanceFactorId
+        ? 'No balance factor: this design places its runs on the blend simplex directly, so every component is designed and each run already sums to the mixture total. Nothing has to absorb the remainder.'
+        : undefined,
       settings,
       augmentedFromProjectId: d.augmentedFromProjectId || null,
       formulationsGenerated: (d.formulationIds || []).length,
@@ -623,7 +657,9 @@ const get_doe_design = {
       notes: d.notes || null,
     };
     if (Number.isFinite(d.dEfficiency)) {
-      out.dEfficiencyNote = 'D-efficiency compares designs fitting the SAME model at the SAME run count. It is a relative score, not a pass mark, and cannot be compared across different models.';
+      out.dEfficiencyNote = out.dEfficiencyKind === 'relative'
+        ? 'RELATIVE D-efficiency: this design against the best achievable for the same model and run budget IN ITS OWN DESIGN REGION, so 100% means "as good as this model and budget allow there". It is NOT the textbook absolute measure. It is used whenever the orthogonal ideal is unreachable by construction — a mixture (components collinear, so even a perfect mixture design scores about 33% on the absolute scale) or a region carved by linear constraints (an orthogonal design generally does not survive the cut). Do not compare this figure with an unconstrained design\'s D-efficiency or with another tool\'s.'
+        : 'ABSOLUTE D-efficiency: 100·|XᵀX|^(1/p)/N on coded factors, where 100% is the orthogonal ideal. Compare only against designs fitting the SAME model at the SAME run count; it is not a pass mark and does not transfer across model forms.';
     }
     if (args.include_runs !== false) {
       const facs = d.factors || [];