Model Context Protocol server with GNNPCSAFT tools for thermodynamic property prediction and PC-SAFT equation-of-state calculations
This server implements 12 scientific computation tools for thermodynamic property prediction. While all tools have basic descriptions and registered schemas, the quality is inconsistent. Tool names follow verb-noun convention (batch_*, mixture_*, optimize_*), which is good. However, descriptions are highly technical and lack the clarity needed for LLM-based tool selection, many do not explain WHEN to use the tool or what prerequisites are required. Parameter descriptions exist but are minimal (often single-phrase without format/constraint guidance). Output schemas are not explicitly documented in the code. Error handling is absent from visible code, no recovery guidance or actionable error messages. The server relies on implicit scientific domain knowledge rather than explicit, actionable documentation. Technical accuracy is high (PC-SAFT is a legitimate equation-of-state model), but tool definitions prioritize domain specificity over LLM usability.
Calculates critical points `[Temperature (K), Pressure (Pa), Density (mol/m³)]` with PC-SAFT for a list of SMILES. The GNNPCSAFT model is used to predict PCSAFT parameters.
Transform a list of InChI to SMILES.
Calcultes molecular weight in `g/mol` for a list of SMILES.
Predict PC-SAFT parameters `[m, sigma, epsilon/kB, kappa_ab, epsilon_ab/kB, dipole moment, na, nb, MW]` for a list of SMILES with the GNNPCSAFT model.
Calculates pure liquid density in `mol/m³` with PC-SAFT for a list of SMILES. The state is the same for all molecules. The GNNPCSAFT model is used to predict PCSAFT parameters.
Calculates pure liquid enthalpy of vaporization in `kJ/mol` with PC-SAFT for a list of SMILES. The temperature is the same for all molecules. The GNNPCSAFT model is used to predict PCSAFT parameters.
Output schemas are not documented. Tools return computed properties (density, pressure, temperature) but the structure and units of returned objects are not specified in visible code. LLMs cannot plan downstream operations without knowing the response format.
Parameter descriptions lack actionable constraints. 'SMILES of the molecules' does not explain valid SMILES format, encoding requirements, or what happens if invalid SMILES are provided. Similarly, 'Temperature (K)' lacks bounds (e.g., 'must be >0 and <10000 K').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Calculates pure vapor pressure in `Pa` with PC-SAFT for a list of SMILES. The temperature is the same for all molecules. The GNNPCSAFT model is used to predict PCSAFT parameters.
Transform a list of SMILES to InChI.
Calculates mixture liquid density (mol/m³) with PC-SAFT.
Calculates mixture `(Bubble point (Pa), Dew point (Pa))` with PC-SAFT.
Optimize the kij interaction parameter for a binary mixture with LLE experimental data, if available. Experimental Data is from the `ThermoML Archive` (https://doi.org/10.18434/mds2-2422).
Optimize the kij interaction parameter for a binary mixture with VLE experimental data, if available. Experimental Data is from the `ThermoML Archive` (https://doi.org/10.18434/mds2-2422).
No error handling or recovery guidance visible in code. Tools accept scientific input (SMILES, temperatures, pressures) but do not document what constitutes invalid input, what errors are returned, or how to recover. E.g., invalid SMILES should trigger a clear message; out-of-bounds temperature should suggest valid ranges.
Tool descriptions lack domain-independent context. Descriptions assume the user understands PC-SAFT, critical points, enthalpy of vaporization, etc. For a generalist LLM, 'Calculates critical points [Temperature (K), Pressure (Pa), Density (mol/m³)]' does not explain WHEN to call this tool or what a critical point is used for in real workflows.
Parameter 'state' in batch_pure_density and mixture_density is under-documented. It is described as 'A list with [Temperature (K), Pressure (Pa)]' but the actual JSON Schema shows type 'array' with generic numeric items, no type enforcement for individual elements, no ordering guarantee, no clear error if the array has wrong length.
Batch tools do not document result structure for arrays. batch_predict_pcsaft_parameters returns a list of SMILES, but does not specify whether the output is a list of 9-element arrays (one per SMILES), how errors within the batch are handled (partial success vs. fail-all), or the field order of the output.
No pagination or result limits documented. batch_* tools accept arrays of SMILES but do not document maximum array size, per-item timeout, or how to handle large batches (100s or 1000s of SMILES). This can cause context window exhaustion or timeouts without clear guidance.
optimize_binary_kij_with_lle and optimize_binary_kij_with_vle reference external ThermoML Archive data but do not document availability. If experimental data is unavailable for a SMILES pair, the tool will likely fail silently or return an error. Error messages should guide the user on how to provide fallback data or use defaults.