Modify an existing topstitch style by renaming it, changing its thread color (RGB), or setting the number of parallel lines.
Rename a topstitch style, set its thread colour ([r, g, b] 0-255) or its number of parallel lines. For stitch length, thread thickness and offset use create_topstitch_style.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| color | No | ||
| style_index | Yes | ||
| number_of_lines | No |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It communicates that the tool edits an existing style and gives the color format, but it does not disclose what happens when optional/null parameters are omitted, whether an invalid style_index fails, or what side effects or return values to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the main operations, one parameter format, and a routing alternative with no filler. The core capabilities are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the supported attributes and color format, but leaves ambiguity about whether multiple fields are applied in one call, how null values behave, and what the tool returns. An agent can probably invoke it, but cannot fully predict its behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps name→rename, color→[r,g,b] 0-255, and number_of_lines→parallel lines, partially compensating for the 0% schema coverage. However, it never explains style_index itself, such as where the index comes from, and it does not clarify how null defaults are interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action on a specific resource: 'Rename a topstitch style, set its thread colour ... or its number of parallel lines.' It also explicitly differentiates its scope from create_topstitch_style by listing which attributes belong to that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use create_topstitch_style for stitch length, thread thickness, and offset, which removes ambiguity for those attributes. It does not spell out the inverse condition ('use this tool for name, color, or number_of_lines'), but that is reasonably clear from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.