The MoziChem-MCP server enables AI assistants to perform advanced chemical engineering and thermodynamic calculations using the Model Context Protocol (MCP).
Core Capabilities:
Equation of State (EOS) Calculations: Utilize models like Peng-Robinson, Soave-Redlich-Kwong, Redlich-Kwong, and van der Waals for single and multi-component systems
Fugacity Calculations: Compute fugacity for single-gas components, single-liquid components (with EOS or Poynting correction methods), and gas mixtures with custom solver configurations
Phase Behavior Analysis: Perform vapor-liquid equilibrium, multi-component phase equilibrium, bubble point, and dew point calculations
Flash Calculations: Execute temperature and pressure flash calculations for complex mixtures
EOS Roots Analysis: Analyze equation of state roots to understand phase behavior and thermodynamic properties
Reference Data Retrieval: Access reference inputs, data, and equations for specific calculation methods
AI Integration: Seamlessly integrate with AI tools like Claude Desktop for interactive chemical engineering workflows
MCP server package is distributed through PyPI for easy installation and dependency management
Provides chemical engineering calculation tools including equation of state models, thermodynamic property predictions, vapor-liquid equilibrium calculations, and phase behavior analysis
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MoziChem-MCP calculate bubble point for a 50/50 methane/ethane mixture at 5 bar"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A collection of Model Context Protocol (MCP) servers for chemical engineering and chemistry applications, built on top of the powerful MoziChem framework. This repository provides specialized MCP tools that enable AI assistants to perform complex chemical calculations, thermodynamic modeling, and process engineering tasks.
MoziChem-MCP bridges the gap between AI language models and chemical engineering calculations by providing structured access to thermodynamic models, equation of state calculations, phase equilibrium computations, and other essential chemical engineering tools through the Model Context Protocol.
Important Notes: This repository is actively maintained and will be updated with new MCP servers and features in the future. Stay tuned for additions to support more chemical engineering domains.
Related MCP server: Corrosion Engineering MCP Server
🌡️ EOS Models MCP (eos-models-mcp)
Equation of State calculations using various models (Peng-Robinson, Soave-Redlich-Kwong, Redlich-Kwong, van der Waals)
Fugacity calculations for pure components and mixtures
Thermodynamic property predictions
Phase behavior analysis
⚖️ Flash Calculations MCP (flash-calculations-mcp)
Vapor-liquid equilibrium calculations
Multi-component phase equilibrium
Temperature and pressure flash calculations
Bubble point and dew point calculations
Python 3.13 or higher
uv package manager (recommended)
# Clone the repository
git clone https://github.com/sinagilassi/mozichem-mcp.git
cd mozichem-mcp
# Install using uv (recommended)
uv sync
# Or install using pip
pip install -e .pip install mozichem-mcpEach MCP server can be run independently:
# Using uvx with the published package
uvx --from mozichem-mcp mozichem-mcp-eos-models
# Or run directly with Python (if installed locally)
python -m mozichem_mcp.mcp.eos_models# Using uvx with the published package
uvx --from mozichem-mcp mozichem-mcp-flash-calculation
# Or run directly with Python (if installed locally)
python -m mozichem_mcp.mcp.flash_calculationThese MCP servers are designed to work with AI assistants that support the Model Context Protocol, such as:
Claude Desktop
Other MCP-compatible AI tools
Add to your Claude Desktop configuration:
{
"mcpServers": {
"mozichem-eos": {
"command": "uvx",
"args": ["--from", "mozichem-mcp", "mozichem-mcp-eos-models"]
},
"mozichem-flash": {
"command": "uvx",
"args": ["--from", "mozichem-mcp", "mozichem-mcp-flash-calculation"]
}
}
}Once integrated with an AI assistant, you can perform calculations like:
"Calculate the fugacity of methane at 300K and 10 bar using the Peng-Robinson equation of state"
"Perform a flash calculation for a mixture of 40% methane and 60% ethane at 250K and 20 bar"Process Design: Use for preliminary process calculations and design
Research: Integrate with computational workflows for chemical engineering research
Education: Enhance learning with interactive thermodynamic calculations
Industry: Support engineering decisions with reliable thermodynamic data
Contributions are welcome! Please feel free to submit a Pull Request to improve the project.
This project is licensed under the MIT License. You are free to use, modify, and distribute this software in your own applications or projects. However, if you choose to use this app in another app or software, please ensure that my name, Sina Gilassi, remains credited as the original author. This includes retaining any references to the original repository or documentation where applicable. By doing so, you help acknowledge the effort and time invested in creating this project.
For any questions, contact me on LinkedIn.
⭐ Star this repository if you find it useful for your chemical engineering projects!
🐛 Report issues or 💡 suggest new features in the Issues section.
This function calculates the fugacity of a mixture of gases using different equation of states (EOS) including Peng-Robinson (PR), Soave-Redlich-Kwong (SRK), Redlich-Kwong (RK), and van der Waals (vdW).
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | List of components with their properties | |
| temperature | Yes | Temperature of the system | |
| pressure | Yes | Pressure of the system | |
| eos_model | No | EOS model to use, e.g., 'SRK', 'PR' | SRK |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does (calculates fugacity) and lists supported EOS models, but doesn't describe important behavioral aspects: computational complexity, accuracy limitations, assumptions about ideal mixing, whether it handles phase equilibria, what the output format looks like, or potential error conditions. For a complex thermodynamic calculation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality upfront. It wastes no words and gets directly to the point. However, it could be slightly more structured by separating the 'what' from the 'how' or adding brief context about fugacity calculations in thermodynamics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (thermodynamic calculations with multiple EOS models), no annotations, but with both comprehensive input schema (100% coverage) and output schema present, the description is minimally adequate. The output schema existence means the description doesn't need to explain return values, but for such a specialized tool, more context about assumptions, limitations, or typical use cases would be helpful despite the structured data coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions the EOS models (which are already enumerated in the schema) but doesn't provide additional context about when to choose specific models, their relative accuracy, or limitations. With comprehensive schema coverage, the baseline of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'calculates the fugacity of a mixture of gases using different equation of states'. It specifies the verb ('calculates'), resource ('fugacity of a mixture of gases'), and methods ('Peng-Robinson, Soave-Redlich-Kwong, Redlich-Kwong, and van der Waals'). However, it doesn't explicitly differentiate from sibling tools like 'calc_gas_component_fugacity' or 'calc_liquid_component_fugacity', which appear to calculate fugacity for individual components rather than mixtures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'calc_gas_component_fugacity' or 'calc_liquid_component_fugacity', nor does it specify scenarios where this mixture calculation is appropriate versus component-level calculations. The only implied usage is for gas mixture fugacity calculations, but no explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This function calculates the fugacity of single-gas component using different equation of states (EOS) including Peng-Robinson (PR), Soave-Redlich-Kwong (SRK), Redlich-Kwong (RK), and van der Waals (vdW).
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component name and properties | |
| temperature | Yes | Temperature of the system | |
| pressure | Yes | Pressure of the system | |
| eos_model | No | EOS model to use, e.g., 'SRK', 'PR' | SRK |
| solver_method | No | Solver method for fugacity calculation, e.g., 'least-square method', 'fsolve', 'root' | ls |
| custom_reference_content | No | Custom reference content provided by PyThermoDB, this consists of data and equations for all components. | None |
| custom_reference_config | No | Custom reference configuration provided by PyThermoDB, this consists of the reference for data and equations for each component. | None |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the calculation method (EOS models), it doesn't describe what the tool returns, potential side effects, error conditions, computational complexity, or any behavioral traits. For a scientific calculation tool with 7 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose. It's appropriately sized for the tool's complexity, though it could be slightly more structured by front-loading the most critical information about single-gas component focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, scientific calculation) and the presence of an output schema, the description is minimally adequate. However, with no annotations and multiple sibling tools, it should provide more context about when to use this specific tool versus alternatives and what the calculation entails. The output schema existence reduces the need to describe return values, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions the EOS models (which are already in the schema's enum) but doesn't provide additional context about parameter interactions, default behaviors, or practical usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function's purpose: 'calculates the fugacity of single-gas component using different equation of states'. It specifies the resource (single-gas component fugacity) and the method (EOS models: PR, SRK, RK, vdW). However, it doesn't explicitly differentiate from sibling tools like 'calc_fugacity_gas_mixture' or 'calc_liquid_component_fugacity', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are clear sibling tools for gas mixtures and liquid components, but the description doesn't mention these distinctions or provide any context about appropriate use cases, prerequisites, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This function calculates the fugacity of single-liquid component using different equation of states (EOS) including Peng-Robinson (PR), Soave-Redlich-Kwong (SRK), Redlich-Kwong (RK), and van der Waals (vdW). The fugacity is calculated based on the EOS used for the gas phase and Poynting correction.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component name and properties | |
| temperature | Yes | Temperature of the system | |
| pressure | Yes | Pressure of the system | |
| eos_model | No | EOS model to use, e.g., 'SRK', 'PR' | SRK |
| solver_method | No | Solver method for fugacity calculation, e.g., 'least-square method', 'fsolve', 'root' | ls |
| liquid_fugacity_mode | No | Mode for liquid fugacity calculation, 'EOS' or 'Poynting' | EOS |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the calculation method and EOS options but doesn't address important behavioral aspects like computational complexity, accuracy limitations, error conditions, or what the output represents. For a complex thermodynamic calculation tool, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that convey the core functionality. The first sentence clearly states what the tool does and the available EOS options, while the second provides additional context about the calculation basis. There's no wasted language, though it could benefit from more behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (thermodynamic calculations with multiple EOS models and solver methods) and the presence of an output schema, the description is minimally adequate. However, with no annotations and significant behavioral aspects unaddressed (like computational characteristics or limitations), it doesn't provide complete context for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, providing good documentation for all parameters. The description adds minimal value beyond the schema, mentioning only 'EOS used for the gas phase and Poynting correction' which relates to the 'eos_model' and 'liquid_fugacity_mode' parameters but doesn't provide additional semantic context about how these choices affect the calculation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('calculates the fugacity'), target ('single-liquid component'), and methods ('using different equation of states including Peng-Robinson, Soave-Redlich-Kwong, Redlich-Kwong, and van der Waals'). It distinguishes from siblings like 'calc_fugacity_gas_mixture' by specifying 'single-liquid component' rather than gas mixtures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'calc_gas_component_fugacity' or 'calc_fugacity_gas_mixture'. It mentions the calculation is 'based on the EOS used for the gas phase and Poynting correction' but doesn't explain when this approach is appropriate or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This function analyzes the roots of the EOS for a given component at specified temperature and pressure.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component name and properties | |
| temperature | Yes | Temperature of the system | |
| pressure | Yes | Pressure of the system | |
| eos_model | No | EOS model to use, e.g., 'SRK', 'PR' | SRK |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'analyzes' but doesn't clarify whether this is a read-only calculation, if it modifies data, what the output contains, or any performance characteristics. The description is too minimal for a tool with computational complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core function. It's appropriately sized for a tool with good schema documentation, though it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. However, for a computational tool with no annotations and sibling tools available, the description should provide more context about when to use this specific tool and what 'analyzes the roots' means in practical terms.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'temperature and pressure' but adds no additional semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('analyzes') and resource ('roots of the EOS for a given component'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'multi_component_eos_roots_analysis', which appears to handle multiple components versus this single-component tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'multi_component_eos_roots_analysis' or other EOS-related tools. It mentions temperature and pressure but doesn't specify typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This function retrieves the reference inputs required for a specific method, including data and equations.
| Name | Required | Description | Default |
|---|---|---|---|
| method_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this 'retrieves' reference inputs, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns structured data, or handles errors. The description is minimal and lacks essential operational context for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be more informative without sacrificing brevity. The structure is straightforward but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), low parameter complexity (1 parameter), and no annotations, the description is minimally complete. It states the purpose but lacks usage guidelines, parameter details, and behavioral context, making it adequate only in a basic sense with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'a specific method' but doesn't explain what 'method_name' represents, valid formats, examples, or constraints. The description adds minimal meaning beyond the bare schema, failing to clarify parameter semantics adequately for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'reference inputs for a specific method', specifying it includes 'data and equations'. It distinguishes this as a lookup function rather than a calculation tool like its siblings. However, it doesn't explicitly differentiate from potential similar retrieval tools (none present in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for method selection, or relationships to sibling calculation tools (e.g., whether this should be called before or after them). It merely states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This function analyzes the roots of the EOS for a mixture of components at specified temperature and pressure.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | List of components with their properties | |
| temperature | Yes | Temperature of the system | |
| pressure | Yes | Pressure of the system | |
| eos_model | No | EOS model to use, e.g., 'SRK', 'PR' | SRK |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions analysis but doesn't disclose what 'analyzes the roots' entails computationally, whether it's read-only or mutating, error conditions, performance characteristics, or output format. For a complex scientific tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core function without unnecessary words. It's appropriately sized for the tool's complexity, though it could be more front-loaded with key distinctions from siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's scientific complexity, 4 parameters, no annotations, but with a rich input schema (100% coverage) and an output schema (implied by context signals), the description is minimally adequate. It covers the basic purpose but lacks context on usage, behavioral traits, and differentiation from siblings, which are important for an AI agent to use it correctly in a server with related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed documentation for all parameters. The description adds minimal value beyond the schema—it mentions 'mixture of components' which relates to the 'components' parameter and 'specified temperature and pressure' which maps to those parameters, but doesn't explain why these inputs are needed or their role in EOS analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'analyzes the roots of the EOS for a mixture of components at specified temperature and pressure.' It specifies the verb ('analyzes'), resource ('roots of the EOS'), and scope ('mixture of components'), but doesn't explicitly differentiate from sibling tools like 'component_eos_roots_analysis' which might be for single components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'calc_fugacity_gas_mixture' or 'component_eos_roots_analysis', nor does it specify prerequisites, constraints, or typical use cases for EOS root analysis in mixtures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is potential confusion between 'calc_fugacity_gas_mixture' and 'calc_gas_component_fugacity' since both involve gas fugacity calculations. The descriptions clarify that one is for mixtures and the other for single components, but the naming could lead to initial ambiguity. The other tools target clearly different operations like root analysis and method reference retrieval.
The naming follows a consistent snake_case pattern throughout, which is good. However, there is a mix of verb styles: 'calc_' prefix for fugacity tools versus 'get_' and 'component_'/'multi_component_' prefixes for others. This minor inconsistency in verb usage prevents a perfect score, but the overall structure remains readable and predictable.
With 6 tools, this server is well-scoped for its chemical engineering domain focused on fugacity calculations and EOS analysis. Each tool appears to serve a specific purpose, such as fugacity calculations for different phases, root analysis, and reference retrieval, making the count appropriate without being overwhelming or insufficient.
The tool set covers key aspects of fugacity and EOS analysis, including calculations for gas mixtures, single gas components, and liquid components, as well as root analysis for both single and multi-component systems. A minor gap is the lack of tools for updating or modifying inputs or results, but core workflows are well-covered for the apparent domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
AI orchestration for computational chemistry and HPC workflows.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sinagilassi/mozichem-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
