mcp-ink-design

Overview Schema Source Related Servers Discussions Admin

Build 3D WebGL Canvas Experience

ink_build_threejs_experience

Read-onlyIdempotent

Generate interactive Three.js WebGL scenes for hero backgrounds, particle fields, or geometric visuals with GPU protections and clean teardown.

Instructions

PURPOSE: Generate high-performance, responsive 3D WebGL scenes using Three.js (particle constellations, geometric wireframes, morphing meshes, or interactive hero canvases) with memory-safe lifecycles.

BEHAVIOR: Generates client-side HTML container, full-bleed CSS, and JavaScript module code purely in-memory. Zero filesystem mutations. Incorporates GPU protections: automatically clamps window.devicePixelRatio to 2, attaches window resize listeners, pauses requestAnimationFrame on hidden browser tabs via the Page Visibility API, and exposes a clean teardown disposal function (geometries, materials, renderer.dispose()).

USAGE GUIDELINES:

When to use: Use when a page needs an interactive 3D hero background, ambient particle field, or futuristic geometric visual experience.
When NOT to use: Do NOT use for standard 2D UI widgets or layouts (use ink_craft_component instead), nor for basic CSS animations without WebGL.
Alternatives: Use ink_craft_component for 2D UI components; use ink_create_base for scaffolding the full application shell.

RETURNS: ResultEnvelope containing canvas mounting 'html', full-bleed responsive 'css', initialization and teardown 'js', and lifecycle documentation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sceneType`	No	Type of 3D WebGL scene to generate with Three.js	particle-constellation
`particleCount`	No	Number of particle points (clamped between 100 and 5000 for GPU thermal and battery efficiency)
`accentColorHex`	No	Primary accent color in 6-digit hex format (#RRGGBB) used for points, materials, and point lights	#38bdf8
`enableMouseParallax`	No	When true, registers smooth pointer move listeners with lerp damping for gentle depth parallax

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Domain-specific typed payload returned by the tool
`status`	Yes	Execution outcome status
`summary`	Yes	Concise, human-readable executive summary of the tool outcome
`evidence`	No	Audit trail, source references, and generated artifact locations
`warnings`	Yes	Operational cautions, craft advice, or non-blocking warnings
`nextActions`	No	Actionable sequential recommendations or subsequent tool suggestions

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.0Sep 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description goes far beyond by detailing in-memory generation, zero filesystem mutations, GPU protections (DPR clamping, resize listeners, Page Visibility API pause), and a clean teardown disposal function. This adds valuable behavioral context that annotations do not capture, with no contradiction.

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

Conciseness5/5

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

The description is well-structured with clear sections (PURPOSE, BEHAVIOR, USAGE GUIDELINES, RETURNS), is front-loaded with purpose, and every sentence conveys essential information without fluff. Despite its length, it is efficient and scannable.

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

Completeness5/5

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

Given the tool's complexity (WebGL scene generation) and the existence of an output schema, the description covers purpose, behavior, usage, exclusions, alternatives, and return envelope contents. It also leverages annotations for safety. There are no critical gaps for an agent to call it correctly.

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%, and each parameter has a detailed description (e.g., particleCount mentions clamping for GPU efficiency). The description itself adds minimal parameter-specific insight beyond what the schema already provides, so it meets the baseline of 3 for high coverage. It does not degrade or enhance the parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool generates 3D WebGL scenes using Three.js with specific scene types (particle constellations, geometric wireframes, etc.), and explicitly contrasts with sibling tools like ink_craft_component for 2D UI. It provides a clear verb, resource, and scope, making it distinguishable from all siblings.

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

Usage Guidelines5/5

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

The description includes a dedicated USAGE GUIDELINES section with explicit when-to-use ('interactive 3D hero background'), when-not-to-use ('Do NOT use for standard 2D UI widgets'), and named alternatives (ink_craft_component, ink_create_base). This is textbook guidance for an agent.

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

Deploy Server