RackArchitect MCP
REMOTE · MCP.RACKARCHITECT.DEV · 3 COMPONENTS
Hosted Remote MCP & 3D/2D Rack-as-Code planner, 5-stage validator, CAD SVG/BOM & STL generator.
Last scanned (6 hours ago)
Scores higher than 55% of remote servers
Reachable. Last reached 5 Nov 2026.
Category IoT and Hardware
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (init_rack). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability77
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4063 tokens (~253/item across 16 items; 12 tools + 4 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management23
- Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.
- 3 Nov 26 0
- Tool “export_deliverables” rewrote its description, which is the text the model reads security
- Tool “export_deliverables” is now declared destructive security
- Server version: 0.7.7 → 0.7.8 functional
- Server version: 0.7.6 → 0.7.7 functional
- 2 Nov 26 +1
- Server version: 0.7.5 → 0.7.6 functional
- 31 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.
- 30 Oct 26 0
- Tool “plan_external_endpoints” rewrote its description, which is the text the model reads security
- Tool “search_catalog” rewrote its description, which is the text the model reads security
- Tool “undo_redo” rewrote its description, which is the text the model reads security
- Tool “validate_rack” rewrote its description, which is the text the model reads security
- Tool “mount_equipment” rewrote its description, which is the text the model reads security
- Tool “modify_equipment” rewrote its description, which is the text the model reads security
- Tool “init_rack” rewrote its description, which is the text the model reads security
- Tool “get_device_blueprint” rewrote its description, which is the text the model reads security
- Tool “export_deliverables” rewrote its description, which is the text the model reads security
- Tool “disconnect_cables” rewrote its description, which is the text the model reads security
- Tool “define_custom_blueprint” rewrote its description, which is the text the model reads security
- Tool “connect_cables” rewrote its description, which is the text the model reads security
- Stability: unverified → 0.03 ▲ functional
- Server version: 0.7.4 → 0.7.5 functional
- 29 Oct 26 67
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://mcp.rackarchitect.dev/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.rackarchitect.dev | CN=YE2,O=Let's Encrypt,C=US | 29 Oct 2026 | 27 Jan 2027 | ECDSA 384 | ECDSA-SHA384 | 5a6a574bb1cfb2dd3f90e231c04add027fc |
| SANs: mcp.rackarchitect.dev | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.rackarchitect.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| rackarchitect.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; preload |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | no-referrer |
| permissions-policy | camera=(), microphone=(), geolocation=(), payment=(), usb=() |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.rackarchitect.dev/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.rackarchitect.dev/mcp | HTTPS enforced | 301 | https://mcp.rackarchitect.dev/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
connect_cables Connect and Route Inter-Device Cables ~253
Connect or update a batch of up to 128 power and network cables between mounted device ports in the active rack, computing 3D Catmull-Rom splines, commercial length bins, and PoE or power budgets. Each entry in 'cables[]' upserts in place by 'cable_id' while leaving all other cables and mounted equipment untouched, pushes a recoverable undo snapshot, and persists rack.yaml atomically; port, speed, PoE, or clearance violations return status 'INVALID' with remediation_suggestions instead of throwing. Within each cable, endpoint 'face' is required only on pass-through couplers such as patch panels exposing identical 'port_id' values on both faces, 'preferred_portal_u' applies only to front-to-rear transitions, and 'vlan_id' or 'ip_cidr' annotate logical network links. Use when both endpoint devices are mounted inside the rack; use disconnect_cables to remove cables, or plan_external_endpoints to terminate incoming building cable drops on a patch panel.
| Name | Type | Req | Description |
|---|---|---|---|
| cables | array | yes | Batch of one or more cable connections to upsert by cable_id, route in 3D, and validate (max 128 per call). |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Cable connection and 3D routing result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
define_custom_blueprint Register Custom Hardware Blueprint ~221
Validate and register a custom hardware blueprint into the active catalog so unlisted equipment can be mounted. Pass the entire specification inside the top-level 'blueprint' object: 'blueprint.slug' must use lowercase kebab-case, ports may combine explicit 'ports[]' with repeating 'port_groups[]' macros whose coordinates fit strictly within 'blueprint.geometry' without overlapping, and 'slots[]' applies only when 'mount_type' is 'modular-carrier' whereas 'slot_compatibility' applies to 'sub-module'. Persists YAML to the local custom-catalog folder in stdio mode or session memory on remote servers, overwrites same-slug custom entries without touching mounted rack state or undo history, and returns status 'INVALID' instead of throwing on validation errors. Use only after search_catalog confirms hardware is unlisted; use mount_equipment instead to place an already registered blueprint into the rack.
| Name | Type | Req | Description |
|---|---|---|---|
| blueprint | object | yes | Complete custom hardware blueprint specification; ports may be defined via explicit ports[], repeating port_groups[] macros, or both. |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Custom blueprint registration payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
disconnect_cables Disconnect Cables by ID or Device Instance ~260
Remove specific cables by identifier or strip all cables attached to a mounted device or modular carrier from the active rack, then re-evaluate PoE budgets and plug clearances. Supply a non-empty 'cable_ids' list, 'instance_id', or both to disconnect their union; 'instance_id' matches both 'from' and 'to' endpoints across a carrier and its child sub-modules while leaving external patch-panel drops intact, whereas omitting both or passing only an empty list returns status 'INVALID' with a PORT_NOT_FOUND issue and zero mutations. Valid calls push an undo snapshot, persist rack.yaml atomically, and return removed IDs, remaining cable count, and updated validation results, succeeding idempotently when targeted IDs are already absent. Use when rewiring ports while keeping hardware mounted; use connect_cables to add or replace cables, or modify_equipment with action 'remove' to delete a device and its cables.
| Name | Type | Req | Description |
|---|---|---|---|
| cable_ids | array | – | Specific cable_id values to disconnect (can be combined with instance_id; at least one of cable_ids or instance_id must be provided). |
| instance_id | string | – | Mounted device or modular-carrier instance_id whose attached cables (including child sub-module cables) should all be disconnected. |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Cable disconnection result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
export_deliverables Export 2D SVG, BOM, 3D GLB, and 3D-Print Deliverables ~297
Generate 2D elevation and wiring SVGs, a Markdown BOM, a binary 3D GLB scene, and parametric OpenSCAD or watertight STL 3D-print models for the active rack project. Omitting 'formats' exports all six types; 'carrier-scad' and 'carrier-stl' emit one file per mounted modular carrier, switch cradle, or printable cover panel and emit zero files when none are mounted, while 'output_dir' resolves relative paths within the project directory and creates missing folders. Local stdio execution writes deterministic filenames—elevation.svg, wiring-schematic.svg, BOM.md, rack-scene.glb, and <slug>.scad or <slug>.stl—overwriting same-named files in place, whereas hosted remote sessions stream in-memory HTTPS download URLs; neither mode mutates rack state or undo history. Use after validate_rack confirms a valid layout; use validate_rack instead for read-only validation and ASCII elevation inspection without generating export files.
| Name | Type | Req | Description |
|---|---|---|---|
| formats | array | – | Deliverable formats to generate and write to disk (defaults to all 6 formats; carrier-scad and carrier-stl emit files when modular carriers are mounted). |
| output_dir | string | – | Optional target filesystem directory for generated files in local stdio mode (defaults to the directory of the active rack.yaml file; ignored on hosted remote MCP servers where HTTPS download URLs ar… |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Deliverable export result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
get_device_blueprint Retrieve Hardware Device Blueprint Details ~186
Retrieve the complete hardware specification, millimeter port coordinates, electrical and PoE ratings, and carrier slot geometry for a single catalog blueprint. The 'slug' parameter requires a case-sensitive exact match in lowercase kebab-case vendor-model-variant format against the built-in or session custom catalog; partial substrings or uppercase characters do not match. Returns the full blueprint in one unpaginated payload with repeating port_groups pre-expanded into up to 256 flat ports[] entries, or returns status 'INVALID' with a BLUEPRINT_NOT_FOUND issue and candidate slugs instead of throwing. Use when you already know the target slug and need exact port_id or slot_id values for mount_equipment or connect_cables; use search_catalog instead to discover unknown slugs by criteria.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | Exact lowercase kebab-case hardware catalog blueprint slug to retrieve (discoverable via search_catalog). |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Blueprint lookup result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
init_rack Initialize and Reset Rack Enclosure ~393
Initialize a new rack project and destructively reset the active rack.yaml state to an empty enclosure with the specified width standard, U height, and rail depth. Overwrites the current enclosure and clears all mounted devices, child sub-modules, cables, and external endpoints, while pushing the previous project state onto the in-memory undo stack for recovery via undo_redo. 'project_name' sets the title used in exported schematics and BOMs, 'rail_depth_mm' plus 'rear_clearance_mm' bounds total +Z chassis and rear plug depth before wall collision, and 'front_door_clearance_mm' is enforced only when 'enclosure_type' has a closed front door. Use when starting a rack design from scratch or changing enclosure dimensions; use validate_rack to inspect the current rack, or modify_equipment to move or remove individual devices.
| Name | Type | Req | Description |
|---|---|---|---|
| enclosure_type | string | – | Enclosure door style ("open-frame", "closed-glass-front", or "closed-vented-front"). |
| front_door_clearance_mm | number | – | Available clearance in millimeters between front mounting rails (Z=0) and a closed front door. |
| project_name | string | – | Human-readable project name stored in rack.yaml. |
| rail_depth_mm | number | yes | Front-to-rear mounting rail depth in millimeters along the Z-axis (max 2000mm). |
| rear_clearance_mm | number | – | Available clearance in millimeters behind the rear mounting rails (Z=rail_depth_mm) for power plugs and bending radii. |
| standard | string | yes | Mechanical rack width standard ("19inch" = 482.6mm, "10inch" = 254.0mm, "6inch" = 152.4mm). |
| u_height | integer | yes | Total usable vertical rack height in Rack Units (1U = 44.45mm, 1..60U). |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Rack initialization payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
modify_equipment Move, Rename, or Remove Mounted Equipment ~503
Move, rename, or destructively remove an existing mounted device or child sub-module in the active rack, recalculate 3D cable splines, and re-run 5-stage validation. 'instance_id' resolves across top-level devices and carrier sub-modules, and required fields depend on 'action': 'move' updates 'u_position' and 'face' on rackmount gear or 'slot_id' and optional 'parent_carrier_id' across carriers for sub-modules with primary fields taking precedence over 'new_*' aliases, 'rename' updates or clears 'hostname', and 'remove' cascades to child sub-modules plus attached cables and external endpoints when 'remove_connected_cables' is true. Pushes the prior state onto the undo stack and updates rack.yaml atomically, or returns status 'INVALID' without mutating state when 'instance_id' or a target carrier is unknown. Use to update or delete a mounted instance; use mount_equipment to add new hardware, or disconnect_cables to remove cables while keeping devices mounted.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | Modification operation: "move" relocates a device, "rename" updates its hostname, and "remove" deletes the device instance. |
| face | string | – | New mounting face ("front" or "rear") when action is "move" on a rackmount device (takes precedence over new_face). |
| hostname | string | – | New logical hostname when action is "rename" (takes precedence over new_hostname). |
| instance_id | string | yes | Existing mounted device or child sub-module instance_id to modify. |
| new_face | string | – | Optional alias for face when action is "move". |
| new_hostname | string | – | Optional alias for hostname when action is "rename". |
| new_u_position | integer | – | Optional alias for u_position when action is "move". |
| parent_carrier_id | string | – | Target parent carrier instance_id when action is "move" on a child sub-module. |
| remove_connected_cables | boolean | – | When action is "remove", whether to automatically disconnect all cables and external endpoints attached to the removed device (default: true). |
| slot_id | string | – | Target slot_id inside parent_carrier_id when action is "move" on a child sub-module. |
| u_position | integer | – | New 1-indexed U position when action is "move" on a direct rackmount device (takes precedence over new_u_position). |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Equipment modification result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
mount_equipment Mount Equipment into Rack Unit or Carrier Slot ~404
Mount a new hardware device instance onto a rack unit or into a modular carrier bay in the active rack.yaml project and run 5-stage validation. 'instance_id' must be unique across both top-level devices and nested sub-modules, 'blueprint_slug' must reference an existing catalog or custom slug, and placement uses two mutually exclusive modes: 'u_position' with optional 'face' where the device's full U span fits within 1..u_height, or 'parent_carrier_id' plus a compatible 'slot_id' for sub-modules. Precondition errors such as duplicate 'instance_id', unknown 'blueprint_slug', or missing carriers return status 'INVALID' without mutating state, whereas 3D collision or PoE issues persist the mount, push an undo snapshot, and return remediation_suggestions. Use to add a new device instance; use modify_equipment to move, rename, or remove an existing instance, or plan_external_endpoints for off-rack room cable drops.
| Name | Type | Req | Description |
|---|---|---|---|
| blueprint_slug | string | yes | Catalog or custom hardware blueprint slug to instantiate. |
| face | string | – | Target rack mounting face ("front" or "rear") for direct rackmount equipment. |
| hostname | string | – | Optional logical hostname or display label shown in elevations and schematics. |
| instance_id | string | yes | Unique project-wide instance identifier for this mounted device (e.g., "ups-u1", "sw-core-01"). |
| parent_carrier_id | string | – | Mounted parent modular-carrier instance_id when mounting a sub-module (requires slot_id; mutually exclusive with u_position). |
| slot_id | string | – | Target bay slot_id inside parent_carrier_id when mounting a sub-module (e.g., "left-bay", "keystone-1"). |
| u_position | integer | – | 1-indexed lowest Rack Unit (U) when mounting directly onto the rack rails (mutually exclusive with parent_carrier_id/slot_id). |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Equipment mounting result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
plan_external_endpoints Terminate External Building Cable Drops on Patch Panel ~416
Terminate external building or room cable drops onto the rear RJ45 ports of a mounted patch panel without consuming rack U slots, and optionally auto-create labeled Cat6A front patch cables to a mounted switch. 'groups[]' batch-generates drops first—with 'custom_labels[]' overriding numbered 'label_prefix' entries per index—followed by 'endpoints[]', allocating sequential free rear ports from 'start_port_number' and sequential free switch RJ45 ports from 'auto_connect_switch_start_port'. Setting 'clear_existing' destructively removes prior external drops on 'patch_panel_instance_id' and their front patch cables before allocation, while unmounted patch-panel or switch IDs return status 'INVALID' without mutating state. Use for off-rack building wiring entering the enclosure; never mount room endpoints via mount_equipment, and use connect_cables for purely internal rack-to-rack links.
| Name | Type | Req | Description |
|---|---|---|---|
| auto_connect_switch_instance_id | string | – | Optional switch instance_id to automatically patch from the front of the patch panel using labeled Cat6A cables. |
| auto_connect_switch_start_port | integer | – | 1-indexed starting Ethernet port number on auto_connect_switch_instance_id (e.g., 1 for eth1). |
| clear_existing | boolean | – | If true, destructively clears existing external_endpoints (and their front patch cables) on patch_panel_instance_id before planning. |
| endpoints | array | – | Individual external building/room drops to terminate on the rear of the patch panel. |
| entry_position | string | – | Rear building cable conduit entry point into the rack frame. |
| groups | array | – | Batch groups of external drops (e.g., 10x PoE cameras, 5x Wi-Fi APs, 5x room LAN outlets). |
| patch_panel_instance_id | string | yes | Mounted patch panel instance_id whose rear ports receive the incoming building cable drops. |
| start_port_number | integer | – | 1-indexed starting port number on the patch panel (defaults to next free rear port or 1). |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | External endpoint planning and auto-patching payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
search_catalog Search Hardware Blueprint Catalog ~446
Search and filter the local hardware catalog to discover compatible rackmount devices, modular carriers, and sub-modules before mounting. All supplied filters combine with logical AND: 'form_factor' and its alias 'mount_type' accept width shorthands '10inch', '19inch', and '6inch' that match both direct rackmount gear and modular carriers, 'accepted_slot_type' matches both carrier bays and compatible sub-modules, and 'max_depth_mm' bounds chassis depth excluding plug clearance. Returns all matches from the bounded catalog in one unpaginated response sorted in deterministic registration order, with built-in blueprints followed by custom blueprints. Call with no arguments to list the full catalog; use get_device_blueprint to inspect expanded port coordinates for a known slug, or define_custom_blueprint to register unlisted hardware.
| Name | Type | Req | Description |
|---|---|---|---|
| accepted_slot_type | string | – | Sub-module slot compatibility token matching either a sub-module slot_compatibility or a carrier slot accepted_slot_type (e.g., "mini-pc-1liter", "sbc-rpi5", "standard-keystone"). |
| category | string | – | Functional hardware category filter (e.g., "switch", "router", "ups", "pdu", "patch-panel", "modular-carrier", "mini-pc", "sbc"). |
| form_factor | string | – | Primary rack width or mounting form-factor filter (shorthands "10inch", "19inch", and "6inch" match both direct rackmount equipment and modular carriers of that width). |
| max_depth_mm | number | – | Maximum allowed chassis depth in millimeters (inclusive upper bound). |
| min_poe_budget_watts | number | – | Minimum required PSE PoE output power budget in watts (inclusive lower bound). |
| mount_type | string | – | Optional alias for form_factor to filter by physical mounting style ("rackmount-10", "rackmount-19", "rackmount-6", "sub-module", or "shelf-standing"); combined with logical AND if both are provided. |
| query | string | – | Optional case-insensitive substring filter matching slug, manufacturer, or model name (omit to match all). |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Catalog search result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
undo_redo Undo or Redo Rack State Mutation ~186
Traverse the per-project in-memory history ring buffer of up to 50 snapshots to revert the latest rack mutation or reapply a reverted mutation, updating rack.yaml atomically. Setting 'action' to 'undo' steps backward across rack-state mutations—excluding catalog-only define_custom_blueprint calls and read-only tools—and pushes the displaced state onto the redo stack, whereas 'redo' is available only immediately after 'undo' because any new rack mutation flushes the redo stack. Calling either action when its target stack is empty is a safe no-op returning applied=false without throwing. Use to roll back an unintended batch change or accidental init_rack reset; use modify_equipment or disconnect_cables instead to edit specific items without reverting intermediate steps.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | History traversal direction: "undo" reverts the most recent state mutation, "redo" reapplies a reverted mutation. |
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Undo/redo history traversal result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
validate_rack Inspect and Validate Active Rack State ~135
Inspect the active rack.yaml state and run all 5 deterministic validation stages covering mechanical bounds, 3D depth and plug clearances, PoE and power budgets, cable compatibility, and thermal limits. Takes no parameters, performs zero state or undo-stack mutations, and returns the ASCII front and rear elevation diagram, power utilization summary, and all diagnostic issues with remediation_suggestions. Sets status to 'INVALID' instead of throwing whenever any validation ERROR is present. Use to inspect currently mounted equipment or verify zero errors before exporting; use export_deliverables instead to generate SVG, BOM, GLB, or 3D-print files.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| data | object | yes | Rack state inspection and validation result payload. |
| issues | array | yes | Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. |
| status | string | yes | Deterministic execution outcome: "VALID" when the operation succeeded with 0 validation errors; "INVALID" when precondition or engineering validation errors are present in issues[]. |
| summary | string | yes | Concise human- and agent-readable summary of the tool result and validation status. |
No examples provided.
How do I install the RackArchitect MCP server?
RackArchitect MCP is a hosted endpoint at https://mcp.rackarchitect.dev/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.rackarchitect.dev
claude mcp add --transport http italex240-rack-architect-mcp 'https://mcp.rackarchitect.dev/mcp'
What is the RackArchitect MCP server?
RackArchitect MCP is listed in the public MCP registry as io.github.itAlex240/rack-architect-mcp. Hosted Remote MCP & 3D/2D Rack-as-Code planner, 5-stage validator, CAD SVG/BOM & STL generator. This page covers its hosted endpoint (https://mcp.rackarchitect.dev/mcp).
Is the RackArchitect MCP server safe to use?
RackArchitect MCP scores 70 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the RackArchitect MCP server expose?
RackArchitect MCP exposes 12 tools: search_catalog, get_device_blueprint, define_custom_blueprint, init_rack, mount_equipment, and 7 more. Their descriptions and schemas cost roughly 3,700 tokens of context every time the server is loaded.
Does the RackArchitect MCP server require authentication?
No. We connected to RackArchitect MCP without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the RackArchitect MCP server still maintained?
RackArchitect MCP is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.