PyThermoModels-MCP is a Model Context Protocol server for running selected PyThermoModels calculations, including EOS root checks, pure-component and mixture fugacity, NRTL and UNIQUAC activity coefficients, tau_ij parameters, and pyThermoDB YAML reference validation.
Critical gaps across all tools. Input schemas are present but severely underspecified: all 10 tools collapse parameters into a single 'args' object with type 'object' and minimal description. No individual parameter types, constraints, or detailed descriptions visible. Tool descriptions are generic and lack actionable context (e.g., 'Calculate pure-component gas fugacity using pyThermoDB YAML reference_content supplied in args' does not explain WHEN to use this vs. liquid_fugacity, what the output contains, or how to interpret results). No output schemas documented. No error handling guidance. No parameter validation rules. Naming is acceptable (verb_noun pattern) but descriptions fail to meet the 10-1024 character guideline with substance.
Calculate pure-component gas fugacity using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Calculate pure-component liquid fugacity using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Calculate mixture fugacity using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Calculate NRTL activity coefficients using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Calculate NRTL tau_ij using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Calculate UNIQUAC activity coefficients using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
All tools (except check_yaml_reference) collapse parameters into a single 'args' object with type 'object' and generic description 'Pydantic model containing [field list]'. No individual parameter types, constraints, enums, or detailed descriptions are visible in the schema. LLMs cannot infer parameter meaning or valid ranges.
Tool descriptions are generic and lack actionable context. E.g., 'Calculate pure-component gas fugacity using pyThermoDB YAML reference_content supplied in args to build the ModelSource' does not explain WHEN to use this tool, what the output contains, how to interpret results, or how it differs from similar tools (e.g., liquid_fugacity). Descriptions fail to guide LLM tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Calculate UNIQUAC tau_ij using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Check mixture EOS roots using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Check pure-component EOS roots using pyThermoDB YAML reference_content supplied in args to build the ModelSource.
Validate pythermodb YAML reference content for use with pyThermoDB.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract required fields (e.g., does calculate_gas_fugacity return a single value or a structured object with fugacity, temperature, pressure, units?). This violates the baseline that 100% of A+ tools have documented return types.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., if reference_content is invalid YAML, does the tool return a parse error? Should the LLM retry or call check_yaml_reference first?
check_yaml_reference accepts 'reference_content' as a string but provides no format constraints, length limits, or examples of valid YAML structure. LLMs cannot validate input before calling the tool.