Zhihuo RotoSpider Layout

Server Details

Rotomolding mold-on-arm layout feasibility: which molds fit on a machine arm/spider, and how.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 06:32
Transport: Streamable HTTP
URL

Available Tools

2 tools

check_mold_layoutA

Read-onlyIdempotent

Inspect

Check whether molds fit together on a rotational-molding machine arm.

    Every answer comes from the deterministic RotoSpider geometric layout
    engine: rotation-envelope and dead-height checks, pairwise mold-to-mold
    clearance, offset-arm riser selection, and ring arrangements for 3+
    identical molds. It never returns a physically invalid layout.

    Args:
        molds: List of mold objects. Use one explicit unit convention:
            Box/frame mold: {"length_mm": L, "width_mm": W, "height_mm": H}.
            Cylinder/tank mold: {"diameter_mm": D, "height_mm": H}.
            Exact L, slope, triangle, frustum, or complex mold: measured
            length_mm+width_mm+height_mm plus the complete
            geometry_asset_id+geometry_asset_revision returned by the
            geometry WebAPI or another trusted publisher.
            Decimal-inch aliases are length_in, width_in, height_in, and
            diameter_in. Each value is converted once to canonical
            micrometres; do not give both aliases for the same value.
            Optional per mold: "name", "weight_kg", "quantity" (default 1;
            use 0 to retain the mold type without requesting a copy).
        machine: Public-sample straight-arm preset. Available models are
            listed in the tool description. Leave empty AND give no
            explicit geometry to scan all presets ("which machine can take
            these molds?").
        arm_type: 'straight' (dual spiders) or 'offset' (single-spider
            offset/L arm). Empty = both.
        spider_diameter_mm: Custom machine - spider (mounting plate)
            diameter. Giving this plus envelope_diameter_mm switches to
            custom-machine mode instead of presets.
        envelope_diameter_mm: Custom machine - rotation envelope diameter
            (for offset arms: the vertical envelope diameter).
        dead_height_mm: Custom straight arm - unusable center height
            between the upper and lower spider surfaces.
        offset_spider_y_mm: Custom offset arm - spider Y offset from the
            spider center to the sphere center (required for custom offset).
        offset_horz_diameter_mm: Custom offset arm - horizontal usable
            envelope diameter after side trim (defaults to envelope).
        riser_heights_mm: Custom offset arm - available riser heights; the
            solver picks the best (or none).
        *_in: Decimal-inch aliases for the matching custom-arm and
            clearance *_mm arguments.
        max_load_weight_kg: Optional arm weight capacity; the solver loads
            molds only up to this total weight.
        clearance_target_mm: Target mold-to-mold clearance (default 300).
        clearance_min_mm: Minimum acceptable clearance (default 150).
        allow_overhang_within_envelope: Allow every mold shape to extend
            past the spider edge while its complete active shape remains
            inside the rotation envelope. Defaults to false.
        include_layout: Include request-relative mold placements. Use with
            response_api v1/v2/v3 to select the placement heading dialect.
        display_unit: 'mm' (default) or 'in'. Canonical result fields remain
            millimetres; 'in' adds a display projection rounded to 0.00001 in.
        response_api: Public placement dialect. Defaults to
            rotospider.layout-check.v1; request rotospider.layout-check.v2
            for exact four-heading orient keys when layouts are included.

    Returns a summary sentence plus per-arm results: feasible, placed vs
    requested counts (per mold type when available), selected riser height,
    spider utilization, center-of-gravity offset, achieved clearance, and
    the engine's reason when molds do not fit.

ParametersJSON Schema

Name	Required	Default
`molds`	Yes
`machine`	No
`arm_type`	No
`display_unit`	No	mm
`response_api`	No	rotospider.layout-check.v1
`dead_height_in`	No
`dead_height_mm`	No
`include_layout`	No
`clearance_min_in`	No
`clearance_min_mm`	No
`riser_heights_in`	No
`riser_heights_mm`	No
`max_load_weight_kg`	No
`offset_spider_y_in`	No
`offset_spider_y_mm`	No
`spider_diameter_in`	No
`spider_diameter_mm`	No
`clearance_target_in`	No
`clearance_target_mm`	No
`envelope_diameter_in`	No
`envelope_diameter_mm`	No
`offset_horz_diameter_in`	No
`offset_horz_diameter_mm`	No
`allow_overhang_within_envelope`	No

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint and idempotentHint already present, the bar is lower, yet the description adds substantial behavioral context: it is deterministic, never returns a physically invalid layout, converts inch values once to canonical micrometres, applies defaults such as clearance_target_mm=300 and allow_overhang_within_envelope=false, and explains result units. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but appropriately structured with a purpose statement, an Args section, and a Returns section. It is front-loaded with the core intent. A few sentences are redundant or unfulfilled, notably the claim that machine models are listed, but overall the length is justified for 24 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, no output schema, and minimal annotations, the description provides a thorough account of parameters, unit conventions, modes, and return values. It falls short of a 5 because the machine preset names are referenced but not enumerated, and the response_api v1/v2/v3 distinction is only partially explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates well by documenting mold object shapes, inch aliases, unit conversion rules, custom-machine mode switches, defaults, and response dialect options. However, the machine parameter says available preset models are listed in the tool description, yet no such list is actually present, leaving a real gap for that parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Check whether molds fit together on a rotational-molding machine arm.' It then names the concrete checks performed (rotation-envelope, dead-height, pairwise clearance, riser selection), which leaves no ambiguity about the tool's function. It is also clearly distinct from the only sibling, send_feedback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong usage context: when to scan all presets by leaving machine empty, when custom-machine mode is activated, and how arm_type and response_api affect behavior. It does not explicitly state 'when not to use' or name alternative layout tools, and it claims available machine models are listed but never actually lists them, which is a small guidance gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_feedbackAInspect

Relay a user question, bug report, or suggestion to the maintainers.

    Args:
        message: The user's feedback text (required).
        contact: Optional reply address the user volunteers.

ParametersJSON Schema

Name	Required	Description	Default
`contact`	No
`message`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate non-readonly, and description confirms it relays feedback. No additional behavioral context (e.g., auth, rate limits) provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus Args list, efficient and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with two parameters; description covers their purpose adequately. No output schema, but return value is not critical for this action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; description adds meaning for both parameters, explaining message is required and contact is optional reply address.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'relay' and resource 'feedback to maintainers', distinguishing it from the sibling 'check_mold_layout'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists when to use (user question, bug report, suggestion) but lacks when-not-to-use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updateAug 13, 2026
- Changedcheck_mold_layout1 field changed
  - addedInput schema / properties / include_layout
```
Added value: +{
+  "default": false,
+  "title": "Include Layout",
+  "type": "boolean"
+}
```
1 tool updateAug 13, 2026
- Changedcheck_mold_layout1 field changed
  - addedInput schema / properties / allow_overhang_within_envelope
```
Added value: +{
+  "default": false,
+  "title": "Allow Overhang Within Envelope",
+  "type": "boolean"
+}
```

1 tool updateAug 13, 2026

Changedcheck_mold_layout1 field changed

addedInput schema / properties / response_api

Added value: +{
+  "default": "rotospider.layout-check.v1",
+  "title": "Response Api",
+  "type": "string"
+}

1 tool updateJul 30, 2026

Changedcheck_mold_layout31 fields changed

addedInput schema / properties / clearance_min_in

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Clearance Min In"
+}

addedInput schema / properties / clearance_min_mm / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / clearance_min_mm / default
```
Previous value: -150New value: +null
```
removedInput schema / properties / clearance_min_mm / type
```
Removed value: -"integer"
```

addedInput schema / properties / clearance_target_in

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Clearance Target In"
+}

addedInput schema / properties / clearance_target_mm / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / clearance_target_mm / default
```
Previous value: -300New value: +null
```
removedInput schema / properties / clearance_target_mm / type
```
Removed value: -"integer"
```

addedInput schema / properties / dead_height_in

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dead Height In"
+}

addedInput schema / properties / dead_height_mm / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / dead_height_mm / default
```
Previous value: -0New value: +null
```
removedInput schema / properties / dead_height_mm / type
```
Removed value: -"integer"
```

addedInput schema / properties / display_unit

Added value: +{
+  "default": "mm",
+  "title": "Display Unit",
+  "type": "string"
+}

addedInput schema / properties / envelope_diameter_in

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Envelope Diameter In"
+}

addedInput schema / properties / envelope_diameter_mm / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / envelope_diameter_mm / default
```
Previous value: -0New value: +null
```
removedInput schema / properties / envelope_diameter_mm / type
```
Removed value: -"integer"
```

addedInput schema / properties / offset_horz_diameter_in

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Offset Horz Diameter In"
+}

addedInput schema / properties / offset_horz_diameter_mm / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / offset_horz_diameter_mm / default
```
Previous value: -0New value: +null
```
removedInput schema / properties / offset_horz_diameter_mm / type
```
Removed value: -"integer"
```

addedInput schema / properties / offset_spider_y_in

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Offset Spider Y In"
+}

addedInput schema / properties / offset_spider_y_mm / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / offset_spider_y_mm / default
```
Previous value: -0New value: +null
```
removedInput schema / properties / offset_spider_y_mm / type
```
Removed value: -"integer"
```

addedInput schema / properties / riser_heights_in

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Riser Heights In"
+}

changedInput schema / properties / riser_heights_mm / anyOf

Previous value: -[
-  {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "type": "number"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / spider_diameter_in

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Spider Diameter In"
+}

addedInput schema / properties / spider_diameter_mm / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / spider_diameter_mm / default
```
Previous value: -0New value: +null
```
removedInput schema / properties / spider_diameter_mm / type
```
Removed value: -"integer"
```

2 tool updatesJul 12, 2026
- First observedcheck_mold_layout
- First observedsend_feedback

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

3DPACK.ING — Truck Load Planning A
ing.3dpack
Truck & trailer load planning from a plain-English shipment: what fits, how full, 3D load plan.
11
OpenFab A
io.github.yyphilo
Instant parametric cost estimates for custom manufacturing: CNC, molding, sheet metal, 3DP, PCB.
Developer Tools
72
container-loading A
io.github.lxxmng
Plan optimal container & truck loads: 3D layouts, utilization, centre of gravity, crush checks.
Travel & Transportation
62
FEA (finite element analysis)
io.github.TheRoboMaster123
Real FEA on CAD parts: validated setups, stress, safety factor, natural frequencies
Research & Data
12

Related MCP Servers

loadingmcp-mcp
E-commerce & Retail
lxxmng
A
license
Not graded
quality
C
maintenance
Plan optimal container & truck loads: 3D layouts, right-size the container mix, and check utilization, centre of gravity, crush protection and securing across 200+ equipment types.
Updated 2 months ago (2026-07-13 20:05 UTC)
16
MIT
pyFit
Design Tools
badass-data-science
A
license
Not graded
quality
C
maintenance
Enables 2D irregular polygon nesting (bin-packing) with tools to design, preview, get reports, and export DXF files for laser cutting or CNC routing.
Updated a month ago (2026-07-29 15:56 UTC)
MIT
foundry net-industrial
Blockchain Autonomous Agents AI & Machine Learning
FoundryNet
F
license
A
quality
A
maintenance
Cross-OEM industrial machine intelligence. Normalizes telemetry across 16 manufacturer families (Fanuc, Siemens, Haas, DMG Mori, Mazak), enables plain-English operational automation, and produces tamper-evident work records. 14 MCP tools.
Updated a month ago (2026-08-11 06:22 UTC)
14
-
SmartCutofficial
Developer Tools
jgmedialtd
F
license
Not graded
quality
B
maintenance
SmartCut is a hosted cutting-optimisation API. It turns a list of parts and available stock into machine-ready cutting patterns for sheet materials (plywood, MDF, glass, plastic, sheet metal), linear stock (timber, bar, pipe, extrusion) and roll goods. Guillotine and true-shape nesting modes, with grain direction, per-part orientation locks, edge banding, blade kerf and stock trim.
Updated 4 days ago (2026-09-02 14:59 UTC)
1
-

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

The two tools occupy completely different roles: one performs geometric layout checks, the other collects user feedback. There is no overlap or boundary ambiguity, so an agent cannot confuse which tool to call.

Naming Consistency5/5

Both tool names follow a verb_noun snake_case pattern with clear imperative verbs and specific object nouns: check_mold_layout and send_feedback. The naming convention is consistent, predictable, and readable.

Tool Count3/5

Two tools is on the low end, and only one is domain-specific; the feedback tool is auxiliary. The single layout engine is rich enough to cover many cases, but the overall surface feels thin for a server with a broader RotoSpider ecosystem.

Completeness5/5

For a stateless geometric layout checker, the core tool covers preset machines, custom machines, arm types, risers, clearances, weight limits, and layout responses. There are no obvious missing lifecycle operations because layout checking is a calculation rather than a CRUD resource.

Resources

Need Help?

Server Details

Available Tools

TDQS

TDQS

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

loadingmcp-mcp

pyFit

foundry net-industrial

SmartCutofficial

Glama MCP Gateway

TDQS

Resources