Click on "Deploy 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 Perform a flash calculation for a 50% methane, 50% ethane mixture at 250K and 20 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: FLASK-tools
🌡️ 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.
The Bubble-Pressure (BP) calculation determines the pressure at which the first bubble of vapor forms when a liquid mixture is heated at a constant temperature. It is used to find the pressure for a given temperature at which the liquid will begin to vaporize.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | List of components with their properties | |
| temperature | Yes | Temperature of the system |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It clearly describes what the calculation determines and under what thermal condition. It does not discuss the ideal-vapor/ideal-liquid assumption, but this is embedded in the tool's name and is common across the sibling set.
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 compact and front-loaded with the definition of bubble pressure. The second sentence partially restates the first ('find the pressure... begin to vaporize'), making it slightly redundant, but overall it is efficient.
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?
For a two-parameter calculation tool with full schema coverage and an output schema, the description is sufficiently complete. It explains the physical meaning and the intended use, though it could add an explicit note about the ideal-model assumption or contrast with dew-pressure.
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 input schema already documents 'components' and 'temperature' meaningfully. The description adds no parameter-specific detail, but none is needed beyond the schema baseline.
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 names the specific resource ('Bubble-Pressure calculation') and a precise verb ('determines the pressure at which the first bubble of vapor forms'). It also explicitly ties the calculation to a given temperature and liquid vaporization, which distinguishes it from bubble-temperature and dew-point 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?
It provides clear usage context: use this when you need the pressure at which a liquid mixture begins to vaporize at a specified temperature. It does not explicitly contrast with dew-pressure calculations, but the physical scenario is sufficiently stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Bubble-Temperature (BT) calculation determines the temperature at which the first bubble of vapor forms when a liquid mixture is heated at a constant pressure. It is used to find the temperature for a given pressure at which the liquid will begin to vaporize.
| Name | Required | Description | Default |
|---|---|---|---|
| pressure | Yes | Pressure of the system | |
| components | Yes | List of components with their properties | |
| solver_method | No | Method to use for solving the bubble temperature calculation. Options are 'root', 'least-squares', or 'fsolve'. | root |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only describes the physical phase-equilibrium concept and does not mention the ideal vapor/liquid model assumption, iterative solving behavior, solver_method effects, or any numerical caveats.
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 only two sentences and front-loaded with the purpose, but the second sentence largely restates the first: both describe finding the temperature at which vaporization begins. It is not padded, but it is slightly redundant.
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?
The input and output schemas cover structured details, and the core definition is present. However, for a thermodynamic tool with several closely related siblings, the description is missing the ideal vapor/liquid assumption and explicit selection criteria, making it minimally adequate rather than complete.
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 pressure, components, and solver_method. The description adds no parameter-specific information beyond the physical context, which keeps this at the baseline for fully covered schemas.
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 states a specific verb and resource: 'determines the temperature at which the first bubble of vapor forms' at a constant pressure. It clearly identifies the bubble-temperature calculation, though it does not explicitly contrast with the sibling dew-point or bubble-pressure tools, so it lacks full sibling differentiation.
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 implies usage context: find the temperature for a given pressure at which a liquid begins to vaporize. However, it provides no explicit guidance about when not to use this tool versus the bubble-pressure, dew-temperature, or dew-pressure siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Dew-Pressure (DP) calculation determines the pressure at which the first drop of liquid condenses from a vapor mixture when cooled at a constant temperature. It is used to find the pressure for a given temperature at which the vapor will begin to condense.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | List of components with their properties | |
| temperature | Yes | Temperature of the system |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the physical meaning but does not disclose that the tool assumes ideal vapor/liquid behavior (as implied by the name), nor does it mention input constraints (e.g., components should be in gas phase, mole fractions sum to 1). It also does not state that this is a read-only calculation. While the description is not misleading, it leaves behavioral aspects unaddressed.
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 two concise sentences with no filler. It front-loads the definition and then gives the usage context. Every sentence serves a purpose, making it highly efficient and well-structured.
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?
For a calculation tool, the description is fairly complete: it defines the calculation, its use case, and the inputs (temperature). It has an output schema (not shown but present), which covers return values. However, it could add context about the ideal assumption and input phase requirements, which are important for a thermodynamic calculation. These gaps prevent a 5, but the overall completeness is good.
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 coverage is 100%, so both parameters (components and temperature) are documented in the schema. The description adds minimal value beyond that, only mentioning 'given temperature' which is already clear from the schema. It does not elaborate on how components should be specified or any constraints, but the schema already covers the basics. A baseline 3 is appropriate.
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: it determines the pressure at which the first drop of liquid condenses from a vapor mixture at a constant temperature. It uses a specific verb ('determines') and resource ('dew-pressure calculation'), and distinguishes itself from siblings like bubble pressure and dew temperature by focusing on pressure at dew point.
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 clear context: it is used to find the pressure for a given temperature when vapor begins to condense. This implies the intended scenario (constant temperature, finding pressure) and indirectly differentiates from bubble-point calculations. It does not explicitly list exclusions or alternatives, but the sibling names (bubble pressure, dew temperature) make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Dew-Temperature (DT) calculation determines the temperature at which the first drop of liquid condenses from a vapor mixture when cooled at a constant pressure. It is used to find the temperature for a given pressure at which the vapor will begin to condense.
| Name | Required | Description | Default |
|---|---|---|---|
| pressure | Yes | Pressure of the system | |
| components | Yes | List of components with their properties | |
| solver_method | No | Method to use for solving the dew temperature calculation. Options are 'root', 'least-squares', or 'fsolve'. | least-squares |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions constant pressure but does not disclose the underlying assumption of ideal vapor/liquid behavior (which is in the tool name but not described), nor any limitations, required conditions, or error scenarios. For a thermodynamic calculation, this is a significant gap.
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 only two sentences, which is concise, but the second sentence largely repeats the first ('first drop of liquid condenses' vs 'vapor will begin to condense'). It is front-loaded with the core purpose but wastes a sentence on redundancy. It could be tightened while preserving clarity.
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?
For a complex thermodynamic calculation with no annotations, the description is incomplete. It does not mention the ideal gas/liquid assumption, which is central to the tool's applicability, nor does it specify constraints like requiring multiple components or the role of pressure. The output schema exists, so return values are covered, but the description leaves critical context (e.g., that it only applies to ideal systems) missing.
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 baseline is 3. The description adds minimal value beyond the schema: it implicitly references pressure and components but does not explain how they should be used together (e.g., that components must be a vapor mixture, or what solver_method does beyond its enum). The description does not compensate for any ambiguity, but the schema already documents each field.
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 determines the dew temperature (first drop of liquid condenses) at a given pressure, using specific language ('determines', 'find the temperature'). The resource is explicit (dew temperature) and the action is distinct from siblings like bubble temperature or pressure calculations, so an agent can distinguish it without opening other definitions.
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 gives clear context: 'used to find the temperature for a given pressure at which the vapor will begin to condense.' However, it does not mention alternatives or explicitly state when not to use it (e.g., for bubble point or non-ideal systems). It implies the scenario (constant pressure, vapor condensing) but does not contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Flash Isothermal (FI) calculation determines the phase equilibrium of a liquid mixture at a constant temperature, calculating the vapor and liquid phase compositions. It is used to find the equilibrium state of a mixture at a specified temperature.
| Name | Required | Description | Default |
|---|---|---|---|
| pressure | Yes | Pressure of the system | |
| components | Yes | List of components with their properties | |
| temperature | Yes | Temperature of the system |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It mentions constant-temperature equilibrium and vapor/liquid compositions, but it omits important behavioral traits such as the ideal vapor/ideal liquid assumption, the role of pressure as an input, and behavior when no two-phase equilibrium exists.
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 short and front-loaded with the core calculation outcome. The second sentence largely restates the first, adding limited new information, so there is mild redundancy but no major structural problem.
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?
Despite full schema coverage and an output schema, the description is thin for a thermodynamic flash calculation. It does not clarify how it differs from sibling bubble/dew calculations, does not state the ideal-model assumptions, and omits the pressure condition that is central to selecting and invoking this tool correctly.
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 components, temperature, and pressure. The description adds no parameter-level meaning beyond naming the specified temperature, so it earns the baseline score without exceeding it.
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 identifies a specific calculation type, Flash Isothermal, and states that it determines phase equilibrium and vapor/liquid compositions. It is clear about the resource being calculated, but it does not explicitly contrast itself with the sibling bubble/dew calculations, so it lacks explicit sibling differentiation.
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 says the tool is used to find the equilibrium state at a specified temperature, giving some usage context. However, it does not mention when to choose this over bubble or dew pressure/temperature calculations, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0calc_bubble_pressure_ideal_vapor_ideal_liquidcalc_bubble_temperature_ideal_vapor_ideal_liquidcalc_dew_pressure_ideal_vapor_ideal_liquidcalc_dew_temperature_ideal_vapor_ideal_liquidcalc_flash_isothermal_ideal_vapor_ideal_liquidScored across 5 tools
Each tool corresponds to a distinct, well-defined VLE calculation: bubble pressure, dew pressure, bubble temperature, dew temperature, and isothermal flash. The descriptions clearly differentiate the independent variable and physical phenomenon, so there is no meaningful ambiguity between tools.
All tool names follow the exact same pattern: calc_<calculation_type>_ideal_vapor_ideal_liquid. This creates a highly predictable and systematic naming convention, despite the names being long.
Five tools is an appropriate, focused count for a specialized vapor-liquid equilibrium server. Each tool covers a core calculation type without redundant or unnecessary helpers.
The tool set covers the standard set of ideal VLE calculations: bubble point (pressure and temperature), dew point (pressure and temperature), and isothermal flash. Within the stated ideal vapor/ideal liquid scope, there are no obvious missing operations or dead ends.
Engineering calculation MCP server for oil and gas engineering applications.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
