A deterministic, open-access Model Context Protocol (MCP) server providing regulatory classification, protraction area intelligence, and capital expenditure heuristics for the deepwater U.S. Gulf of Mexico Outer Continental Shelf (OCS).
Grounded directly in the canonical technical whitepaper:
Gulf Coast Subsea Technical Insights: Deepwater Gulf of Mexico Subsea Overview: 20K PSI Architecture, SURF Tie-Backs, and Field Economics (2026–2030)
Permanent Academic DOI: 10.5281/zenodo.23008481
Tool Name | Governing Standard / Basis | Primary Function |
| BSEE NTL 2019-G03 / API 17TR8 | Evaluates shut-in tubing pressure (SITP) and bottomhole temperature to determine whether a project triggers BSEE 20,000 PSI Tier-1 regulations, mandatory Independent Third-Party (I3P) verification, and Certified Verification Agent (CVA) approvals. |
| BOEM Outer Continental Shelf (OCS) | Looks up deepwater protraction areas (MC, GC, WR, KC, AC, VK, AT), returning bathymetric depth envelopes, Paleogene Wilcox/Miocene geological trends, and regional host platform infrastructure. |
| GCS 2026-2030 Benchmark Model | Models subsea tieback capital expenditures (CAPEX), flow assurance distance flags (>20 miles), and breakeven oil price comparisons ($25-$35/bbl vs $55-$65/bbl for standalone FPUs). |
Related MCP server: opendtect-mcp
npx (No Installation Required)npx -y gom-deepwater-radarAdd 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": {
"gom-deepwater-radar": {
"command": "npx",
"args": ["-y", "gom-deepwater-radar"]
}
}
}bsee_hpht_regulatory_classifierQuery: shut_in_tubing_pressure_psi: 19500, bottomhole_temp_f: 275
Output Payload:
{
"bsee_classification": {
"regime_title": "Extreme HPHT 20,000 PSI Tier-1 Subsea System",
"is_hpht_threshold_exceeded": true,
"is_20k_tier1": true
},
"regulatory_compliance_mandates": {
"dwop_filing_requirements": "Full BSEE NTL No. 2019-G03 & API Technical Report 17TR8 (2nd Ed) compliance mandatory. Formal Independent Third-Party (I3P) and Certified Verification Agent (CVA) verification required before DWOP approval.",
"metallurgy_and_barrier_standard": "Precipitation-hardened Nickel-based Superalloys (UNS N07718 / Alloy 718, UNS N06625 / Alloy 625) required for all pressure-containing components and subsea tree gate valves."
},
"provenance_metadata": {
"authority_repository": "Gulf Coast Subsea Deepwater Intelligence Unit",
"specification_url": "https://gulfcoastsubsea.com/20k-subsea-tiebacks.html",
"citation_doi": "10.5281/zenodo.23008481"
}
}This server is published and maintained by Gulf Coast Subsea (an independent offshore engineering hub curated by Dot The World).
Canonical Technical Whitepaper: https://gulfcoastsubsea.com/20k-subsea-tiebacks.html
Academic Citation DOI: 10.5281/zenodo.23008481
Contact: ceo@dottheworld.com
MIT License.
Regulatory Disclaimer: This tool provides regulatory screening derived from public BSEE and BOEM guidance documents for conceptual evaluation and AI agent verification. Formal Deepwater Operations Plan (DWOP) submittals and offshore facility permits strictly require filing through registered offshore operators and review by licensed Professional Engineers (PE).
Classifies Gulf of Mexico deepwater wells under BSEE NTL 2019-G03 and API 17TR8 guidelines, determining whether 20,000 PSI Tier-1 regulations, Independent Third-Party (I3P) verification, and Certified Verification Agent (CVA) approvals are legally triggered.
| Name | Required | Description | Default |
|---|---|---|---|
| water_depth_ft | No | Water depth in feet. Default: 6000.0 ft. | |
| bottomhole_temperature_f | No | Bottomhole temperature in degrees Fahrenheit. Default: 250.0°F. | |
| shut_in_tubing_pressure_psi | Yes | Shut-in tubing pressure (SITP) in PSI (e.g. 12000, 16500, 19500). |
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 discloses the regulatory framework and the nature of the determination, which is useful context, but it does not state whether the tool is read-only, deterministic, whether it requires authoritative inputs, or whether there are side effects or rate limits.
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, information-dense sentence with no wasted words. It is front-loaded with the core verb and scoped resource, and every clause contributes to purpose or regulatory trigger detail.
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 regulatory complexity, the absence of an output schema, and no annotations, the description is only partially complete. It indicates the determination outcomes but omits return format, usage conditions, and behavioral constraints, leaving some gaps for an agent to infer.
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 three parameters are already documented in the input schema. The description does not add parameter-specific syntax, constraints, or examples beyond what the schema provides, making 3 the appropriate baseline for high schema coverage.
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 ('Classifies'), resource ('Gulf of Mexico deepwater wells'), regulatory standards, and the exact regulatory triggers it determines. It is not a tautology and is very clear, but it does not explicitly distinguish itself from sibling tools such as lookup_gom_protraction_area or estimate_tieback_economics.
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 explains what the tool determines but gives no when-to-use guidance, no prerequisites, no exclusions, and no mention of alternatives. Usage must be inferred from the regulatory context rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluates subsea tieback capital expenditures (CAPEX), breakeven oil prices ($25-$35/bbl), and flow assurance distance thresholds versus standalone greenfield floating production units (FPUs).
| Name | Required | Description | Default |
|---|---|---|---|
| host_type | No | Type of host facility ('semi_submersible', 'spar', 'tlp'). Default: 'semi_submersible'. | semi_submersible |
| water_depth_ft | No | Water depth in feet. Default: 5000.0 ft. | |
| production_rate_bpd | No | Anticipated oil production rate in barrels per day. Default: 25000.0 bpd. | |
| tieback_distance_miles | Yes | Distance from subsea wellhead to host platform in miles (e.g. 10.0, 25.0). |
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 does disclose the analytical basis (CAPEX, breakeven range $25-$35/bbl, flow-assurance distance thresholds vs. FPUs), which tells the agent what the model reasons over. However it says nothing about whether this is a deterministic calculation, what assumptions/limits apply, or what the response contains — significant gaps for a model-driven estimator.
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 evaluated outputs and closes with the comparison baseline. No filler, no repetition of the tool name or schema.
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 usefully enumerates the outputs (CAPEX, breakeven oil price, distance thresholds), which covers what an agent should expect back. It is thin on assumptions and validity limits, but for a four-parameter computational estimator this is close to 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 the schema already documents all four parameters including defaults and units. The description adds only indirect meaning (the flow-assurance distance concept behind tieback_distance_miles) and does not mention host_type, water_depth_ft, or production_rate_bpd. 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?
Specific verb ('Evaluates') plus a precise resource domain ('subsea tieback capital expenditures, breakeven oil prices, flow assurance distance thresholds'). The comparison against standalone greenfield FPUs further narrows what this tool is, and it is unmistakably distinct from the sibling regulatory-classifier and protraction-lookup tools.
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 frames the tool as a comparison versus greenfield FPUs, which implies an evaluation context, but it never states when to call this versus the sibling tools or what inputs make it appropriate. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up BOEM Outer Continental Shelf (OCS) deepwater protraction areas in the Gulf of Mexico (MC, GC, WR, KC, AC, VK, AT), returning water depths, geological Wilcox/Miocene trends, and flagship host platform hubs.
| Name | Required | Description | Default |
|---|---|---|---|
| area_code | Yes | Two-letter protraction area code (e.g. 'MC' for Mississippi Canyon, 'WR' for Walker Ridge, 'GC' for Green Canyon). |
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 helpfully discloses the return contents (water depths, Wilcox/Miocene trends, host platform hubs), which implies a read-only lookup, but it says nothing about auth requirements, coverage limits, or failure modes for invalid area codes.
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?
One dense, front-loaded sentence with no filler. Slightly overloaded with parenthetical enumerations, but every clause is informative.
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 single-parameter lookup with no output schema, the description adequately conveys both the scope and the nature of the returned data. Only minor gaps remain (validation behavior for unknown codes, data freshness).
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 single 'area_code' parameter is already fully documented with examples in the schema. The description's enumeration of area codes adds little beyond what the schema provides; 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 ('Looks up') and a precise resource (BOEM OCS deepwater protraction areas in the Gulf of Mexico), enumerating the covered area codes. This clearly distinguishes it from the sibling tools, which concern regulatory classification and tieback economics.
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 explains what the tool returns but never says when to use it versus the siblings, nor any prerequisites or exclusions. Usage is only implied by the subject matter.
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.0bsee_hpht_regulatory_classifierestimate_tieback_economicslookup_gom_protraction_areaScored across 3 tools
Each tool serves a clearly distinct purpose: regulatory classification, protraction-area lookup, and tieback economics. There is no overlap in the resource or action being targeted, so an agent can easily select the right tool.
All names use snake_case and are descriptive, but the first tool lacks an action verb and instead leads with an agency/acronym, while the other two follow a verb-noun pattern. The inconsistency is minor and does not impair readability.
Three tools are well-scoped for a focused deepwater analysis server, and each tool covers a distinct analytical dimension. The count is small but not trivially thin, given the specificity of the domain.
The surface covers regulatory classification, geological area lookup, and tieback economics, but it lacks direct well, platform, pipeline, or production-data access that a 'deepwater radar' user might reasonably expect. These gaps are notable though workable for the three supported workflows.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
Built-environment forecasts, public benchmarks, and permit or zoning readiness through remote MCP.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Infrastructure and hazard intelligence with provenance, spatial confidence and quality contracts.
