Provides deterministic engineering calculations and validation for NVIDIA GB200 NVL72 high-density liquid-cooled AI racks, including coolant flow requirements, heat removal capacity, pipe friction loss, ASHRAE liquid cooling class, and related commissioning audit checks.
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., "@Data Center Auditor MCP Server Calculate coolant flow and ASHRAE class for a 132 kW GB200 rack at 12 K delta T."
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 deterministic Model Context Protocol (MCP) server for mission-critical AI data centers, high-density direct-to-chip liquid cooling (NVIDIA GB200 NVL72), and Level 1â5 commissioning TDD protocols.
Powered by the first-principles engineering protocols from Data Center Field Guides.
This MCP server equips AI agents with 6 deterministic engineering calculation and validation tools:
Tool | Category | Description | Governing Standard |
| Thermal / Fluid | Calculates required liquid coolant flow rate ($L/min$, $GPM$), mass balance, heat removal capacity, and ASHRAE liquid cooling class ($W1$â$W4$) for 132 kW NVL72 racks. | ASHRAE TC 9.9 / NVIDIA GB200 NVL72 |
| Fluid Hydraulics | Calculates Darcy-Weisbach pressure drop ($\Delta P$), pipe fluid velocity, Reynolds number ($Re$), and erosion risk thresholds ($<0.5\text{ m/s}$ settling, $>2.0\text{ m/s}$ erosion) across DN25âDN100 pipes. | Darcy-Weisbach / Swamee-Jain / ASME B31.3 |
| TDD Commissioning | Audits MOP, SOP, EOP, and IST Level 1â5 commissioning scripts against physical boundaries, Point of No Return (PONR) rules, and safety gates. | ASHRAE Guideline 0 / NFPA 70E / Uptime |
| Environmental | Classifies whitespace atmospheric corrosion severity for Copper and Silver reactivity rates according to ANSI/ISA-71.04-2013 ($G1$, $G2$, $G3$, $GX$). | ANSI/ISA-71.04-2013 / RoHS |
| Ground-Truth Search | Full-text keyword and protocol search across the 69-protocol Data Center Field Guides ground truth corpus. | DCFG Field Handbook |
| Audit Codes | Fast lookup for fatal commissioning flaws and defect codes (e.g. | DCFG Defect Taxonomy |
Related MCP server: Corrosion Engineering MCP Server
To automatically install for Claude Desktop:
npx -y @smithery/cli install @geese1028/datacenter-mcp --client claudeTo automatically install for Cursor:
npx -y @smithery/cli install @geese1028/datacenter-mcp --client cursorAdd the following to your claude_desktop_config.json (on macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"datacenter-auditor": {
"command": "node",
"args": ["/PATH/TO/datacenter-mcp/index.js"]
}
}
}Create or edit .cursor/mcp.json in your project root:
{
"mcpServers": {
"datacenter-auditor": {
"command": "node",
"args": ["/PATH/TO/datacenter-mcp/index.js"]
}
}
}$$\dot{Q} = \dot{m} \cdot c_p \cdot \Delta T$$ Where $\dot{Q}$ is rack heat dissipation ($132\text{ kW}$ for NVL72), $\dot{m}$ is coolant mass flow, $c_p$ is fluid specific heat ($3.96\text{ kJ/kg}\cdot\text{K}$ for PG25), and $\Delta T$ is cold plate temperature delta ($10\text{ K}$â$15\text{ K}$).
$$\Delta P = f \cdot \frac{L}{D} \cdot \frac{\rho v^2}{2}$$ Friction factor $f$ calculated via the Swamee-Jain explicit approximation of the Colebrook-White equation for turbulent pipe flow ($Re \ge 2,300$): $$f = \frac{0.25}{\left[\log_{10}\left(\frac{\varepsilon}{3.7D} + \frac{5.74}{Re^{0.9}}\right)\right]^2}$$
Evaluation according to ANSI/ISA-71.04-2013 Table 1 for 30-day passive coupon exposure:
Level G1 (Mild): $\text{Cu} < 300\text{ \AA/30d}$, $\text{Ag} < 200\text{ \AA/30d}$ (Mandatory for RoHS compliance).
Level G2 (Moderate): $\text{Cu} < 1000\text{ \AA/30d}$, $\text{Ag} < 1000\text{ \AA/30d}$.
Level G3 (Harsh): $\text{Cu} < 2000\text{ \AA/30d}$, $\text{Ag} < 2000\text{ \AA/30d}$.
Level GX (Severe): $\text{Cu} \ge 2000\text{ \AA/30d}$, $\text{Ag} \ge 2000\text{ \AA/30d}$.
Official Specs: https://datacenterfieldguides.com
Full Protocol Index: https://datacenterfieldguides.com/llms.txt
Unredacted Engineering Protocols: https://datacenterfieldguides.com/llms-full.txt
MIT Š Tristan (Data Center Field Guides)
Audits a data center commissioning script (MOP, SOP, EOP, or IST Level 1-5) against deterministic physical boundary rules and safety gates.
| Name | Required | Description | Default |
|---|---|---|---|
| script_text | Yes | The raw text of the MOP, SOP, EOP or commissioning script to audit | |
| commissioning_level | No | Commissioning level being executed (L1 Factory, L2 Quality/Receipt, L3 Component/PFT, L4 System/FPT, L5 Integrated IST) | ALL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It hints that the analysis is rule-based and deterministic ('deterministic physical boundary rules and safety gates'), which is useful, but it never states that the operation is read-only, what the findings/violations look like, whether it is idempotent, or how it handles unsupported or malformed input.
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 with the resource and the audit basis front-loaded and no filler. It is efficient, though the brevity comes at the cost of any usage or output guidance.
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 only two parameters, full schema coverage, and no output schema, the definition needs to describe what an audit returns (violations, gate failures, pass/fail summary) and it does not. For a low-complexity tool this is adequate but leaves a real gap about results and error behavior.
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, making 3 the baseline. The description adds only a gloss on the commissioning levels ('IST Level 1-5') that the enum already spells out, and gives no extra guidance on choosing between a specific level and 'ALL'.
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 a specific verb ('Audits') and a clearly bounded resource ('data center commissioning script'), and enumerates the document families it accepts (MOP, SOP, EOP, IST Level 1-5). It does not need to differentiate itself from siblings like verify_hydraulic_boundary or calculate_pipe_friction_loss, since none of them audit scripts, so a 4 is appropriate.
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 explicit when-to-use or when-not-to-use guidance, no stated prerequisites (e.g., that the script must be raw text of a single procedure), and no mention of alternatives. The named document types imply scope but leave an agent to infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates Darcy-Weisbach pipe friction pressure drop, flow velocity, Reynolds number, and erosion thresholds for data center liquid cooling loops.
| Name | Required | Description | Default |
|---|---|---|---|
| pipe_dn | Yes | Standard pipe nominal diameter | |
| flow_lpm | Yes | Volumetric flow rate in Liters/Minute (e.g. 162.5 LPM for NVL72 132kW) | |
| coolant_type | No | Coolant fluid type | pg25 |
| pipe_length_m | Yes | Total straight pipe length in meters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the computed outputs (pressure drop, velocity, Reynolds number, erosion thresholds), which implies a deterministic, side-effect-free calculation, but it never states that the call is read-only, nor does it disclose modeling assumptions such as coolant temperature, pipe roughness, or whether fittings/minor losses are included.
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 verb and computed quantities come first. It is arguably a little dense with four output quantities in one clause, but nothing is wasted.
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 deterministic four-parameter calculator with full schema coverage and no output schema, the description covers both the computation and the returned quantities, which is the main gap such tools usually have. The remaining shortfalls are assumption-related (fluid temperature, roughness, minor losses) rather than structural.
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% and both enums are documented with defaults, so the inputs are already well explained. The description adds no parameter-level meaning, not even the unit conventions or the meaning of the erosion threshold relative to the selected pipe DN.
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?
Names a specific computation (Darcy-Weisbach pipe friction pressure drop) plus the additional derived quantities (velocity, Reynolds number, erosion thresholds) and the domain (data center liquid cooling loops). The sibling tools are all audit/verify/search/classify/lookup operations, so no distinguishing sentence is needed, but the description does not explicitly signal that this is the only compute tool in the set.
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 only implied â an agent can infer this fits hydraulic sizing/verification work, and it plausibly pairs with verify_hydraulic_boundary, but that relationship is never stated. There is no when-to-use, when-not-to-use, or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classifies data center whitespace atmospheric corrosion severity according to ANSI/ISA-71.04-2013 for Copper and Silver reactivity.
| Name | Required | Description | Default |
|---|---|---|---|
| copper_angstroms_30d | Yes | Copper reactivity rate in Angstroms per 30 days (Ă /30 days) | |
| silver_angstroms_30d | Yes | Silver reactivity rate in Angstroms per 30 days (Ă /30 days) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden; it makes clear this is a standards-based classification over two reactivity readings, implying a stateless computation, but it never states determinism, side-effect freedom, or that no external state is touched. It also does not disclose what the classification output looks like (e.g., severity class labels), which matters since no output schema 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?
A single front-loaded sentence identifies the action, scope, and standard with no filler. Every clause contributes identifying information.
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 pure classification tool with fully documented inputs, the definition is nearly sufficient; the remaining gap is the absent note on what severity levels or return structure the caller receives, which is not covered by any output schema.
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 both parameters documented as Ă /30 days, so the schema already does the heavy lifting. The description reinforces the meaning by tying the two inputs to Copper and Silver reactivity under the ANSI standard, but adds no accepted ranges, units edge cases, or constraints beyond that.
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'), a specific resource ('data center whitespace atmospheric corrosion severity'), the governing standard (ANSI/ISA-71.04-2013), and the two measured species (Copper and Silver reactivity). None of the siblings overlap with corrosion classification, so the tool is unambiguously identifiable.
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 domain ('data center whitespace atmospheric corrosion') and standard imply when the tool applies, but there is no explicit when-to-use/when-not-to-use statement or routing to any alternative. An agent must infer applicability from the scope wording alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up fatal commissioning flaws and defect codes (e.g. A-01, B-02, C-03) from the Data Center Field Guides audit standard.
| Name | Required | Description | Default |
|---|---|---|---|
| defect_code | Yes | Defect code such as "A-01", "B-04", "CAT-A-01" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Looks up' reasonably conveys a non-mutating reference read and the examples hint at accepted code formats, but the description says nothing about behavior on an unknown or malformed code, case sensitivity of the prefixes, or what a hit actually returns.
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 identifies the action, the resource, the source standard, and illustrates the identifier format. There is no filler or redundant restatement of the tool name.
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 one-parameter lookup this covers the essentials of what is being fetched, but with no output schema and no annotations the description leaves the return shape (e.g., flaw description, severity, remediation) and failure behavior undefined. That is a real gap for an agent deciding whether this call answers its question.
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% for the single parameter, and the schema already supplies example values ('A-01', 'B-04', 'CAT-A-01'). The description's own examples add only marginal extra information and do not explain normalization or variant handling, so the 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 and resource ('Looks up ... defect codes') and pins down the domain (fatal commissioning flaws from the named field-guide standard). Concrete code examples (A-01, B-02, C-03) remove any ambiguity about what a 'defect code' is, and no sibling (audit_commissioning_script, verify_hydraulic_boundary, classify_corrosion_severity, etc.) overlaps with this retrieval job.
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 explicit when-to-use or when-not-to-use guidance and no pointer to alternatives. The agent can infer this is the reference lookup to call when it encounters a defect code, but that inference is entirely unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the Data Center Field Guides ground-truth corpus for commissioning procedures, fatal flaw criteria, and engineering formulas.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms or protocol topic (e.g. "NVL72 manifold", "corrosion coupon", "MOP switching", "Level 4 commissioning", "substation TDD") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It usefully signals that results come from a curated ground-truth corpus rather than a generic index, and 'searches' implies a non-destructive read. It says nothing about result count, ranking, citation format, or whether empty results are possible, which leaves real gaps for a no-annotation 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?
One sentence, front-loaded with the action and target, with no filler. Every clause contributes either scope (the corpus) or content coverage (procedures, criteria, formulas).
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 retrieval tool with no output schema and no annotations, the description covers what the tool searches and, in effect, what kind of content comes back. The remaining gap is operational detail about result shape and limits, which is minor given the tool's simplicity.
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?
There is a single required parameter with 100% schema description coverage, and the schema already supplies concrete query examples ('NVL72 manifold', 'MOP switching'). The description adds no further guidance on query formulation or phrasing, so the baseline of 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 gives a specific verb (searches) and a named resource (the Data Center Field Guides ground-truth corpus), plus the content types it returns (commissioning procedures, fatal flaw criteria, engineering formulas). That is enough to separate it from the compute/lookup siblings like calculate_pipe_friction_loss or lookup_defect_code, though it never explicitly names those alternatives.
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 intent to retrieve source-corpus material is implied by 'ground-truth corpus,' but there is no explicit when-to-use or when-not-to-use guidance and no routing between this and sibling tools. An agent must infer that this is the fallback for open-ended topical retrieval rather than a targeted computation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates required coolant flow rate, mass balance, heat removal capacity, and ASHRAE Liquid Cooling Class compliance for AI compute racks (e.g., NVIDIA GB200 NVL72).
| Name | Required | Description | Default |
|---|---|---|---|
| delta_t_c | Yes | Coolant temperature rise across compute cold plates in °C (e.g. 10 to 15) | |
| coolant_type | No | Coolant fluid: water, pg25 (25% Propylene Glycol), pg30, eg25 (25% Ethylene Glycol) | pg25 |
| heat_load_kw | Yes | Total heat load to be rejected via liquid loop in kW (e.g. 132 for NVL72) | |
| supply_temp_c | No | Supply coolant temperature in °C (optional) | |
| measured_flow_lpm | No | Actual measured coolant flow rate in Liters/Minute (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Calculates' reasonably implies a pure, side-effect-free computation, and the description does disclose the four result categories it produces, but it never explains what optional inputs like measured_flow_lpm do (presumably a measured-vs-required comparison, given the tool name 'verify'), nor any error/validity conditions or output shape.
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 computed outputs are listed compactly. Its only structural weakness is that it packs four result types into one clause, leaving no separate sentence for scope or behavior.
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 five parameters, no annotations, and no output schema, the description should do more: it lists what is computed but not how results are returned, and it leaves the 'verify' framing of the tool name unexplained relative to its stated 'calculates' behavior. The rich schema offsets the parameter gap, keeping this at a minimum-viable level.
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% â every parameter, including units, ranges, enum values, and defaults, is documented in the schema. The description adds essentially no parameter-level meaning beyond restating the computed quantities, so the 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') and enumerates concrete resources/outputs: coolant flow rate, mass balance, heat removal capacity, and ASHRAE Liquid Cooling Class compliance, scoped to AI compute racks with a concrete example (GB200 NVL72). That makes the tool clearly distinguishable by subject matter from siblings like calculate_pipe_friction_loss or classify_corrosion_severity, though it never explicitly contrasts itself with them.
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 only implied by the domain phrase 'for AI compute racks (e.g., NVIDIA GB200 NVL72)' â an agent can infer this is for liquid-cooled AI rack verification, but there is no explicit when-to-use statement, no mention of when NOT to use it, and no pointer to calculate_pipe_friction_loss or other siblings for related calculations.
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.0audit_commissioning_scriptcalculate_pipe_friction_lossclassify_corrosion_severitylookup_defect_codesearch_field_protocolsverify_hydraulic_boundaryScored across 6 tools
Most tools target clearly distinct actions and artifacts, such as auditing a script, searching field protocols, classifying corrosion, or looking up a defect code. The only potential overlap is between verify_hydraulic_boundary and calculate_pipe_friction_loss, since both perform hydraulic calculations, though their descriptions distinguish system-level rack verification from pipe-level friction loss.
All six tool names follow a consistent snake_case verb_noun pattern: audit_, verify_, calculate_, search_, classify_, and lookup_. The verbs are specific and the naming convention is predictable throughout.
Six tools is well-scoped for a focused data center auditing server. Each tool maps to a distinct audit or engineering sub-task, and there is no evident padding or redundancy.
The surface covers the core auditing workflow: script audit, hydraulic verification, friction calculations, protocol search, corrosion classification, and defect lookup. Minor gaps exist around report generation/export or batch auditing, but the main lifecycle needs are represented.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Paid deterministic data-quality and execution-verification tools for AI agents.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
