Skip to main content
Glama
log-wade

datacenter-mcp-server

by log-wade

Data Center Cooling Load Calculator

dc_calculate_cooling_load
Read-onlyIdempotent

Calculate data center cooling capacity requirements in kW, tons, and BTU/hr from IT load, PUE, and environmental factors, and get design recommendations.

Instructions

Calculate the total cooling load for a data center facility based on IT load, PUE, and environmental factors.

This tool computes cooling capacity requirements in kW, tons, and BTU/hr, estimates required airflow in CFM, rates the facility's PUE efficiency, and provides actionable recommendations for cooling system design.

Accounts for: IT heat rejection, electrical overhead losses, lighting loads, humidification, and altitude derating above 5,000 ft.

Args:

  • it_load_kw (number): Total IT electrical load in kW

  • pue (number): Power Usage Effectiveness ratio (1.0-3.0)

  • safety_factor (number): Design margin (default 1.15 = 15%)

  • lighting_area_sqft (number): Floor area for lighting heat gain

  • include_humidification (boolean): Include humidification load

  • altitude_ft (number): Site altitude for equipment derating

  • design_outdoor_temp_f (number): ASHRAE design day temperature

Returns structured JSON with cooling_load_kw, cooling_load_tons, cooling_load_btu, estimated_airflow_cfm, pue_rating, and engineering recommendations.

Examples:

  • "Calculate cooling for a 2 MW data center with PUE of 1.4" -> it_load_kw: 2000, pue: 1.4

  • "What cooling do I need for 500 kW at 6000 ft altitude?" -> it_load_kw: 500, pue: 1.5, altitude_ft: 6000

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pueYesPower Usage Effectiveness — ratio of total facility power to IT power (typically 1.2-1.8)
it_load_kwYesTotal IT electrical load in kilowatts (kW)
altitude_ftNoSite altitude in feet above sea level (equipment derating applied above 5,000 ft)
safety_factorNoDesign safety factor applied to cooling capacity (default: 1.15 = 15% margin)
lighting_area_sqftNoWhite space floor area in square feet (for lighting/misc heat gain calculation)
design_outdoor_temp_fNoDesign outdoor dry-bulb temperature in Fahrenheit (ASHRAE 0.4% cooling design day)
include_humidificationNoWhether to include humidification load in calculation (adds ~7%)
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, and non-destructive. The description adds context about included calculations (IT heat rejection, electrical losses, lighting, humidification, altitude derating) and return format, exceeding the annotation baseline. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, capabilities, factors, args, returns, examples. It is front-loaded with key info. However, the Args section duplicates the schema, adding redundancy and length without new value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no output schema, the description covers return fields and calculation factors, plus examples. It lacks emphasis on required parameters and edge cases, but is otherwise complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The Args section mostly reiterates schema descriptions. The examples add some semantic mapping from natural language to parameters, but not enough to elevate beyond baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calculates total cooling load for a data center, with specific outputs (kW, tons, BTU/hr, CFM, PUE rating, recommendations). It differentiates from siblings by focusing on cooling load, while others address power redundancy, tier classification, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on what the tool does and its inputs (factors like IT load, PUE, environmental factors), with examples of typical use. However, it does not explicitly mention alternatives or when not to use this tool, though sibling tools are distinct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/log-wade/datacenter-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server