Skip to main content
Glama
genart-dev

genart-mcp

by genart-dev

update_algorithm

Replaces a sketch's algorithm source code, optionally resolving new component dependencies, so you can revise generative art logic and then preview the result.

Instructions

Replace the algorithm source code of a sketch. If adding/changing components, pass them in the components field alongside the algorithm. After updating, use preview_sketch to open an interactive preview in the browser.

Algorithm data bridge: Algorithms can publish data for design layers by setting window.__genart_data properties:

  • Stroke paths: Set window.__genart_data.strokePaths = [{points:[{x,y},...], depth, width, pressure:[...], group}, ...]

  • Multiple channels: Publish separate arrays (e.g. strokePaths for all paths, leafPaths for depth-filtered subset)

  • Grid data: Set window.__genart_data.flowField/valueMap/mask as Float32Arrays for spatial algorithms Painting layers bind to these channels via pathSource: 'algorithm:'. Declare channels in the sketch's dataChannels field via update_sketch.

Input Schema

NameRequiredDescriptionDefault
agentNoYour CLI agent name (e.g. 'claude-code', 'codex-cli', 'gemini-cli', 'opencode', 'kiro')
modelNoYour AI model identifier (e.g. 'claude-opus-4-6', 'gpt-4o', 'gemini-2.5-pro')
sketchIdYesID of the sketch to update
validateNoRun renderer-specific validation before saving (default: true)
algorithmYesNew algorithm source code. State API by renderer: p5: `function sketch(p, state) { ... }` — state.canvas.width/height, state.seed, state.params.key, state.colorPalette[index]. Prefix all p5 calls with `p.` canvas2d: `function sketch(ctx, state) { ... }` — same state API as p5. three: `function sketch(THREE, state, container) { ... }` svg: `function sketch(state) { ... }` — return SVG string. glsl: uniforms auto-injected (u_resolution, u_seed, u_param_<key>, u_color_<index>), no state object. genart: GenArt Script source — globals: w, h, t, frame, fps, rnd(n), noise(x,y), vec(x,y), PI, lerp, clamp, map, dist, mouseX/Y, pmouseX/Y, mouseDown, touchX/Y, touches, prev (previous frame ImageData); drawing: circle/rect/line/arc/dot/poly/path x y ...; color: #hex, named, white.50, linear(#a,#b angle:90), radial(#a,#b); params: `param count 100 range:10..500`; colors: `color bg #000`; layers: `layer "terrain:sky" "noon" opacity:0.8 blend:"multiply"`; animation: `frame:` block; once: async (await loadFont ok); post: vignette/grain/blur/bloom/grade/scanlines/pixelate/chromatic_aberration/distort/dither/halftone — effects accept optional quality:"auto"|"high"|"fast" last arg. No state object — params/colors are globals. Data bridge: set window.__genart_data = { strokePaths: [{points:[{x,y},...], depth, width}, ...] }. Use `mulberry32(state.seed)` from "prng" component for p5/canvas2d/three/svg — NEVER `Math.random()`. For genart renderer use built-in rnd() which is seeded automatically.
componentsNoComponent dependencies to resolve alongside the algorithm update. Use list_components to see available.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations, so the description carries the full burden. It does disclose that this is an overwrite ('Replace') and describes the post-update preview workflow, but it says nothing about what happens on validation failure, whether the change is saved immediately, or whether the prior code is recoverable. Most of the text describes the data-bridge runtime contract rather than the behavior of the update operation itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The operational sentence is front-loaded and efficient, but the following 'Algorithm data bridge' block is long and partly duplicates the algorithm parameter's schema description (window.__genart_data, strokePaths, dataChannels). Useful reference material, but not tight.

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

Completeness4/5

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

No output schema exists, and the description compensates by telling the agent how to verify the result (preview_sketch). For a code-replacement tool with fully documented params, the remaining gap is the failure/validation path, which is minor.

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%, so the schema already documents all six parameters in detail. The description adds only a little beyond that: it clarifies when to populate components. It says nothing extra about validate, agent, or model beyond what the schema states.

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 ('Replace the algorithm source code of a sketch'), which cleanly separates it from update_sketch, create_sketch and save_sketch. 'Replace' also signals full-overwrite semantics rather than a patch. It stops short of explicitly naming the sibling it differs from.

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 concrete routing advice: pass components alongside the algorithm when adding/changing them, and use preview_sketch afterward to view the result. It also redirects channel declaration to update_sketch. There is no explicit 'do not use this when…' exclusion, but the context is clear.

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