Skip to main content
Glama
Mesteriis

Plasticity MCP

plasticity_plan_cohesive_layer_planes

Read-only

Plan ordered cohesive split planes and interface offsets from a slicer profile hash, layer height, build direction and first interface anchor for interface delamination analysis.

Instructions

Generate ordered cohesive split planes from the selected exact slicer profile hash, its layer height, the caller-supplied first interlayer plane anchor in current CAD millimeters, and a confirmed global print build direction. The profile hash, layer height, layer count, build direction and anchor are caller-supplied; this helper does not fetch or authenticate a Workbench job, read CAD placement, or prove the anchor lies on the Solid. For a completed Workbench slice, call workbench_slicer_interface_heights with every selected interfaceLayerIndex; copy each returned relativeOffsetMm into interfaceOffsetsMm in the same order. You may also pass the complete selected response metadata and interfaces as depositionPathEvidence; the planner checks job/profile/G-code hashes, selected layers, layer count and relative offsets, then preserves each road-direction summary in the analysis record as provenance. To receive candidate material frames for every deposited layer, call workbench_slicer_layer_path_orientations in batches of up to 32 and combine the selected results, including the final layer, as layerPathEvidence with matching job/profile/source/G-code hashes. For solver-mapped frames, retrieve complete coverage evidence (linear moves and XY G2/G3 circular arcs using I/J offsets or signed R radius; up to 256 layers), provide user-confirmed pathFrameMapping.slicerXDirectionGlobal, and explicitly confirm with roadAxisMapping that the exact-process coupon axis 1 represents the dominant deposited-road direction. P multi-turn arcs, malformed or mixed I/J-and-R arcs, non-XY arc planes, absolute I/J center mode, and G5/G5.1 splines or G5.2/G5.3 NURBS blocks remain partial and cannot qualify this solver mapping. The cohesive analysis additionally requires useOrthotropicBulkProperties and the measured single-material tensor. It then applies that one shared tensor with a per-layer local frame in both Mode-I and Turon; it does not create multiple materials or layer-varying property values. Without roadAxisMapping, returned frames remain candidates and do not affect solver input. The same measured, direction-independent cohesive law is repeated at each interface; individual roads, within-layer raster mixtures and direction-dependent adhesion are not modeled. Interface and per-layer evidence, when both supplied, must refer to the same job and artifacts. These relative offsets are in the slicer's build frame; map only their distances onto the confirmed CAD build axis, and do not assume that absolute slicer coordinates equal CAD coordinates. Before cohesive analysis, record both the immutable Workbench profile hash and its layerHeightMm in the measured interface-test process; the analysis rejects absent or mismatched layer heights. Exact plane intersections are checked only when meshing succeeds. A complete stack up to 255 interfaces is fully analyzed; larger stacks may select up to 255 explicitly chosen interfaces and are marked incomplete. Omitted interfaces are not analyzed and no full-stack delamination conclusion is valid. Pass the returned plan as layerPlanePlan and the returned planes as splitPlanes to plasticity_analyze_cohesive_interface; that tool checks the profile hash and layer height against the measured test record and, for orthotropic bulk, checks the direction against the exact coupon frame.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
layerHeightMmYes
roadAxisMappingNo
totalLayerCountYes
pathFrameMappingNo
layerPathEvidenceNo
interfaceOffsetsMmNo
processProfileHashYes
buildDirectionGlobalYes
firstInterfacePointMmYes
interfaceLayerIndicesYes
depositionPathEvidenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/destructive annotations, it discloses that the helper does not fetch/authenticate a Workbench job, does not read CAD placement, and does not prove the anchor lies on the Solid; that a single shared tensor is applied per-layer rather than layer-varying materials; that stacks >255 interfaces are marked incomplete; and that omitted interfaces are never analyzed. This is substantial behavioral context the annotations cannot convey.

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?

Front-loaded with purpose, and given the 11-param nested schema much of the content earns its place. However it is a single dense prose block with no sectioning, mixing purpose, prerequisites, evidence-gathering, and failure modes, which makes it harder to scan than the complexity alone requires.

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?

With no output schema, the description compensates by explaining that the returned plan (layerPlanePlan) and planes (splitPlanes) are consumed by plasticity_analyze_cohesive_interface and what that tool verifies. It covers prerequisites, evidence contracts, and limitations thoroughly; only the exact returned structure/limits remain implicit.

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%, so the description must carry the semantics, and it does explain most parameters: the role of profile hash/layer height/layer count/build direction/anchor, how interfaceOffsetsMm must be copied in order, and the meaning and requirements of depositionPathEvidence, layerPathEvidence, pathFrameMapping and roadAxisMapping. It stops short of documenting format/constraints for a few inputs (e.g. the strict build-direction vector, interfaceLayerIndices bounds), so it is strong but not exhaustive.

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 first sentence names a specific verb (Generate) and resource (ordered cohesive split planes) and enumerates the exact driving inputs (slicer profile hash, layer height, first interlayer plane anchor in CAD mm, build direction). It distinguishes itself from siblings by naming the downstream consumer plasticity_analyze_cohesive_interface and the upstream evidence tools, so an agent can place it in the workflow without opening any schema.

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?

It states explicitly when to call it (before cohesive analysis, with a Workbench slice), the prerequisites (record profile hash and layerHeightMm in the measured test first, same job/artifacts for combined evidence), and the alternative evidence paths (workbench_slicer_interface_heights for offsets, workbench_slicer_layer_path_orientations for frames). It also names what cannot qualify the solver mapping (P multi-turn arcs, G5 splines, etc.).

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

Deploy Server

Other Tools