Chorono

by codie1982

Overview Schema Source Related Servers Discussions Admin

array_layer

Duplicate a layer into linear, grid, radial, or path patterns using custom spacing, counts, angles, and copy or instance modes for animation layout.

Instructions

Lay out copies of a layer in a pattern: "linear" (row/column via moveX/moveY), "grid" (columns×rows), "radial" (count around a circle: radius + angles), or "path" (distribute along a path layer). count includes the source. cloneMode copy|instance.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "layerId": "<layerId>",
      "pattern": "<pattern>"
    },
    "name": "array_layer"
  }
}

Input Schema

Name	Required	Description
`rows`	No	Grid: row count
`count`	No	Total objects incl. source (linear/radial/path)
`moveX`	No	Linear: x step per copy
`moveY`	No	Linear: y step per copy
`closed`	No	Radial: distribute evenly around full circle
`radius`	No	Radial: ring radius
`scaleX`	No	Linear: scaleX step (multiplicative)
`scaleY`	No	Linear: scaleY step
`centerX`	No	Radial: center x
`centerY`	No	Radial: center y
`columns`	No	Grid: column count
`layerId`	Yes	Source layer id
`pattern`	Yes	Array layout
`reverse`	No	Path: distribute in reverse
`rowMoveX`	No	Grid: x step between rows
`rowMoveY`	No	Grid: y step between rows
`cloneMode`	No	copy or instance
`endOffset`	No	Path: skip arc-length at end
`requestId`	No
`sessionId`	No
`columnMoveX`	No	Grid: x step between columns
`columnMoveY`	No	Grid: y step between columns
`pathLayerId`	No	Path: id of the path layer to follow
`rotationDeg`	No	Linear: rotation step per copy (deg)
`startOffset`	No	Path: skip arc-length at start
`orientToAngle`	No	Radial: rotate each to face outward
`startAngleDeg`	No	Radial: start angle (deg)
`totalAngleDeg`	No	Radial: total arc span (deg)
`alignToTangent`	No	Path: rotate to path tangent
`expectedRevision`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare a mutation (readOnlyHint=false) in a closed world, so the safety burden is partly lifted. The description adds genuinely useful behavior ('count includes the source') but leaves open what copy vs instance actually means, whether the source layer is modified in place, and how expectedRevision conflicts are handled.

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?

Two tight sentences, front-loaded with the core action and then the mode breakdown, with no filler. The telegraphic style ('count includes the source. cloneMode copy|instance.') is efficient but slightly clipped, and the copy-vs-instance note is dropped without explanation.

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?

For a 30-parameter mutation tool with no output schema, the definition covers the pattern taxonomy and the count convention but says nothing about return values (new layer ids?), copy vs instance lifecycle, or concurrency via expectedRevision. It is workable for common cases but leaves meaningful gaps at this complexity.

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 90%, so the baseline is 3; the description earns a step up by grouping parameters under the pattern that consumes them (moveX/moveY for linear, columns×rows for grid, radius + angles for radial, path layer for path), which the flat schema does not express. It stops short of explaining cloneMode semantics or the requestId/sessionId/expectedRevision plumbing.

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 verb 'Lay out copies of a layer' plus an explicit enumeration of the four patterns (linear, grid, radial, path) makes the operation unmistakable. It does not, however, contrast itself with the sibling clone_layer, which is the closest source of confusion when an agent is choosing a duplication tool.

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 only implied by the pattern list; there is no statement of when to prefer array_layer over clone_layer, add_path, or assign_motion_path, nor any prerequisites such as needing a valid path layer for 'path' mode. An agent can infer intent from the pattern names but must guess at boundaries with siblings.

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

Deploy Server