Serpentine3D MCP Server

Overview Schema Source Related Servers Discussions Admin

serp_layers

Create, rename, assign, hide, style, and delete 3D model layers, including nested layers and hatch/cut display settings, to organize objects and control viewport visibility.

Instructions

Manage layers. action: 'list', 'create', 'rename', 'visible', 'current', 'color' (color as [r,g,b] 0-1), 'assign' (move objects to layer), 'delete', 'style' (how a layer draws: style={linetype, print_width mm (0 = printer default), screen_width px or 'from print', hatch none/lines/cross/solid or a pattern loaded with the hatchpatterns command, hatch_angle degrees, hatch_spacing mm on paper, hatch_color ink/layer/#rrggbb, hatch_background none/layer/#rrggbb (what a cut shows under its hatch), cut_line_width mm on paper round a cut (0 = none), cut_line_color ink/layer/#rrggbb}). A layer can live under another: pass parent to 'create', and name a layer by its path ('Walls::Interior') where two layers share a name.

Input Schema

Name	Required	Default
`name`	No
`color`	No
`style`	No
`action`	No	list
`parent`	No
`objects`	No
`visible`	No
`new_name`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.12.0Oct 17, 2026

addedInput schema / properties / style

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Style"
+}

Changed1 schema field changedv0.8.3Sep 3, 2026
- addedInput schema / properties / parent
```
Added value: +{
+  "default": "",
+  "title": "Parent",
+  "type": "string"
+}
```
First observedv0.5.6Jul 31, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden, and it partially does: it discloses that layers can be nested via 'parent' and addressed by path, and it details the style/hatch units and defaults (0 = printer default, 'from print'). However, it says nothing about what 'delete' does to objects on the layer, whether operations are reversible, or what errors occur for a missing layer — significant gaps for a mutation tool with zero annotation coverage.

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?

The action enumeration is front-loaded and every sentence carries information the schema does not. The style clause is a dense parenthetical run-on that would read better as a list, but given 0% schema coverage the detail is justified rather than wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the nested-layer and path-addressing model is well covered. What is missing is the destructive-behavior contract for 'delete' and any indication of which parameters pair with which actions — material for an 8-parameter mutation tool with no annotations.

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 coverage is 0%, so the description must compensate, and it largely does: 'color' format is given as [r,g,b] 0-1, 'style' is broken down field-by-field with units and accepted values, 'parent' is explained, and path-based naming ('Walls::Interior') is clarified. 'objects', 'visible', and 'new_name' are only covered by implication through the 'assign', 'visible', and 'rename' action names, which is a minor remaining gap across 8 undocumented parameters.

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?

The description opens with a specific resource ('Manage layers') and immediately enumerates the exact operations via the action values, so an agent can map intent to a call. It is clearly distinct from siblings like serp_create_curve or serp_transform, though 'Manage' alone is generic and the enumeration does the identifying work.

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 through the action list rather than stated: an agent can infer 'list' is the default and that 'assign'/'delete' are the mutating paths, but there is no explicit when-to-use-this-vs-alternative guidance, no prerequisites (e.g. must a layer exist before 'assign'?), and no note on which actions require 'name'.

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

Deploy Server