This server exposes PyMemSim membrane simulation capabilities through MCP, letting AI agents run physics-based gas hollow-fiber membrane simulations with structured thermodynamic model sources.
Run gas hollow-fiber membrane simulations via simulate_gas_hfm, including feed/permeate conditions, gas components, flow patterns, heat transfer options, module geometry, and optional solver/thermo settings.
Validate PyThermoDB YAML reference content with check_yaml_reference to ensure thermodynamic data is correctly formatted before simulation.
Analyze recommended feed flow rate bounds for hollow-fiber modules with hfm_feed_flow_rate_analyzer, using geometry, operating conditions, permeance, viscosity, and pressure-drop limits.
Serve over STDIO or HTTP for use by MCP-compatible desktop and agent clients.
Support agentic workflows where LLM agents build model sources from reference data and execute simulations, sensitivity analysis, and optimization.
Decouple data, equations, and solvers by using external YAML model sources, enabling reproducible, unit-safe thermodynamic definitions in membrane separation modeling.
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., "@PyMemSim-MCP simulate CO2/N2 separation in hollow fiber membrane with feed 20% CO2 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.
PyMemSim-MCP exposes PyMemSim membrane simulation capabilities through an MCP server.
PyMemSim-MCP is a next-generation framework that brings the Model Context Protocol into chemical engineering modeling and simulation, specifically for membrane-based separation systems.
Built on top of PyMemSim, this package introduces a model-source-driven architecture in which thermodynamic data, transport properties, and governing equations are defined externally in a structured, machine-readable format (e.g., YAML). These model sources are dynamically constructed using tools such as PyThermoLinkDB and PyThermoDB, and then supplied, alongside conventional inputs like temperature, pressure, and composition, to simulation workflows.
Unlike traditional tightly coupled simulation tools, PyMemSim-MCP decouples data, equations, and numerical solvers, enabling:
✅ Consistent and unit-safe thermodynamic definitions across simulations
🔗 Flexible integration with multiple modeling packages and workflows
⚙️ Solver-agnostic execution of mass and heat balance equations
🔍 Transparent and interpretable simulation pipelines
A key innovation of PyMemSim-MCP is its compatibility with agentic workflows, where specialized agents can:
🧠 Extract and structure thermodynamic data from unstructured sources into validated model sources
🤖 Interact with MCP-enabled endpoints to perform simulations, sensitivity analysis, and optimization
This approach addresses critical gaps in current LLM-integrated engineering tools, where inconsistencies in data formats, units, and equations often lead to unreliable results. By enforcing a unified scientific contract, PyMemSim-MCP allows LLMs to control both conventional inputs and structured model sources before executing physics-based computations, significantly improving robustness and reproducibility.
PyMemSim-MCP is particularly suited for:
🧪 Membrane process modeling (e.g., hollow fiber modules, gas separation)
🤝 AI-assisted simulation workflows
🚀 Rapid prototyping and validation of process models
🎓 Educational and research applications in computational chemical engineering
Overall, PyMemSim-MCP represents a step toward trustworthy AI-driven simulation environments, where domain knowledge, data, and numerical methods are seamlessly integrated under a standardized and extensible framework.
Related MCP server: AspenPlus MCP Server
Python >=3.11
pip (or uv)
pip install pymemsim-mcpThis installs the CLI entrypoint:
pymemsim-mcp
The server entrypoint is:
module: python -m pymemsim_mcp.server
script: pymemsim-mcp
Both support the same options.
pymemsim-mcp --mode stdioEquivalent:
python -m pymemsim_mcp.server --mode stdiopymemsim-mcp --mode http --host 127.0.0.1 --port 8000 --path /mcpEquivalent:
python -m pymemsim_mcp.server --mode http --host 127.0.0.1 --port 8000 --path /mcp--mode: stdio or http (default: stdio)
--host: HTTP bind host (default: 127.0.0.1)
--port: HTTP bind port (default: 8000)
--path: HTTP endpoint path (default: /mcp)
{
"mcpServers": {
"pymemsim": {
"command": "pymemsim-mcp",
"args": ["--mode", "stdio"]
}
}
}{
"mcpServers": {
"pymemsim": {
"url": "http://127.0.0.1:8000/mcp"
}
}
}simulate_gas_hfm: build thermo model source from reference content and run gas hollow-fiber membrane simulation.
For AI-assisted and agentic membrane-process simulation, see PyMemSim-Agent.
PyMemSim-Agent provides a harness-neutral instruction and workflow layer designed to orchestrate PyMemSim-MCP through AI agents such as Codex, Claude, Gemini, and other agentic environments.
While PyMemSim-MCP exposes the scientific simulation capabilities through the Model Context Protocol (MCP), PyMemSim-Agent provides the reasoning rules, skills, prompts, examples, and workflows needed for an agent to use those capabilities systematically.
Together, they enable agentic workflows in which an AI agent can:
🧠 Interpret a membrane-separation problem and identify the required simulation inputs
📚 Build structured thermodynamic model sources from reference data
✅ Validate required properties, units, equations, and simulation inputs
🔧 Select and invoke the appropriate PyMemSim-MCP tools
⚙️ Execute physics-based membrane simulations
📊 Interpret simulation outputs and engineering performance indicators
🔁 Perform iterative studies such as sensitivity analysis, operating-condition exploration, and optimization
🧪 Maintain a reproducible workflow connecting scientific references, model inputs, numerical simulation, and engineering interpretation
The overall architecture can therefore be viewed as:
User / Engineering Problem
│
▼
Agentic Harness
(Codex / Claude / Gemini / ...)
│
▼
PyMemSim-Agent
Instructions • Skills
Prompts • Workflows
│
▼
PyMemSim-MCP
MCP Tools
│
▼
PyMemSim
Physics-Based Simulation
│
▼
Engineering Results👉 PyMemSim-Agent repository: https://github.com/sinagilassi/PyMemSim-Agent
python -m py_compile pymemsim_mcp/server.py
python -m py_compile pymemsim_mcp/interface/gas_hfm.pypymemsim-mcp: command not found
Run pip install -e . in the active environment.
Confirm environment is activated.
Port already in use (HTTP mode)
Change port, for example: --port 8010.
Import errors
Reinstall dependencies: pip install -e ..
For any questions, contact me on LinkedIn.
This project is licensed under the Apache License 2.0. See the LICENSE file for details.
Validate pythermodb YAML reference content for use with pyThermoDB.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml_content | Yes | The YAML content to be checked as a reference. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. The term 'validate' implies a non-destructive check, but it fails to state whether the tool modifies state, requires special permissions, or what side effects (if any) occur. The description is insufficiently transparent.
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 sentence with no wasted words. It efficiently conveys the core action and target resource, earning its place without redundancy.
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 simple tool signature (one parameter) and the existence of an output schema (which likely describes the validation result), the description is minimally adequate. However, it does not explain what the output represents (e.g., success, errors) or how validation failures are communicated, leaving some ambiguity.
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 the parameter is fully described in the schema. The description adds no additional meaning beyond the schema; it merely restates the tool's purpose. Per the rubric, baseline 3 applies when schema coverage is high, and the description does not contribute further.
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 uses the specific verb 'validate' and identifies the resource as 'pythermodb YAML reference content'. It clearly distinguishes this tool from its sibling calculation tools (all calc_*), making the purpose unmistakable.
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 its siblings or any alternatives. It does not state that validation should precede calculations or specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze recommended feed flow rate bounds for a hollow-fiber membrane module from geometry, operating conditions, and permeance inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| permeance | Yes | A dictionary containing the permeance values for each component in the feed stream. | |
| theta_max | No | The maximum allowable packing density of the fibers (default is 0.8). | |
| viscosity | Yes | The viscosity of the feed stream. | |
| fiber_length | Yes | The length of the fibers. | |
| velocity_max | No | The maximum velocity to consider for the analysis (default is 10.0 m/s). | |
| velocity_min | No | The minimum velocity to consider for the analysis (default is 0.01 m/s). | |
| feed_pressure | Yes | The pressure of the feed stream. | |
| feed_temperature | Yes | The temperature of the feed stream. | |
| number_of_fibers | Yes | The number of fibers in the HFM system. | |
| max_pressure_drop | No | The maximum allowable pressure drop across the fibers (default is 20,000 Pa). | |
| permeate_pressure | Yes | The pressure of the permeate stream. | |
| feed_mole_fraction | Yes | A dictionary containing the mole fraction values for each component in the feed stream. | |
| fiber_inner_diameter | Yes | The inner diameter of the fibers. | |
| fiber_outer_diameter | Yes | The outer diameter of the fibers. |
| 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 full disclosure burden. However, it does not mention whether the tool is read-only, has side effects, rate limits, or any other behavioral traits beyond computing bounds. The description is too vague to inform the agent about potential impacts.
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, front-loaded sentence with no redundancy. Every word contributes to the purpose. It is appropriately sized and efficiently 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?
Given the complexity (14 parameters, nested objects, output schema exists), the description is minimal but adequate. It summarizes inputs but lacks detail on output nature or edge cases. However, since an output schema is present, it partially compensates. Overall, it is just sufficient.
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 baseline is 3. The description adds no additional meaning beyond categorizing inputs (geometry, operating conditions, permeance). It does not explain parameter relationships, units, or constraints beyond what the schema already provides.
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: analyzing recommended feed flow rate bounds for a hollow-fiber membrane module using geometry, operating conditions, and permeance inputs. It distinguishes from siblings 'check_yaml_reference' and 'simulate_gas_hfm' by specifying a unique output (feed flow rate bounds) and inputs.
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, or any prerequisites. It simply states what the tool does without contextual advice or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run a gas hollow-fiber membrane simulation, using pyThermoDB YAML reference content to build the model source.
| Name | Required | Description | Default |
|---|---|---|---|
| request | 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 the full burden of behavioral disclosure. It only states 'run a simulation' without explaining what the simulation does (e.g., steady-state, transient), what inputs are required beyond the YAML, or any side effects. This is insufficient for a complex tool.
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 sentence, which is concise, but it is under-specified and lacks structure. It does not provide enough information to be useful, so conciseness does not compensate for missing content.
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 (many parameters, no annotations, output schema exists), the description is far too minimal. It fails to cover essential aspects like simulation behavior, parameter roles, or how to structure inputs. The description is completely inadequate.
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% according to context, meaning no parameter descriptions in the schema. The description adds no parameter information at all, only mentioning 'using pyThermoDB YAML reference content'. This leaves the many parameters completely unexplained.
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 runs a gas hollow-fiber membrane simulation and mentions using pyThermoDB YAML reference content. However, it does not distinguish itself from sibling tools like check_yaml_reference or hfm_feed_flow_rate_analyzer, lacking 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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as having a valid YAML reference. This omission makes it hard for an agent to decide when to invoke this tool.
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.1check_yaml_referencehfm_feed_flow_rate_analyzersimulate_gas_hfmScored across 3 tools
Each tool targets a clearly distinct operation: validating YAML content, analyzing feed flow rate bounds, and running a membrane simulation. There is no overlap in functionality.
Tool names use snake_case but mix verb-noun patterns: 'check_yaml_reference' and 'simulate_gas_hfm' start with verbs, while 'hfm_feed_flow_rate_analyzer' is a noun phrase without a verb, creating inconsistency.
With only 3 tools, the server is tightly scoped to core membrane simulation tasks. Each tool serves a necessary, non-redundant purpose.
The set covers validation, analysis, and simulation, but lacks tools for user input setup, result visualization, or parameter tuning, leaving notable gaps for a complete workflow.
Engineering calculation MCP server for oil and gas engineering applications.
MCP server exposing the Backtest360 engine API as tools for AI agents.
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
