RackArchitect MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_catalogC | Filter hardware blueprints by search query, form factor, category, maximum depth, minimum PoE budget, or slot compatibility. |
| get_device_blueprintA | Retrieve expanded port coordinates, electrical capabilities, and modular carrier slot layouts for a specific hardware slug. |
| define_custom_blueprintA | Register and persist a custom hardware blueprint when planning with unlisted equipment. |
| init_rackC | Initialize rack mechanical standard, U height, rail depth, and enclosure clearances. |
| mount_equipmentA | Mount a device onto a rack unit or into a modular carrier slot and run the 5-stage validation engine. |
| modify_equipmentB | Move, rename, or remove an existing mounted device instance and recalculate all 3D cable paths. |
| connect_cablesB | Connect one or more cables between device ports, computing 3D Catmull-Rom routes, commercial length bins, and PoE/power DAG status. |
| disconnect_cablesA | Disconnect cables by cable_id or remove all cables attached to a device instance_id. |
| validate_rackB | Run the full 5-stage deterministic constraint solver, generate an ASCII front/rear elevation plan, and return diagnostics with self-correction remediation suggestions. |
| export_deliverablesC | Generate 2D elevation SVG, orthogonal wiring schematic SVG, Markdown BOM, and 3D GLB deliverables. |
| undo_redoA | Revert the most recent rack state mutation (undo) or reapply a reverted mutation (redo). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| plan-homelab-from-scratch | Guided step-by-step workflow to design, wire, and validate a 10-inch or 19-inch rack without guessing geometry. |
| optimize-and-fix-rack | Analyze all mechanical, depth-clearance, thermal, and PoE/power issues in the active rack and resolve them autonomously. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Current Rack Summary & ASCII Elevation | Compact ASCII Front/Rear Elevation Plan, Power/PoE utilization, and validation summary of the active rack. |
| Current Bill of Materials (BOM) | Live Markdown Bill of Materials including hardware, 3D-printable carriers, commercial cable SKU bins, and power budget. |
| Current Validation Diagnostics Report | Structured JSON ValidationResult containing all ERROR, WARNING, and INFO issues with remediation_suggestions. |
| Current Declarative rack.yaml Source | Raw declarative YAML source of the active RackProject. |
TDQS
Scored across 11 tools
Most tools target a distinct resource+action pair: blueprint retrieval vs. catalog search vs. rack init vs. mount/modify vs. connect/disconnect. The only mild overlaps are mount_equipment vs. modify_equipment (both can reposition a device) and get_device_blueprint vs. search_catalog (both surface hardware info), but the descriptions make the intended split reasonably clear.
Nearly all tools follow a clean verb_noun pattern (get_device_blueprint, init_rack, mount_equipment, connect_cables, validate_rack). The lone deviation is undo_redo, which fuses two verbs into one name, plus minor verb variety (init vs. define), but overall the convention is predictable.
Eleven tools is squarely in the well-scoped range for a rack-design domain, with no redundant tools or obviously trivial filler. Each tool maps to a distinct stage of the workflow: catalog, blueprint, init, mount, wire, validate, export, undo.
The lifecycle is well covered end-to-end: discovery, custom blueprints, physical mounting, cabling, validation, deliverables, and undo/redo. The main gap is a read-only state inspection tool (e.g. get_rack_state / list_mounted_devices) so an agent must infer current contents from validate_rack diagnostics or an export.