# RackArchitect MCP (remote · mcp.rackarchitect.dev) Hosted Remote MCP & 3D/2D Rack-as-Code planner, 5-stage validator, CAD SVG/BOM & STL generator. - Trust score: 64/100 (medium) - Change this week: +3 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-11-05 ## Components - remote · `mcp.rackarchitect.dev`: 70/100, [markdown](https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp.md), [page](https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp) - remote · `mcp.rackarchitect.dev`: 64/100 (this document), [markdown](https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp-2.md), [page](https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp-2) - mcpb · `rack-architect-mcp.mcpb`: 6/100, [markdown](https://verifymcp.io/servers/italex240-rack-architect-mcp/rack-architect-mcp.md), [page](https://verifymcp.io/servers/italex240-rack-architect-mcp/rack-architect-mcp) ## Channel facts - Endpoint: `https://mcp.rackarchitect.dev/sse` - Transports: `sse` - Auth: `none` - Version: `0.7.8` ## Trust breakdown 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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-11-05. - **Endpoint Security**: 63/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (init_rack). - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 40/100 - Verified sse transport via a live MCP handshake. - **Schema Quality & AI Usability**: 77/100 - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name). - AI-judged instruction clarity (excellent). - 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. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 23/100 - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - Structured output schemas are declared (100% of tools); any adoption earns full credit. - **Tool Safety**: 100/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation. - An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### How do I install the RackArchitect MCP server? RackArchitect MCP is a hosted endpoint at https://mcp.rackarchitect.dev/sse, 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. ### Claude ```bash claude mcp add --transport http italex240-rack-architect-mcp 'https://mcp.rackarchitect.dev/sse' ``` ### Cursor ```json { "mcpServers": { "italex240-rack-architect-mcp": { "url": "https://mcp.rackarchitect.dev/sse" } } } ``` ### VS Code ```json { "servers": { "italex240-rack-architect-mcp": { "type": "http", "url": "https://mcp.rackarchitect.dev/sse" } } } ``` ### Codex ```toml [mcp_servers.italex240-rack-architect-mcp] url = "https://mcp.rackarchitect.dev/sse" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "italex240-rack-architect-mcp": { "type": "remote", "url": "https://mcp.rackarchitect.dev/sse", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add italex240-rack-architect-mcp --url 'https://mcp.rackarchitect.dev/sse' --transport streamable-http ``` ### Hermes ```yaml mcp_servers: italex240-rack-architect-mcp: url: "https://mcp.rackarchitect.dev/sse" ``` ### Netclaw ```json { "McpServers": { "italex240-rack-architect-mcp": { "Transport": "http", "Url": "https://mcp.rackarchitect.dev/sse" } } } ``` ### Vellum ```bash assistant mcp add italex240-rack-architect-mcp -t streamable-http -u 'https://mcp.rackarchitect.dev/sse' ``` ### Other ```json { "mcpServers": { "italex240-rack-architect-mcp": { "type": "http", "url": "https://mcp.rackarchitect.dev/sse" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-11-04 (score 64, +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. ### 2026-11-03 (score 63, 0) - [security] Tool “export_deliverables” rewrote its description, which is the text the model reads - [security] Tool “export_deliverables” is now declared destructive - [functional] Server version: 0.7.7 → 0.7.8 - [functional] Server version: 0.7.6 → 0.7.7 ### 2026-11-02 (score 63, +1) - [functional] Server version: 0.7.5 → 0.7.6 ### 2026-10-31 (score 62, +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. ### 2026-10-30 (score 61, 0) - [security] Tool “connect_cables” rewrote its description, which is the text the model reads - [security] 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 “define_custom_blueprint” 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 “export_deliverables” 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 “init_rack” 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 “mount_equipment” rewrote its description, which is the text the model reads - [functional improvement] Stability: unverified → 0.03 - [functional] Server version: 0.7.4 → 0.7.5 ### 2026-10-29 (score 61) First indexed and scored. ## MCP tools (12) ### `search_catalog` (~446 tokens) Search Hardware Blueprint Catalog 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. Input parameters: - `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). Output parameters: - `data` (object): Catalog search result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `get_device_blueprint` (~186 tokens) Retrieve Hardware Device Blueprint Details 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. Input parameters: - `slug` (string, required): Exact lowercase kebab-case hardware catalog blueprint slug to retrieve (discoverable via search_catalog). Output parameters: - `data` (object): Blueprint lookup result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `define_custom_blueprint` (~221 tokens) Register Custom Hardware Blueprint 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. Input parameters: - `blueprint` (object, required): Complete custom hardware blueprint specification; ports may be defined via explicit ports[], repeating port_groups[] macros, or both. Output parameters: - `data` (object): Custom blueprint registration payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `init_rack` (~393 tokens) Initialize and Reset Rack Enclosure 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. Input parameters: - `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, required): 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, required): Mechanical rack width standard ("19inch" = 482.6mm, "10inch" = 254.0mm, "6inch" = 152.4mm). - `u_height` (integer, required): Total usable vertical rack height in Rack Units (1U = 44.45mm, 1..60U). Output parameters: - `data` (object): Rack initialization payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `mount_equipment` (~404 tokens) Mount Equipment into Rack Unit or Carrier Slot 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. Input parameters: - `blueprint_slug` (string, required): 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, required): 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). Output parameters: - `data` (object): Equipment mounting result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `modify_equipment` (~503 tokens) Move, Rename, or Remove Mounted Equipment 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. Input parameters: - `action` (string, required): 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, required): 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). Output parameters: - `data` (object): Equipment modification result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `connect_cables` (~253 tokens) Connect and Route Inter-Device Cables 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. Input parameters: - `cables` (array, required): Batch of one or more cable connections to upsert by cable_id, route in 3D, and validate (max 128 per call). Output parameters: - `data` (object): Cable connection and 3D routing result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `disconnect_cables` (~260 tokens) Disconnect Cables by ID or Device Instance 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. Input parameters: - `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. Output parameters: - `data` (object): Cable disconnection result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `plan_external_endpoints` (~416 tokens) Terminate External Building Cable Drops on Patch Panel 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. Input parameters: - `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, required): 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). Output parameters: - `data` (object): External endpoint planning and auto-patching payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `validate_rack` (~135 tokens) Inspect and Validate Active Rack State 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. Output parameters: - `data` (object): Rack state inspection and validation result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `export_deliverables` (~297 tokens) Export 2D SVG, BOM, 3D GLB, and 3D-Print Deliverables 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 .scad or .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. Input parameters: - `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… Output parameters: - `data` (object): Deliverable export result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ### `undo_redo` (~186 tokens) Undo or Redo Rack State Mutation 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. Input parameters: - `action` (string, required): History traversal direction: "undo" reverts the most recent state mutation, "redo" reapplies a reverted mutation. Output parameters: - `data` (object): Undo/redo history traversal result payload. - `issues` (array): Structured diagnostic findings (ERROR, WARNING, INFO) with actionable remediation_suggestions. - `status` (string): 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): Concise human- and agent-readable summary of the tool result and validation status. ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp-2#diagnostics ## Score history - 2026-11-05: 64 - 2026-11-04: 64 - 2026-11-03: 63 - 2026-11-02: 63 - 2026-11-01: 62 - 2026-10-31: 62 - 2026-10-30: 61 - 2026-10-29: 61 ## Common questions ### 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/sse). ### Is the RackArchitect MCP server safe to use? RackArchitect MCP scores 64 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. ## Links - Remote endpoint: https://mcp.rackarchitect.dev/sse - Repository: https://github.com/itAlex240/rack-architect-mcp - Changelog RSS feed: https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp-2.xml - Changelog JSON feed: https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp-2.json - HTML version of this page: https://verifymcp.io/servers/italex240-rack-architect-mcp/mcp-2