Skip to main content
Glama
Mesteriis

Plasticity MCP

plasticity_radial_face_pattern

Destructive

Repeat a connected face set around a world-space axis to create a native radial array on a Solid or Sheet. Re-read topology and validate that the faces form a repeatable feature.

Instructions

Repeat one exact connected feature-face set on the same Solid or Sheet around a world-space axis in a native radial array. Count includes the source feature and sweep is in degrees. Re-read all topology and validate the result because Plasticity must recognize the selected faces as a repeatable feature.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
axisYes
countYes
facesYes
intentNo
centerMmYes
revisionYes
sweepDegreesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations declare the destructive/write profile, and the description adds real value beyond them: 'Count includes the source feature', 'sweep is in degrees', and the operational warning that Plasticity must recognize the faces as a repeatable feature and that topology must be re-read and validated. It does not explain failure/rollback behavior, keeping it from a 5.

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?

Three tight sentences, front-loaded with the operation and scope, then the counting/units clarification, then the validation requirement. No filler.

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?

For a destructive 7-parameter tool with 0% schema coverage and no output schema, the description covers the critical semantics (count, sweep units, face-set requirement, topology re-read) but leaves centerMm, revision, and intent undefined, which an agent could mis-set.

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

Parameters3/5

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

Schema description coverage is 0%, so the description carries the burden and does partially compensate: it clarifies count (inclusive of source, min 2 implied), sweepDegrees (degrees), faces (connected feature-face set), and axis (world-space). It says nothing about centerMm, revision, or intent.

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?

States a specific verb+resource+scope: 'Repeat one exact connected feature-face set ... around a world-space axis in a native radial array'. This distinguishes it from plasticity_radial_pattern (body-level) and plasticity_rectangular_face_pattern by naming the face-set input and the radial axis.

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

Usage Guidelines3/5

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

Usage is implied by the description (this is the radial-array version operating on face sets), but it never names an alternative or states when-not-to-use it versus plasticity_radial_pattern or plasticity_rectangular_face_pattern. No prerequisites for face selection are given beyond the closing warning.

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