Skip to main content
Glama
tbrito88
by tbrito88

Convert to Sheet Metal

convert_to_sheet_metal

Convert a uniform-thickness solid body into sheet metal when Fusion API lacks flange creation. Model shape with extrude/shell, then apply this tool.

Instructions

Convert a solid body of uniform thickness into sheet metal. Thickness is taken from the geometry, not from the rule. This replaces flange creation, which the Fusion API does not expose: model the shape with extrude/shell, then convert.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
body_nameYes
rule_nameNoSheet metal rule. Default: first available
face_indexNoBase face. Default: largest planar face

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Discloses a non-obvious behavioral trait beyond the annotations: thickness is taken from the geometry, not from the rule. This corrects the natural assumption that rule_name governs thickness. Annotations only cover read/write and idempotency hints, so this added context is genuinely valuable.

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 core action and followed by the two facts an agent actually needs (thickness source, alternative workflow). 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 3-parameter mutation tool with no output schema, the description covers purpose, workflow prerequisite, and the key thickness behavior. It does not state what happens to the original solid body or what the call returns, a minor gap given the annotations cover safety hints.

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 coverage is 67% with rule_name ('Default: first available') and face_index ('Default: largest planar face') already documented in the schema; body_name is undocumented. The description clarifies that thickness does not come from the rule, adding meaning to rule_name, but does not otherwise expand parameter semantics.

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

Purpose4/5

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

States a precise verb and resource: 'Convert a solid body of uniform thickness into sheet metal,' including the precondition (uniform thickness) that qualifies which bodies are eligible. It does not explicitly differentiate from the closest sibling fold_sheet_metal, so it falls short of 5.

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?

Gives strong context: it replaces flange creation because the Fusion API doesn't expose it, and prescribes the workflow ('model the shape with extrude/shell, then convert'). No explicit exclusions or named alternatives among siblings, so 4 rather than 5.

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