Skip to content

RackArchitect MCP

io.github.itAlex240/rack-architect-mcpitAlex240streamable-httpv0.7.1Scanned

Hosted Remote MCP & 3D/2D Rack-as-Code planner, 5-stage validator, CAD SVG/BOM & STL generator.

12 tools: 4 can delete or cancel things, 5 change things and 3 only read.

Tools: 4 delete, 0 irreversible, 5 write, 3 read.
  • Reads private data · 0
  • Reads text others write · 0
  • Can send data out · 0
  • 1 finding

Anlyon alternative

9 of these tools change something. Run those as governed actions.

Declare what an action changes, and Anlyon puts it under a shared limit, binds every approval to the exact request, and grades the outcome. It works on any HTTPS API you can describe as an action.

Anlyon does not run, proxy or govern this MCP server. A tool your own code calls directly is not routed through Anlyon and is not governed by it.

Import an OpenAPI spec →

Tools

Grouped by what each tool does, most consequential first. Open one for its reasons and full description; descriptions are the publisher's own words.

12 tools

Deletes or cancels 4Claude Code: deny
  • disconnect_cablesRemove specific cables by cable_id or strip all cables attached to a mounted device or carrier instance_id from the active rack, then re-evaluate PoE/power budgets and plug clearan…No findings

    Why it is in this group

    • The description's first verb is "remove": a word for removing or ending something.
    • The server marks it destructive (destructiveHint: true).
    Description, as the server wrote it
    Remove specific cables by cable_id or strip all cables attached to a mounted device or carrier instance_id from the active rack, then re-evaluate PoE/power budgets and plug clearances. Supply cable_ids, instance_id, or both (their union is disconnected, and targeting a modular-carrier also disconnects cables attached to its child sub-modules); calling with neither parameter is rejected with status 'INVALID' without mutating state. Pushes the prior state onto the undo stack, updates rack.yaml atomically, and is idempotent if the targeted cables are already absent. Use when rewiring ports or relieving PoE/port conflicts while keeping devices mounted; to add or replace cables, use connect_cables instead, and to remove the device itself along with its cables, use modify_equipment with action 'remove'.

    Annotations the server declares

    • title: Disconnect Cables by ID or Device Instance
    • readOnlyHint: false
    • destructiveHint: true
    • idempotentHint: true
    • openWorldHint: false
  • init_rackInitialize a new rack project and destructively reset the active rack.yaml state to an empty enclosure with the specified mechanical width standard, usable U height, and rail depth…No findings

    Why it is in this group

    • The name "init_rack" says "init": a word for a change.
    • The server marks it destructive (destructiveHint: true).
    Description, as the server wrote it
    Initialize a new rack project and destructively reset the active rack.yaml state to an empty enclosure with the specified mechanical width standard, usable U height, and rail depth. Overwrites the current rack configuration and clears all previously mounted devices, child sub-modules, cables, and external endpoints, while pushing the prior project state onto the in-memory undo stack (recoverable via undo_redo). Front door clearance checks apply when enclosure_type has a closed front door, and rail_depth_mm defines the front-to-rear Z mounting span (1U = 44.45mm). Use when starting a new rack design from scratch or changing enclosure dimensions; do not use to inspect the current rack (use validate_rack) or to relocate/remove individual devices in an existing layout (use modify_equipment).

    Annotations the server declares

    • title: Initialize and Reset Rack Enclosure
    • readOnlyHint: false
    • destructiveHint: true
    • idempotentHint: true
    • openWorldHint: false
  • modify_equipmentMove, rename, or destructively remove an existing mounted device or sub-module instance in the active rack, recalculate all 3D cable splines, and re-run 5-stage validation.No findings

    Why it is in this group

    • The name "modify_equipment" says "modify": a word for a change.
    • The server marks it destructive (destructiveHint: true).
    Description, as the server wrote it
    Move, rename, or destructively remove an existing mounted device or sub-module instance in the active rack, recalculate all 3D cable splines, and re-run 5-stage validation. Parameter requirements depend on action: 'move' uses u_position/face (or aliases new_u_position/new_face, where primary fields take precedence) for rackmount devices or parent_carrier_id/slot_id for sub-modules; 'rename' uses hostname (or alias new_hostname); 'remove' deletes the target instance (plus any child sub-modules if it is a carrier, and all attached cables and external endpoints when remove_connected_cables is true). Pushes the prior state onto the undo stack and persists the updated rack.yaml atomically, or rejects unknown instance_id values without mutating state. Use to update or delete an already mounted device; to mount a new device instance, use mount_equipment instead, and to remove cables while keeping the device mounted, use disconnect_cables.

    Annotations the server declares

    • title: Move, Rename, or Remove Mounted Equipment
    • readOnlyHint: false
    • destructiveHint: true
    • idempotentHint: false
    • openWorldHint: false
  • plan_external_endpointsTerminate external building or room cable drops (such as PoE cameras, Wi-Fi APs, and wall LAN outlets) onto the rear ports of a mounted patch panel without consuming rack U slots, …No findings

    Why it is in this group

    • The description's first verb is "terminate": a word for removing or ending something.
    • The server marks it destructive (destructiveHint: true).
    Description, as the server wrote it
    Terminate external building or room cable drops (such as PoE cameras, Wi-Fi APs, and wall LAN outlets) onto the rear ports of a mounted patch panel without consuming rack U slots, and optionally auto-create labeled Cat6A front patch cables to a mounted switch. Use groups[] to batch-generate numbered drops sharing a category, PoE draw, and VLAN, or endpoints[] for individually named drops (both can be combined and allocate sequential free rear ports starting at start_port_number). When clear_existing is true, destructively removes existing external endpoints on patch_panel_instance_id and their front patch cables before allocating; rejects the call without mutating state if the target patch panel or switch is not mounted yet. Use for off-rack building wiring entering the enclosure; do not mount room endpoints as rack devices with mount_equipment, and use connect_cables for purely internal rack-to-rack connections.

    Annotations the server declares

    • title: Terminate External Building Cable Drops on Patch Panel
    • readOnlyHint: false
    • destructiveHint: true
    • idempotentHint: false
    • openWorldHint: false
Changes things 5Claude Code: ask
  • connect_cablesConnect or update a batch of power and network cables between mounted device ports in the active rack, computing 3D Catmull-Rom spline paths, commercial cable length bins, and PoE/…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Connect or update a batch of power and network cables between mounted device ports in the active rack, computing 3D Catmull-Rom spline paths, commercial cable length bins, and PoE/power DAG budgets. Each item in cables[] upserts by cable_id (replacing any existing cable with the same cable_id), pushes the prior state to the undo stack, and persists to rack.yaml; port, connector, speed, PoE budget, or plug-clearance violations are returned as status 'INVALID' with remediation_suggestions rather than throwing. Endpoint face ('front' or 'rear') is only required on pass-through couplers such as patch panels that expose the same port_id on both faces, and preferred_portal_u only applies when cables traverse between front and rear faces. Use when both endpoint devices are already mounted inside the rack; to remove cables, use disconnect_cables, and to terminate external building/room drops onto the rear of a patch panel, use plan_external_endpoints instead.

    Annotations the server declares

    • title: Connect and Route Inter-Device Cables
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • define_custom_blueprintValidate, register, and persist a custom hardware blueprint into the active catalog and local custom-catalog YAML directory so unlisted equipment can be mounted.1 finding

    Why it is in this group

    • The description's first verb is "validate": a word for reading.
    • The server marks it as not read-only (readOnlyHint: false).

    Findings

    • Warn

      The server marks "define_custom_blueprint" as not read-only (readOnlyHint: false), and its words say it reads.

      Matched text

      annotations: {"readOnlyHint":false,"destructiveHint":false,"idempotentHint":true,"openWorldHint":false}; The description's first verb is "validate": a word for reading.

      What this check looks for
    Description, as the server wrote it
    Validate, register, and persist a custom hardware blueprint into the active catalog and local custom-catalog YAML directory so unlisted equipment can be mounted. Expands any port_groups macros into flat ports[], verifies that all local port coordinates lie within chassis dimensions without overlapping, and overwrites any existing custom blueprint sharing the same slug while leaving mounted rack state and the undo stack untouched. Ports may be supplied via explicit ports[], repeating port_groups[], or both, and slots[] is only needed when mount_type is 'modular-carrier'. Use only when search_catalog confirms a device is missing from the catalog; to mount an already registered blueprint into the rack, use mount_equipment instead.

    Annotations the server declares

    • title: Register Custom Hardware Blueprint
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • export_deliverablesGenerate and write engineering deliverable files (2D elevation SVG, wiring schematic SVG, Markdown BOM, 3D GLB scene, and parametric OpenSCAD/STL 3D-print carrier models) for the a…No findings

    Why it is in this group

    • The description's first verb is "generate": a word for a change.
    Description, as the server wrote it
    Generate and write engineering deliverable files (2D elevation SVG, wiring schematic SVG, Markdown BOM, 3D GLB scene, and parametric OpenSCAD/STL 3D-print carrier models) for the active rack project to disk. Writes requested formats to output_dir (defaulting to the active rack.yaml directory) and overwrites any existing export files of the same name without mutating rack state or the undo stack; 'carrier-scad' and 'carrier-stl' emit files only when at least one modular-carrier is mounted in the rack. Returns the resolved output directory, written file paths and byte sizes, BOM power/cable totals, and current validation status. Use as the final step after validate_rack confirms a valid layout; for read-only validation and ASCII elevation inspection without writing files to disk, use validate_rack instead.

    Annotations the server declares

    • title: Export 2D SVG, BOM, 3D GLB, and 3D-Print Deliverables
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • mount_equipmentMount a new hardware device instance onto a rack unit or into a modular carrier slot in the active rack.yaml project and run 5-stage physical and electrical validation.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Mount a new hardware device instance onto a rack unit or into a modular carrier slot in the active rack.yaml project and run 5-stage physical and electrical validation. Supply u_position (and optional face) for direct rackmount equipment, or supply both parent_carrier_id and slot_id to place a sub-module inside an already mounted modular-carrier; the two targeting modes are mutually exclusive. Rejects duplicate instance_id values, unknown blueprint_slug values, or missing parent carriers without mutating state, whereas 3D depth/clearance or PoE issues still persist the mount, push the prior state to the undo stack, and return status 'INVALID' with remediation_suggestions. Use to add a new device instance to the rack; to move, rename, or remove an already mounted instance, use modify_equipment instead, and to terminate external room cable drops on a patch panel, use plan_external_endpoints.

    Annotations the server declares

    • title: Mount Equipment into Rack Unit or Carrier Slot
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: false
  • undo_redoTraverse the per-project in-memory mutation history (up to 50 snapshots) to revert the most recent rack state change ('undo') or reapply a previously reverted change ('redo'), atom…No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    Description, as the server wrote it
    Traverse the per-project in-memory mutation history (up to 50 snapshots) to revert the most recent rack state change ('undo') or reapply a previously reverted change ('redo'), atomically updating rack.yaml. Any new state-mutating tool call (init_rack, mount_equipment, modify_equipment, connect_cables, disconnect_cables, or plan_external_endpoints) clears the redo stack; calling undo or redo when the corresponding stack is empty is a safe no-op that returns applied=false without throwing. Use to roll back an unintended batch mutation or recover from an accidental init_rack reset; to modify or remove a specific device or cable without reverting intermediate steps, use modify_equipment or disconnect_cables instead.

    Annotations the server declares

    • title: Undo or Redo Rack State Mutation
    • readOnlyHint: false
    • destructiveHint: false
    • idempotentHint: false
    • openWorldHint: false
Only reads 3Show 3 read-only tools
  • get_device_blueprintRetrieve the complete hardware specification, millimeter port coordinates, electrical/PoE ratings, and carrier slot geometry for a single catalog blueprint by its exact lowercase k…No findings

    Why it is in this group

    • The name "get_device_blueprint" says "get": a word for reading.
    Description, as the server wrote it
    Retrieve the complete hardware specification, millimeter port coordinates, electrical/PoE ratings, and carrier slot geometry for a single catalog blueprint by its exact lowercase kebab-case slug. Repeating port_groups matrices in the blueprint are returned pre-expanded into flat ports[] entries; if the slug does not exist in the built-in or custom catalog, returns status 'INVALID' with a BLUEPRINT_NOT_FOUND issue and candidate slugs without throwing. Use when you already know the target slug and need exact port_id or slot_id values for mount_equipment or connect_cables; to discover unknown slugs by criteria, use search_catalog instead.

    Annotations the server declares

    • title: Retrieve Hardware Device Blueprint Details
    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • search_catalogSearch and filter the local hardware catalog to discover compatible rackmount devices, 3D-printed modular carriers, and sub-modules before mounting.No findings

    Why it is in this group

    • The name "search_catalog" says "search": a word for reading.
    Description, as the server wrote it
    Search and filter the local hardware catalog to discover compatible rackmount devices, 3D-printed modular carriers, and sub-modules before mounting. Call with no arguments to list all blueprints (unpaginated, no result cap), or combine multiple filters with logical AND; 'query' matches substrings case-insensitively across slug, manufacturer, and model, while 'form_factor' (or alias 'mount_type') shorthand values ('10inch', '19inch', '6inch') match both direct rackmount units and modular carriers of that width. To inspect full expanded port coordinates for a known slug, use get_device_blueprint instead; to register unlisted hardware, use define_custom_blueprint.

    Annotations the server declares

    • title: Search Hardware Blueprint Catalog
    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false
  • validate_rackInspect the active rack.yaml state and run all 5 deterministic validation stages (mechanical bounds, 3D front/rear depth and plug clearances, PoE/power budgets, cable port/speed co…No findings

    Why it is in this group

    • The name "validate_rack" says "validate": a word for reading.
    Description, as the server wrote it
    Inspect the active rack.yaml state and run all 5 deterministic validation stages (mechanical bounds, 3D front/rear depth and plug clearances, PoE/power budgets, cable port/speed compatibility, and thermal/center-of-gravity checks) without modifying state. Returns the current ASCII front/rear device elevation plan, power/PoE utilization summary, and all ERROR/WARNING/INFO issues with self-correction remediation_suggestions directly in the response payload (setting status to 'INVALID' when any ERROR exists, without throwing). Use to inspect currently mounted equipment or verify zero errors after mutations and before exporting; to write SVG, BOM, GLB, or 3D-print files to disk, use export_deliverables instead.

    Annotations the server declares

    • title: Inspect and Validate Active Rack State
    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: false

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Exfil surface

Which tools read private data, which read text someone else can write, and which can send data out. One of each is a path a prompt injection can use.

No private-data, untrusted-input, outbound path in this server alone: no tool is tagged private-data or untrusted-input or outbound.

Reads private data0
Reads files, mail, messages, databases, secrets, calendars or repositories.
Reads text others write0
Brings in text someone else can write: web pages, inbound email, messages, issues and comments.
Can send data out0
Can carry data to people or systems: it sends, posts or publishes, or takes a recipient, channel or URL.

Other servers in the same agent add their own tools to these paths. Audit your whole setup to see them together.

Findings

Matches of fixed checks, with the text they matched.

1 warn
  • The server marks "define_custom_blueprint" as not read-only (readOnlyHint: false), and its words say it reads.

    Matched text

    annotations: {"readOnlyHint":false,"destructiveHint":false,"idempotentHint":true,"openWorldHint":false}; The description's first verb is "validate": a word for reading.

    What this check looks for

History

Changes to its tool definitions and to its remote endpoint, newest first.

No change seen yet. Its tools are rescanned every day, and a remote endpoint is looked at once a week.

Install

Pinned to version 0.7.1. Values in angle brackets are yours to fill in.

claude mcp add --transport http rack-architect https://rack-mcp.167.233.80.33.sslip.io/mcp
claude mcp add --transport http rack-architect https://rack-mcp.167.233.80.33.sslip.io/mcp

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change or a way out, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__rack-architect__search_catalog",
      "mcp__rack-architect__get_device_blueprint",
      "mcp__rack-architect__validate_rack"
    ],
    "ask": [
      "mcp__rack-architect__define_custom_blueprint",
      "mcp__rack-architect__mount_equipment",
      "mcp__rack-architect__connect_cables",
      "mcp__rack-architect__export_deliverables",
      "mcp__rack-architect__undo_redo"
    ],
    "deny": [
      "mcp__rack-architect__init_rack",
      "mcp__rack-architect__modify_equipment",
      "mcp__rack-architect__disconnect_cables",
      "mcp__rack-architect__plan_external_endpoints"
    ]
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. A read that can send data out (it takes a URL, say) asks first too. It assumes the server is installed as rack-architect. Review it before you use it.

Pin

Keep the decision: fail CI when the tools change, follow every change, or show a badge.

Pin in CI

Fail a build when the tools you reviewed are not the tools the server serves today.

curl -s "https://anlyon.dev/api/v1/servers/io.github.itAlex240/rack-architect-mcp/verify?hash=379c2cfec606741c51331a9a0ebf74f7b0c22529259d0cedd8677ff6009cfb67" | jq -e '.changed == false'

Pinned hash 379c2cfec606, from Oct 29, 2026, 14:18 UTC.

Watch

Get told when its tools change: a new tool, a new description, a new class.

https://anlyon.dev/servers/io.github.itAlex240/rack-architect-mcp/changes.xml

An Atom feed. Works in any feed reader or Slack's RSS app.

Badge

anlyon.dev badge for io.github.itAlex240/rack-architect-mcp
[![anlyon.dev](https://anlyon.dev/badge/io.github.itAlex240/rack-architect-mcp.svg)](https://anlyon.dev/servers/io.github.itAlex240/rack-architect-mcp)

Source: MCP Registry · repository. Synced Oct 29, 2026, 14:17 UTC.