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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-20 02:15
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-10-19 22:50 across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one performs deterministic mold layout validation and the other relays user feedback to maintainers. There is no plausible scenario where an agent would confuse check_mold_layout with send_feedback.

Naming Consistency5/5

Both names follow a consistent verb_noun snake_case pattern (check_mold_layout, send_feedback) with clear, domain-appropriate verbs. No mixing of conventions or casing styles.

Tool Count3/5

Only two tools are exposed, and one of them (send_feedback) is ancillary rather than a core domain operation, leaving effectively a single functional tool. The layout checker is deeply parameterized, which mitigates the thinness, but the surface is still borderline minimal.

Completeness4/5

The single functional tool covers the full layout-checking lifecycle: feasibility, clearances, riser selection, custom and preset machines, unit handling, and detailed failure reasons. Minor gaps exist around discovering machine presets programmatically and retrieving or persisting prior layout results, but these are workable.

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, each
            with its heading in milli-degrees (angleMilliDeg).
        display_unit: 'mm' (default) or 'in'. Canonical result fields remain
            millimetres; 'in' adds a display projection rounded to 0.00001 in.
        response_api: The answer's version, rotospider.layout-check.v3,
            the default and the only version.

    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.v3
`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.6/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It goes beyond by explaining the deterministic nature ('never returns a physically invalid layout') and the engine's behavior, such as unit conversion and the distinction between canonical and display units. It does not mention all edge cases (e.g., error handling), but the annotations cover the read-only aspect.

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

Conciseness3/5

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

The description is comprehensive but becomes lengthy due to the detailed parameter list. It is well-structured with a clear intro, an Args section, and a Returns section, which aids navigation. However, it could be tightened by moving some parameter details into a linked reference, but the current structure is acceptable for a complex tool.

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

Completeness5/5

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

Given the tool's complexity (24 parameters, no output schema, no nested objects), the description covers all necessary information: input formats, unit handling, behavior, and return content. It even specifies the exact response API version. No critical gaps noted; the description compensates for the lack of an output schema and the bare parameter names.

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

Parameters5/5

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

Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains each parameter in detail, including unit aliases, defaults, and conditions for custom mode. It even clarifies the use of quantity=0 and the conversion to micrometres, which is invaluable when the schema only lists names.

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 clearly states that the tool checks whether molds fit together on a rotational-molding machine arm, and details the specific deterministic engine and checks performed. It distinguishes itself from any sibling by focusing on layout feasibility, and the title reinforces this.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use the tool, such as leaving machine empty to scan all presets, and also gives instructions on how to provide molds. It implies alternatives indirectly (e.g., scanning presets) and clearly states the conditions for custom mode. Although no alternative tool is named, the usage context is thorough.

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.

2 tool updatesOct 19, 2026
- First observedcheck_mold_layout
- First observedsend_feedback

Related MCP Connectors

Zhihuo RotoSpider Layout A
net.zhihuo.mcp
Rotomolding mold-on-arm layout feasibility: which molds fit on a machine arm/spider, and how.
Data Visualization
22
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
RFQdecoder A
io.github.Mounirt879
Should-cost of a machined, sheet metal or cast part from its PDF, DXF or STEP drawing, line by line.
Design Tools Finance
71

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 15 days ago (2026-10-04 22:13 UTC)
9 npm
MIT
pyFit
Design Tools
badass-data-science
A
license
Not graded
quality
B
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 3 months 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 3 days ago (2026-10-17 01:16 UTC)
14
-
MakerSimofficial
Data Visualization Knowledge & Memory
RawLabs
A
license
Not graded
quality
B
maintenance
Experimental load-path analysis for 3D-printed STL parts, with stress and movement comparisons across CAD revisions, PNG captures, visual reviews, and persistent human-guided design sessions. Runs locally through a stdio MCP server.
Updated 2 days ago (2026-10-17 20:01 UTC)
MIT