Skip to main content
Glama
ttiimmaacc

mcp-for-clo3d

by ttiimmaacc

create_topstitch_style

Creates a topstitch style with custom stitch length, thread thickness, and offset by copying a saved template and importing it, working around CLO API limits.

Instructions

Create a topstitch style with a given stitch length, thread thickness and offset from the stitched line (CLO's API cannot set these on a style, so a saved style file is copied with the values changed and imported). Returns its style_index for add_topstitch.

The stitch's shape and colour come from a template: a style saved from CLO once (select a topstitch in the Object Browser, set its Shape, e.g. Overlock, and colour in the Property Editor, click the save icon in its Topstitch row) and passed as template_path with a template name; later calls just name the template.

Args: name: Name for the new style. stitch_length_mm: Length of each stitch in mm (default: the template's). thread_thickness_mm: Thread thickness in mm (CLO shows it as Tex: 0.2 mm = 40 Tex). offset_mm: Distance of the stitching from the line or seam it follows, in mm. template: Which saved template to use, e.g. "default" or "overlock". template_path: A .sst saved from CLO, stored as this template (first time only).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
templateNodefault
offset_mmNo
template_pathNo
stitch_length_mmNo
thread_thickness_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.1
    • addedInput schema / properties / template
      Added value: +{
      +  "default": "default",
      +  "title": "Template",
      +  "type": "string"
      +}
  2. First observedv0.5.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the underlying implementation (copies a saved style file with values changed and imports it), the required template workflow, and the return value (style_index). It stops short of stating permissions, error behavior, or what happens if a template name is reused or an existing style is overwritten.

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?

Front-loads purpose and the return value, then the template explanation, then per-arg docs. The template paragraph is somewhat long but earns its place because the workaround is non-obvious. Minor formatting noise (line breaks, trailing blank) keeps it from a 5.

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?

No output schema and no annotations exist, so the description must stand alone; it covers the purpose, the non-obvious file-copy mechanism, the template prerequisite, and the returned style_index. For a 6-parameter tool this is complete enough for an agent to invoke correctly.

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 must compensate fully and does: it documents all six parameters, including the Tex conversion for thread_thickness_mm, the offset meaning relative to the stitched line, defaults inherited from the template, and the first-time-only nature of template_path. This adds substantial meaning beyond the bare schema titles.

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 ('Create a topstitch style') and enumerates the three defining attributes (stitch length, thread thickness, offset). It also ties itself into the workflow by explaining it returns a style_index for add_topstitch, distinguishing it from get_topstitch_style/list_topstitch_styles/set_topstitch_style siblings.

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 clear context for when this is needed (CLO's API cannot set these values on a style, so a template file must be copied and imported) and explains the one-time template setup. However, it never states when NOT to use it or names alternatives such as set_topstitch_style for modifying an existing style or list_topstitch_styles for discovering available ones.

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