mcp-ink-design

Overview Schema Source Related Servers Discussions Admin

Craft UI Component with Tactile Physics

ink_craft_component

Read-onlyIdempotent

Synthesize tactile UI components (heroes, glass cards, buttons) with semantic HTML5, CSS logical properties, and spring micro-interactions. Returns markup, styles, and JS.

Instructions

PURPOSE: Synthesize bespoke, tactile UI components (hero sections, glass cards, tactile buttons, navigation bars, metrics grids, modal dialogs) with semantic HTML5, modern CSS logical properties, and spring micro-interaction physics.

BEHAVIOR: Generates component markup, stylesheets, and lifecycle JavaScript strings purely in-memory. Does not mutate the filesystem, write to disk, or initiate network connections. Enforces keyboard accessibility (ARIA dialog, roving tabindex, escape dismiss) and bidi RTL/LTR compliance.

USAGE GUIDELINES:

When to use: Use when creating individual, high-craft UI components and interactive widgets that need to be embedded in an existing layout.
When NOT to use: Do NOT use to scaffold an entire web application project (use ink_create_base instead), nor for 3D WebGL scenes (use ink_build_threejs_experience instead), nor for non-visual state stores (use ink_generate_script_logic instead).
Alternatives: Use ink_create_base for full application scaffolding; use ink_build_threejs_experience for 3D canvas experiences.

RETURNS: ResultEnvelope containing semantic 'html' markup, scoped 'css' rules using logical properties and OKLCH tokens, tactile 'js' interaction logic, and accessibility notes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`title`	No	Primary headline or action label of the component	Craft Architecture
`direction`	No	Writing direction; 'auto' enforces CSS logical properties (margin-inline, inset-inline)	auto
`description`	No	Subheading or explanatory body copy	Engineered with optical precision
`componentType`	No	Type of bespoke UI component to synthesize	hero-section
`interactivePhysics`	No	When true, attaches mouse spring drag, ripple physics, and keyboard navigation handlers

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.

Changed6 schema fields changedv1.2.0Sep 23, 2026

changedInput schema / properties / componentType / description

Previous value: -"Type of bespoke UI component to generate"New value: +"Type of bespoke UI component to synthesize"

changedInput schema / properties / description / description

Previous value: -"Descriptive body text"New value: +"Subheading or explanatory body copy"

changedInput schema / properties / direction / description

Previous value: -"Component writing direction"New value: +"Writing direction; 'auto' enforces CSS logical properties (margin-inline, inset-inline)"

changedInput schema / properties / interactivePhysics / description

Previous value: -"Include tactile spring micro-interaction JavaScript"New value: +"When true, attaches mouse spring drag, ripple physics, and keyboard navigation handlers"

changedInput schema / properties / title / description

Previous value: -"Headline or primary component label"New value: +"Primary headline or action label of the component"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "description": "Domain-specific typed payload returned by the tool",
+      "properties": {
+        "accessibilityNotes": {
+          "description": "Accessibility considerations and ARIA keyboard patterns",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "componentType": {
+          "type": "string"
+        },
+        "css": {
+          "description": "Scoped CSS using logical properties, fluid clamp values, and OKLCH color tokens",
+          "type": "string"
+        },
+        "html": {
+          "description": "Semantic HTML5 markup with ARIA roles and logical structure",
+          "type": "string"
+        },
+        "js": {
+          "description": "Tactile micro-interaction JavaScript with automatic teardown",
+          "type": "string"
+        }
+      },
+      "required": [
+        "componentType",
+        "html",
+        "css",
+        "js",
+        "accessibilityNotes"
+      ],
+      "type": "object"
+    },
+    "evidence": {
+      "additionalProperties": false,
+      "description": "Audit trail, source references, and generated artifact locations",
+      "properties": {
+        "artifacts": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "label": {
+                "type": "string"
+              },
+              "sha256": {
+                "type": "string"
+              },
+              "uri": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "label"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "inputsDigest": {
+          "type": "string"
+        },
+        "sources": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "label": {
+                "type": "string"
+              },
+              "retrievedAt": {
+                "type": "string"
+              },
+              "uri": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "label"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "nextActions": {
+      "description": "Actionable sequential recommendations or subsequent tool suggestions",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "status": {
+      "description": "Execution outcome status",
+      "enum": [
+        "success",
+        "partial",
+        "blocked",
+        "failed"
+      ],
+      "type": "string"
+    },
+    "summary": {
+      "description": "Concise, human-readable executive summary of the tool outcome",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Operational cautions, craft advice, or non-blocking warnings",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "status",
+    "summary",
+    "data",
+    "warnings"
+  ],
+  "type": "object"
+}

First observedv1.1.0Sep 20, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is established. The description adds meaningful behavioral context beyond annotations: it generates in-memory strings without filesystem or network I/O, enforces keyboard accessibility, and mentions bidi compliance. This is more than a restatement, so a 4 is appropriate.

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?

Though longer than average, the description is organized into labeled sections (PURPOSE, BEHAVIOR, USAGE GUIDELINES, RETURNS) with purpose front-loaded. Every sentence carries information; there is no filler. The structure aids scanning, so it earns a 5.

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?

The description covers purpose, when-to-use, behavioral constraints, and return format (ResultEnvelope with html, css, js, and accessibility notes). With annotations covering safety and a comprehensive schema, nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3. The description adds nuance by connecting 'direction' to CSS logical properties and 'interactivePhysics' to spring micro-interaction and keyboard handlers, enriching the static schema text. This exceeds the baseline, warranting a 4.

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 opens with a precise verb ('Synthesize') and resource ('bespoke, tactile UI components'), enumerates concrete component types, and clearly distinguishes itself from siblings by stating it is for individual components, not full scaffolds or 3D scenes. This is a model of purpose clarity.

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?

A dedicated USAGE GUIDELINES section explicitly lists when to use, when NOT to use, and names three sibling tools (ink_create_base, ink_build_threejs_experience, ink_generate_script_logic) with the specific conditions that select them. No inference is required.

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

Deploy Server