Design, validate, and lay out AI data centers worldwide via three MCP tools.
design: Size an AI data center from IT load, rack density, GPU generation (Hopper/Blackwell/Rubin), site area, and region — returns rack count, design PUE, total MVA, plus cost in KRW and timeline when available; supports optional redundancy, cooling mode, and PUE target overrides.
validate: Check a design against electrical, cooling, layout, safety, and data rules — returns severity-classified findings (blocking/warn/info) and RFI items; accepts either a raw input to size-then-validate or a previously computed design summary.
layout: Generate rack and site layout plans — returns a rack plan (hall dimensions in mm, row/column grid, per-rack positions and kW) and a site plan (block-level layout in percentage coordinates), optionally georeferenced via a WGS84 site centroid.
AI data center sizing, validation, and layout via a remote MCP server.
AI 데이터센터 자동화 툴: 결정론적 엔진으로 AI 데이터센터를 설계·검증·레이아웃합니다.
This repository shows how to connect an MCP client or REST client to the AIDC-AI.IO Design Engine — a deterministic, source-backed engine that sizes, validates, and lays out Rubin-era AI data centers.
What the engine does (on the server):
Accepts an IT load, rack density, GPU generation (Hopper / Blackwell / NVIDIA Vera Rubin NVL72 / VR200), and site constraints.
Returns deployment-unit-snapped rack counts, design PUE, power-factor-backed total MVA (22.9 kV intake), liquid-cooling / air-cooling heat split, CDU planning values, cost (KRW), and timeline.
Validates designs against electrical, cooling, layout, safety, and data rules with severity-classified findings and RFIs.
Generates a rack-plan grid (hall dimensions, row/column positions in mm) and a site-block layout.
What this repo contains:
MCP client configuration snippet.
curl and Node.js examples that call the public REST projection (/api/agent/*).
Authenticated runnable examples that read the current response shape.
The core calculation engine, reference catalogs (rack library, AHJ/code matrix, 1.6T fabric topology, direct-to-chip (D2C) cooling models, etc.) are proprietary and remain server-side. No engine source is published here.
Korea live. Region-specific: 22.9 kV utility intake, Korean AHJ/code, climate, and operations validation. Keywords the engine targets: AI data center, AIDC, NVIDIA Rubin, Vera Rubin, 22.9kV, liquid cooling, CDU, D2C, 1.6T fabric, PUE.
Related MCP server: datacenter-mcp-server
Field | Value |
Transport | Streamable HTTP |
Endpoint |
|
Official registry name |
|
Registry descriptor |
|
Auth | Registered API key required. Configure |
Tool count | 3 |
Limits | The registered account limits apply; preserve HTTP 429 and |
Tool | One-line description |
| Size an AI data center: returns rack count, PUE, total MVA, liquid/air cooling split, CDU count, cost (KRW), and build timeline. |
| Check a design against electrical, cooling, layout, safety, and data rules; returns severity-classified findings and RFIs. |
| Generate a rack-plan grid (hall dimensions, row/column positions in mm) and a site-block layout. |
Obtain a registered integration key through AIDC Contact.
Use a client that supports Streamable HTTP and pass the key through its
credential settings as an Authorization: Bearer header. The mcp.json
example contains a replacement marker, not a working credential. Keep the
configured copy private and never commit a real key.
For a local stdio client, the published package is available through npm:
npx -y aidc-mcp-server@0.2.4Set AIDC_API_KEY in the MCP server process's environment using your client's
secret or environment configuration. A file next to the server is not read
automatically. design, validate, and layout do not accept credentials
as tool inputs. Authentication errors are connection-configuration failures,
not engineering verdicts.
Build and run the same published MCP server used for registry evaluation:
docker build -t aidc-ai-mcp .
docker run --rm -i -e AIDC_API_KEY aidc-ai-mcpThe container communicates over stdio and connects to https://aidc-ai.io by
default. Export a registered AIDC_API_KEY before running the container;
-e AIDC_API_KEY forwards the existing variable without placing its value in
the command text.
The MCP package calls these REST endpoints. All calculation routes require a registered key:
Tool | REST endpoint |
|
|
|
|
|
|
curl -s -X POST https://aidc-ai.io/api/agent/design \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${AIDC_API_KEY}" \
-d '{
"itLoadMw": 30,
"rackDensityKw": 120,
"gpuGen": "rubin",
"siteAreaSqm": 5000,
"region": "metropolitan",
"options": {
"redundancy": "n_plus_1",
"coolingMode": "liquid",
"pueTarget": 1.2
}
}'Use node design.example.js for a live authenticated example. Successful
responses contain ok, summary, warnings, engineVersion, requestId,
and _agent. Sizing values such as rackCount, pueDesign, and mvaTotal
are inside summary. Preserve warnings and validation findings; an ok: true
response does not certify the design or turn PENDING into PASS.
There is no fixed numeric output fixture for a real project. Use the returned engine result and its evidence for the exact selected inputs.
designSize an AI data center from scratch.
Field | Type | Range / values | Required |
| number | 0 < x ≤ 1000 | Yes |
| number | 0 < x ≤ 500 | Yes |
| string |
| Yes |
| number | 0 < x ≤ 1 000 000 | Yes |
| string |
| Yes |
| string |
| No |
| string |
| No |
| number | 1.0 – 2.5 | No |
Key response fields: summary.rackCount, optional summary.unsnappedRackCount,
summary.pueDesign, summary.mvaTotal, and cooling/commercial values inside
summary. warnings[], engineVersion, and requestId are top-level fields.
validateCheck a design against engineering rules.
{
"rawInput": {
"itLoadMw": 30,
"rackDensityKw": 120,
"gpuGen": "rubin",
"siteAreaSqm": 5000,
"region": "metropolitan"
}
}Key response fields: findings[] (including severity, family, message,
and optional publicRuleId), rfis[], and optional verdict / graphVerdict.
Public MCP accepts rawInput or designSummary; private EngineSession IDs
remain in the signed-in AIDC workflow.
layoutGenerate a rack plan and site block layout.
{
"design": {
"itLoadMw": 30,
"rackDensityKw": 120,
"gpuGen": "rubin",
"siteAreaSqm": 5000,
"region": "metropolitan"
},
"siteCentroid": { "lat": 37.5665, "lng": 126.9780 },
"siteAreaSqm": 5000
}Key response fields: rackPlan (hall dimensions, rows, columns, per-rack positions in mm),
sitePlan (block-level layout in percentage coords)
Resource | URL |
Website | |
OpenAPI 3.1 spec | |
MCP server card | |
LLM context | |
Full LLM context | |
Contact |
This repository (examples and connector code only) is released under the MIT License.
The AIDC-AI.IO engine, reference catalogs, and all server-side logic remain proprietary.
Generate a profile-aware AI data center design basis from OPR inputs and optional project data.
| Name | Required | Description | Default |
|---|---|---|---|
| gpuGen | Yes | NVIDIA GPU generation: hopper, blackwell, or rubin. | |
| region | Yes | Metropolitan or regional site class. | |
| options | No | Optional redundancy, cooling-mode, and PUE overrides. | |
| parcels | No | Optional bounded GeoJSON parcel features. | |
| itLoadMw | Yes | IT load in megawatts. 0 < x <= 1000. | |
| hallCount | No | Optional requested data-hall count. | |
| siteAreaSqm | Yes | Total site area in square meters. | |
| customInputs | No | Optional project-specific design inputs. | |
| rackDensityKw | Yes | Requested per-rack power in kW. 0 < x <= 500. |
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 says the tool generates a design basis, but it does not disclose whether it is read-only, whether it persists anything, what permissions are needed, or how errors are handled. The mention of 'profile-aware' is too vague to count as meaningful behavioral disclosure.
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?
It is a single, front-loaded sentence with no redundant or filler language. Every part of the sentence contributes to identifying the tool's output and input context.
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?
The tool has 9 parameters, 5 required, nested objects, no annotations, and no output schema, yet the description only gives a one-line summary. It does not explain the output structure, behavioral expectations, or how the optional inputs affect the result, leaving substantial gaps for a complex sizing 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 input schema already provides per-parameter meaning. The description adds only a high-level grouping ('OPR inputs and optional project data') and no parameter-level detail beyond what the schema states, so the baseline of 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?
The description states a specific verb ('Generate') and resource ('AI data center design basis'), with the input source ('OPR inputs and optional project data'). It is clear what the tool produces, but it does not distinguish itself from the sibling tools 'validate' and 'layout'.
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 guidance on when to use this tool versus alternatives. The phrase 'from OPR inputs and optional project data' hints at context, but it does not state prerequisites, exclusions, or when a caller should prefer 'validate' or 'layout'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate profile-aware physical rack blocks, rack-plan candidates, and site layout data from a nested design request.
| Name | Required | Description | Default |
|---|---|---|---|
| design | Yes | Nested design request that drives layout. | |
| siteAreaSqm | No | Optional layout-specific site area override. | |
| siteCentroid | No | Optional WGS84 site centroid. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and discloses almost nothing beyond purpose. It does not say whether generation is deterministic, read-only, whether it consumes significant compute, or how many candidates are produced. 'Profile-aware' is unexplained jargon.
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, stating the verb, the outputs, and the input source. It is efficient, though too sparse given the tool's complexity.
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 complex generator with a deeply nested input schema and no output schema, the description enumerates the return artifacts but omits invocation context, ordering relative to 'design'/'validate', and any behavioral caveats. Adequate but thin relative to complexity.
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 the nested design request and the optional overrides, establishing a baseline of 3. The description only nods to 'a nested design request' and adds no meaning beyond what the schema 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?
Names a specific verb ('Generate') and concrete resources ('physical rack blocks, rack-plan candidates, and site layout data'), which is far better than a tautology. It is clear what the tool produces, though it does not explicitly contrast itself with the sibling 'design' tool that presumably produces the input request.
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 phrase 'from a nested design request' faintly implies this runs after a design exists, but there is no explicit when-to-use statement, no named alternatives among design/validate, and no prerequisites or ordering guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a previous design summary or raw design input against engineering rules. Private EngineSessions remain in the signed-in AIDC workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| rawInput | No | Raw design request to size and validate. | |
| designSummary | No | Previously computed design summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'Against engineering rules' is vague about what is checked or returned, and the EngineSessions sentence only hints at session/auth scoping ('signed-in AIDC workflow') without stating whether validation mutates state or requires authentication.
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 purpose sentence is front-loaded and tight, which is good. The second sentence about private EngineSessions is cryptic and its contribution is unclear, so it does not clearly 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?
This is a complex validation tool with deep nested schemas, no annotations, and no output schema, yet the description never explains what a validation result looks like or what happens on failure. Given the complexity, the description leaves significant gaps for an agent to call it correctly.
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 baseline is 3. The description correctly names the two mutually exclusive inputs matching the schema's anyOf, but adds no syntax, format, or constraint detail beyond what the schema already documents.
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 (validate) and resource (data center design) and clarifies the two accepted input forms (design summary or raw input). It does not differentiate itself from the sibling tools 'design' and 'layout', so it falls short of a 5.
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?
'Validate a previous design summary or raw design input' implies the follow-on role after a design step, which is useful. However, there is no explicit when-not guidance and no routing to the 'design' or 'layout' siblings, leaving the agent to infer which tool starts the workflow.
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.2designlayoutvalidate17 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "designSummary"
+ ]
+ },
+ {
+ "required": [
+ "rawInput"
+ ]
+ }
+]Input schema / descriptionAdded value: +"Provide a previous design summary or raw design input. Private EngineSessions remain in the signed-in AIDC workflow."Input schema / properties / designSummary / additionalPropertiesRemoved value: -falseInput schema / properties / designSummary / descriptionPrevious value: -"Previously computed design summary. Provide either this OR rawInput."New value: +"Previously computed design summary."Input schema / properties / rawInput / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / rawInput / descriptionPrevious value: -"Raw design request. The engine will size first, then validate. Provide either this OR designSummary."New value: +"Raw design request to size and validate."Input schema / properties / rawInput / properties / customInputsAdded value: +{
+ "additionalProperties": {},
+ "description": "Optional project-specific design inputs.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / rawInput / properties / gpuGen / descriptionPrevious value: -"NVIDIA GPU generation. hopper=H100/H200, blackwell=B100/B200/GB200, rubin=R100/Vera Rubin."New value: +"NVIDIA GPU generation: hopper, blackwell, or rubin."Input schema / properties / rawInput / properties / hallCountAdded value: +{
+ "description": "Optional requested data-hall count.",
+ "exclusiveMinimum": 0,
+ "maximum": 48,
+ "type": "integer"
+}Input schema / properties / rawInput / properties / itLoadMw / descriptionPrevious value: -"IT load in megawatts. 0 < x ≤ 1000."New value: +"IT load in megawatts. 0 < x <= 1000."Input schema / properties / rawInput / properties / options / additionalPropertiesRemoved value: -falseInput schema / properties / rawInput / properties / options / descriptionPrevious value: -"Optional engineering overrides: redundancy tier (n / n+1 / 2n), cooling mode (air / hybrid / liquid), PUE target (1.0–2.5)."New value: +"Optional redundancy, cooling-mode, and PUE overrides."Input schema / properties / rawInput / properties / parcelsAdded value: +{
+ "description": "Optional bounded GeoJSON parcel features.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "geometry": {
+ "anyOf": [
+ {
+ "properties": {
+ "coordinates": {
+ "items": {
+ "items": {
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 3,
+ "minItems": 2,
+ "type": "array"
+ },
+ "maxItems": 512,
+ "minItems": 4,
+ "type": "array"
+ },
+ "maxItems": 16,
+ "minItems": 1,
+ "type": "array"
+ },
+ "type": {
+ "const": "Polygon",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "coordinates"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "coordinates": {
+ "items": {
+ "items": {
+ "items": {
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 3,
+ "minItems": 2,
+ "type": "array"
+ },
+ "maxItems": 512,
+ "minItems": 4,
+ "type": "array"
+ },
+ "maxItems": 16,
+ "minItems": 1,
+ "type": "array"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "type": "array"
+ },
+ "type": {
+ "const": "MultiPolygon",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "coordinates"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+ ]
+ },
+ "properties": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "type": {
+ "const": "Feature",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "geometry"
+ ],
+ "type": "object"
+ },
+ "maxItems": 25,
+ "type": "array"
+}Input schema / properties / rawInput / properties / rackDensityKw / descriptionPrevious value: -"Per-rack power in kW. 0 < x ≤ 500. Rubin Ultra targets 300+."New value: +"Requested per-rack power in kW. 0 < x <= 500."Input schema / properties / rawInput / properties / region / descriptionPrevious value: -"Site classification. metropolitan = dense urban / capital region (e.g. Seoul / Tokyo / Frankfurt / Northern Virginia), regional = secondary / suburban / industrial-park region. Drives utility cost and substation availability assumptions."New value: +"Metropolitan or regional site class."Input schema / properties / rawInput / properties / siteAreaSqm / descriptionPrevious value: -"Total site area in m². 0 < x ≤ 1,000,000."New value: +"Total site area in square meters."v0.1.1designvalidatelayoutvalidatev0.1.0designlayoutvalidateScored across 3 tools
The three tools target distinct stages: design generates the design basis, validate checks inputs/rules, layout produces physical rack/site data. No functional overlap; boundaries are clear from descriptions.
All tool names are single, lowercase action words (design, validate, layout) following a consistent terse style. No mixed conventions or casing.
Three tools is well within the ideal 3-15 range and each maps to a core operation (generate, validate, layout). No redundant tools; the set is tightly scoped.
Core generate-validate-layout pipeline is covered, but there is no explicit retrieval/update/list for designs, and sessions are handled externally. Minor gaps may require workarounds but no critical dead end.
AI data-center design engine: size, validate & lay out Rubin-era data centers. Korea live.
MCP Hub: AI service discovery, per-user OAuth, and multi-service workflow orchestration
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Massed Compute MCP — GPU inventory, VM lifecycle, billing, SSH keys, and setup recipes.
