Skip to main content
Glama
genart-dev

genart-mcp

by genart-dev

merge_sketches

Combine parameters, colors, and algorithms from two or more source sketches into a new sketch, choosing blend, layer, or alternate merge strategies.

Instructions

Combine parameters, colors, and algorithm from 2+ source sketches into a new sketch

Input Schema

NameRequiredDescriptionDefault
newIdYesURL-safe kebab-case ID for the merged sketch
titleYesTitle for the merged sketch
canvasNoCanvas size (default: largest source dimensions)
rendererNoRenderer for merged sketch (default: first source's renderer)
strategyNoMerge strategy (default: blend)
sourceIdsYesIDs of 2+ source sketches to merge

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It reveals that parameters, colors, and algorithm are pulled from sources, but never says whether source sketches are modified or preserved, what happens on conflict, or that a new sketch is created rather than overwriting anything. For an unannotated mutation tool this is a significant gap.

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?

A single front-loaded sentence with no filler. It is efficient but thin rather than padded, so it scores well on structure while leaving room for more substance.

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?

With 6 parameters, a nested canvas object, two enums, and no output schema, the schema documents the inputs well. What is missing is the contract around results and side effects: whether a sketch handle or ID is returned, whether sources persist, and how the merge strategies differ behaviorally.

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 description coverage is 100%, including defaults and enum values for strategy and renderer, so the schema does the heavy lifting. The description adds no parameter-level detail such as how sourceIds ordering affects strategy or how the first source's renderer becomes the default.

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 specific verb and resource ('Combine ... into a new sketch') plus what is carried over (parameters, colors, algorithm). It does not differentiate from the nearest sibling fork_sketch, which also produces a derived sketch, so an agent must infer the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use merge_sketches rather than fork_sketch, create_sketch, or compare_sketches, and no stated preconditions. The '2+ source sketches' constraint is the only usage hint, and it is embedded rather than framed as guidance.

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