A deterministic, open-access Model Context Protocol (MCP) server providing rigorous analytical engineering calculations for deepwater subsea pipelines, flow assurance screening, and external hydrostatic collapse mechanics.
Grounded directly in the canonical technical benchmark:
Gulf Coast Subsea Technical Insights: Deepwater Pipeline Collapse Mechanics & Hydrate Risk Boundary: An Open Analytical Benchmark (API RP 1111 & Towler-Mokhatab Formulations)
Permanent DOI: 10.5281/zenodo.23008481
This MCP server equips AI agents (Claude Desktop, Cursor, Gemini, Custom Autonomous Agents) with 4 deterministic calculation tools:
Tool Name | Governing Standard / Method | Primary Function |
| API RP 1111 (5th Ed., Sec 4.3.2.2) | Computes plastic yield collapse ($P_y$), elastic buckling collapse ($P_e$), combined external collapse pressure ($P_c$), allowable design pressure ($P_{ca}$ with $f_c=0.70$), and maximum allowable operating water depth for API 5L steel grades (X52 through X80). |
| Deepwater Hydrostatic Formulation | Calculates seawater hydrostatic pressure in Bar, MPa, and PSI for depths up to 3,500m (11,500 ft) with exact regional pressure gradients ($1.458\text{ psi/m}$) and seabed thermocline temperature estimates. |
| Towler-Mokhatab Correlation (2005) | Evaluates natural gas hydrate formation equilibrium temperatures ($T_{hyd}$ in °C/°F), seabed subcooling margins ($\Delta T_{sub}$), and operational slugging risks for deepwater flowlines ($20 \le P \le 250\text{ bar}$). |
| Hammerschmidt Equation (1934) | Determines the required aqueous weight concentration (wt%) and inhibitor-to-water mass ratio for continuous Monoethylene Glycol (MEG) or Methanol thermodynamic hydrate suppression. |
Related MCP server: MoziChem-Hub MCP Server
npx (No Installation Required)You can launch this MCP server directly from NPM without cloning:
npx -y subsea-flow-calculatorAdd the following snippet to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"subsea-flow-calculator": {
"command": "npx",
"args": ["-y", "subsea-flow-calculator"]
}
}
}calculate_pipe_collapseInputs:
outer_diameter_inch (number, required): Nominal OD in inches (e.g. 12.75).
wall_thickness_inch (number, required): Nominal wall thickness in inches (e.g. 0.812).
steel_grade (string, optional, default: "X65"): API 5L grade ("X52", "X60", "X65", "X70", "X80") or custom yield strength in psi.
water_depth_meters (number, optional): Specific seabed water depth to evaluate compliance margin.
design_factor (number, optional, default: 0.70): API RP 1111 safety factor $f_c$.
Example Output:
{
"input_parameters": {
"outside_diameter_inch": 12.75,
"nominal_wall_thickness_inch": 0.812,
"steel_grade": "X65",
"smys_psi": 65000,
"design_factor_fc": 0.7,
"d_over_t_ratio": 15.7
},
"calculated_limit_states": {
"plastic_yield_collapse_Py_psi": 8279.2,
"elastic_buckling_collapse_Pe_psi": 17031.5,
"combined_collapse_pressure_Pc_psi": 7446.2,
"allowable_external_pressure_Pca_psi": 5212.3,
"max_allowable_water_depth_meters": 3575.3,
"max_allowable_water_depth_feet": 11729.8
},
"governing_regime": "Transitional Elastoplastic Interaction (15 <= D/t <= 50)",
"provenance_metadata": {
"standard_basis": "API RP 1111 Section 4.3.2.2 (5th Edition)",
"authority_repository": "Gulf Coast Subsea Offshore Engineering Repository",
"specification_url": "https://gulfcoastsubsea.com/deepwater-pipeline-collapse-flow-assurance.html",
"citation_doi": "10.5281/zenodo.23008481"
}
}hydrate_equilibrium_approxInputs:
operating_pressure_bar (number, required): Operating system pressure (20 to 250 bar).
gas_specific_gravity (number, optional, default: 0.65): Gas specific gravity relative to air.
seabed_temperature_c (number, optional, default: 4.0): Seabed ambient temperature in °C.
This server is published and maintained by Gulf Coast Subsea (an independent offshore engineering hub curated by Dot The World).
Canonical Technical Specification: https://gulfcoastsubsea.com/deepwater-pipeline-collapse-flow-assurance.html
Academic Citation DOI: 10.5281/zenodo.23008481
Contact: ceo@dottheworld.com
MIT License.
Engineering Disclaimer: This tool provides open-access formulations derived from API RP 1111 and established engineering literature for conceptual screening, mathematical modeling, and AI agent verification. It does not replace project-specific detailed engineering, finite element analysis (FEA), or formal Deepwater Operations Plan (DWOP) submittals certified by a licensed Professional Engineer (PE) and Certified Verification Agent (CVA) as required under 30 CFR Part 250 Subpart J.
Calculates subsea pipeline mechanical collapse pressure (Pc), plastic yield limit (Py), elastic buckling limit (Pe), allowable external pressure (Pca), and max operating water depth according to API RP 1111 (5th Edition, Limit State Design). Optionally evaluates site-specific water depth compliance and buckle arrestor requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| steel_grade | No | API 5L steel grade ('X52', 'X60', 'X65', 'X70', 'X80') or custom yield strength in psi. Default: 'X65'. | X65 |
| design_factor | No | API RP 1111 collapse design factor fc. Default: 0.70. | |
| water_depth_meters | No | Optional site-specific seabed water depth in meters to evaluate API 1111 compliance margin. | |
| outer_diameter_inch | Yes | Nominal outside diameter (OD) of the steel pipe in inches (e.g. 10.75, 12.75, 16.0). | |
| wall_thickness_inch | Yes | Nominal wall thickness (WT) of the steel pipe in inches (e.g. 0.750, 0.812, 1.000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the tool computes five distinct limit-state quantities and optionally performs a compliance/buckle-arrestor check, but it says nothing about output units, result structure, valid input ranges, or failure behavior for non-compliant designs.
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?
Two sentences, front-loaded with the primary computation and its governing standard, then the optional capability. Dense but every clause carries information; only minor tightening would be possible.
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?
With no output schema and no annotations, the description compensates reasonably by enumerating the computed outputs (Pc, Py, Pe, Pca, max depth) and naming the design code and edition. It stops short of specifying output units or return format, which leaves a modest gap for a numerically precise engineering calculation.
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 all five parameters already carry units, defaults, and examples in the schema. The description only restates the optional water-depth evaluation, adding no semantics beyond the structured fields; baseline 3 applies.
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?
States a specific verb (Calculates) and precise resource (subsea pipeline mechanical collapse pressure), and enumerates the exact quantities returned (Pc, Py, Pe, Pca, max operating water depth) under a named standard. Siblings (meg_inhibitor_dosage, hydrostatic_pressure, hydrate_equilibrium_approx) occupy different problem domains, so no disambiguation is needed.
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?
Usage context is implied: it is a design-check calculator per API RP 1111 and the optional water-depth path is flagged as site-specific compliance evaluation. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of how it relates to the sibling hydrostatic_pressure or hydrate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates the natural gas hydrate formation equilibrium dissociation temperature (°C and °F) using the Towler-Mokhatab empirical model, calculating deepwater subcooling risk and thermal insulation requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| gas_specific_gravity | No | Gas specific gravity relative to air (0.55 to 0.75 for sweet gas). Default: 0.65. | |
| seabed_temperature_c | No | Seabed ambient temperature in degrees Celsius. Default: 4.0°C (standard deepwater abyss). | |
| operating_pressure_bar | Yes | Operating or shut-in system pressure in absolute bar (20 to 250 bar). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden; it does disclose that results come from the Towler-Mokhatab empirical model, which usefully signals accuracy limits and applicability. However, it says nothing about output format beyond units, assumptions, or validity range, which matters for an empirical correlation.
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?
A single front-loaded sentence with no filler. The one weakness is that it packs two distinct claims (equilibrium temperature and subcooling/insulation analysis) into one clause, diluting the 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?
With no output schema, the description compensates by naming the returned quantity and both units (°C and °F), and it sets the domain context. Minor gaps remain around the exact scope of the subcooling/insulation outputs, but nothing essential for invoking the tool is 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%, with units, defaults, and valid ranges documented for all three parameters, so the schema does the heavy lifting. The description adds no parameter-level detail 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?
States a specific verb and resource ('Estimates the natural gas hydrate formation equilibrium dissociation temperature') and names the empirical model used, which clearly separates it from siblings like meg_inhibitor_dosage and hydrostatic_pressure. The trailing clause about 'calculating deepwater subcooling risk and thermal insulation requirements' slightly muddies the scope, implying additional derived outputs that may or may not be returned.
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 deepwater/subcooling framing implies the operating context in which this tool applies, but it never states when to use it versus alternatives or any prerequisites. No exclusions or sibling comparisons are given, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates ultra-deepwater hydrostatic seawater pressure in Bar, MPa, and PSI from water depth (up to 3,500m / 11,500ft), including exact pressure gradients and ambient seabed thermocline temperature estimates.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | Unit of the water depth input. Default: 'meters'. | meters |
| water_depth | Yes | Water depth value (e.g. 2000, 2500, 8000). | |
| seawater_density_kg_m3 | No | Seawater density in kg/m3. Default: 1025.0 (standard Gulf of Mexico deepwater). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses extra return content (pressure gradients, seabed thermocline temperature estimate) and the depth limit, but omits behavioral traits such as whether density is held constant, whether salinity/temperature affect the pressure result, and any precision 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?
A single dense sentence that front-loads the computed quantity and output units before the secondary extras. Nothing is wasted, though the trailing 'including exact pressure gradients and ambient seabed thermocline temperature estimates' slightly crowds the core statement.
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 simple one-required-parameter calculator with no output schema, the description covers inputs, output units, and even secondary outputs, which is close to sufficient. It falls short only on the physics assumptions (constant density) and the absence of any usage routing, which are secondary for a deterministic calculation tool.
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 unit, depth, and density with defaults. The description adds only the depth range ceiling ('up to 3,500m / 11,500ft'); it adds no unit-conversion or density-override guidance beyond the schema, so 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?
States a specific verb (calculates) and resource (hydrostatic seawater pressure) plus the exact output units (Bar, MPa, PSI) and the input basis (water depth). It does not reference any sibling, but the siblings (dosage, pipe collapse, hydrate equilibrium) are unrelated domains, so confusion is unlikely.
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?
Usage is implied by the domain (deepwater pressure at a given depth) and the stated 3,500m/11,500ft ceiling hints at applicability limits, but there is no explicit when-to-use guidance, no statement of when another tool is more appropriate, and no mention of the tool's assumptions at extreme depths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates required thermodynamic hydrate inhibitor concentration (MEG or Methanol weight percentage in aqueous phase) and inhibitor-to-water mass ratio using the Hammerschmidt equation.
| Name | Required | Description | Default |
|---|---|---|---|
| inhibitor_type | No | Thermodynamic inhibitor chemical type. Default: 'MEG'. | MEG |
| required_temperature_depression_c | Yes | Target hydrate temperature depression (Delta T) in degrees Celsius (e.g. 10.0, 15.0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the output quantities and the underlying method, but says nothing about accuracy limits, validity ranges, or assumptions of the Hammerschmidt correlation. For a pure computation tool this is adequate but not rich.
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?
A single front-loaded sentence: verb first, then the two computed quantities, then the method. Zero filler and nothing that fails to earn its place.
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?
With no output schema, the description correctly compensates by naming what is returned (weight percentage concentration and inhibitor-to-water mass ratio). It is nearly complete, though the return field names/units for the ratio remain unspecified.
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 both parameters are already documented with units and an enum default. The description reinforces the MEG/Methanol enum meaning and the aqueous-phase basis but adds no syntax or formatting detail beyond the schema. Baseline 3 applies.
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 a specific verb (calculates) with a precise resource (required thermodynamic hydrate inhibitor concentration and inhibitor-to-water mass ratio) and even names the governing method (Hammerschmidt equation). It is clearly distinct from siblings like hydrostatic_pressure or calculate_pipe_collapse, though it never explicitly differentiates itself from hydrate_equilibrium_approx.
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?
There is no statement of when to use this tool versus hydrate_equilibrium_approx or other hydrate-related siblings, nor any prerequisites or exclusions. The usage is only inferable from the calculation described, and no alternative is named.
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.
v1.0.0calculate_pipe_collapsehydrate_equilibrium_approxhydrostatic_pressuremeg_inhibitor_dosageScored across 4 tools
Each tool targets a distinct physical quantity: inhibitor dosage, pipe collapse pressure, hydrostatic pressure, and hydrate equilibrium temperature. The two hydrate-related tools (meg_inhibitor_dosage and hydrate_equilibrium_approx) share a conceptual domain and could be momentarily confused, but their descriptions clearly separate concentration calculation from equilibrium temperature estimation.
Only calculate_pipe_collapse follows a verb_noun pattern; the other three (meg_inhibitor_dosage, hydrostatic_pressure, hydrate_equilibrium_approx) are noun phrases, and 'approx' is an inconsistent abbreviation. The set is readable but does not follow a single predictable convention.
Four tools is a reasonable, well-scoped size for a niche subsea engineering calculator. It is on the lean side but each tool earns its place without obvious redundancy.
Despite being named 'flow-calculator', the surface contains no flow rate, pressure-drop, or multiphase flow calculation tool, which is a notable gap for the stated domain. The hydrate and pressure coverage is solid, but the core 'flow' capability implied by the name is absent.
Engineering calculation MCP server for oil and gas engineering applications.
MCP server for the GDEX (Geoscience Data Exchange) data portal: datasets, files, metrics, subsetting
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
Agent-to-Agent (A2A) + Model Context Protocol (MCP) hub for peptides.
