This MCP server provides tools for high-craft, anti-AI-slop web design and engineering, including scaffolding, design tokens, components, 3D experiences, security audits, validation, testing, viewport capture, style inspection, and asset imports with Arabic/RTL support.
Scaffold complete web projects (ink_create_base) with semantic HTML5, OKLCH design tokens, fluid typography, and Arabic RTL/LTR logical properties.
Generate bespoke OKLCH palettes and design tokens (ink_design_palette_tokens) with WCAG AAA contrast guarantees and optional fluid typography scales.
Craft tactile, animated UI components (ink_craft_component) such as hero sections, glass cards, tactile buttons, navigation bars, metrics grids, and modal dialogs.
Build lightweight 3D WebGL experiences (ink_threejs_experience) with devicePixelRatio clamping, mouse parallax, and memory-safe cleanup.
Generate modular JavaScript/TypeScript logic (ink_script_logic) like state stores, event buses, scroll observers, theme toggles, and form validators.
Audit frontend security (ink_security_audit) for DOM XSS, dangerous sinks, token leakage, and missing CSP headers.
Validate design craft (ink_validate_design) by checking anti-slop rules, WCAG contrast, fluid typography, semantic HTML, and bidi logical properties.
Run Python verification tests (ink_python_test_runner) for contrast, security AST linting, visual heuristics, and full audits.
Capture responsive viewport snapshots (ink_capture_viewport) in 16:9, 9:16, and mobile sizes to detect overflow and layout issues.
Inspect and reverse-engineer website styles (ink_inspect_website_style) to extract color palettes, fonts, shadows, and layout DNA.
Import and configure custom fonts/assets (ink_import_custom_assets) with Google Fonts support, including Arabic optical line-height variables.
Generates modern CSS architectures with OKLCH color tokens, fluid typography, logical properties, and responsive design rules.
Configures dynamic Google Fonts imports for Arabic and Latin scripts, generating CSS variables with optical line-heights.
Scaffolds semantic HTML5 projects with accessible landmarks and structured markup.
Provides client-side OWASP security audits, scanning for XSS, unsafe DOM sinks, token leakage, and generating tailored CSP headers.
Generates memory-safe Three.js canvas experiences such as particle constellations and geometric wireframes.
Creates purposeful 3D WebGL experiences with responsive canvases, devicePixelRatio clamping, and memory disposal cleanup.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-ink-design create a tactile-button component with a luxury-dark OKLCH palette"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) Server for High-Craft Web Design & Engineering.
Defeating "AI Slop" through bespoke OKLCH color harmonies, mathematical fluid typography, layered physical depth, Three.js 3D experiences, OWASP security audits, and dedicated Python verification.
INK_MASTER.md)Most AI-generated web interfaces look generic, repetitive, and bland:
Cliche #6366f1 / #a855f7 purple-to-blue linear gradients on dark cards.
Rigid pixel typography that breaks or looks clumsy on mobile devices.
Single harsh black drop-shadows instead of layered ambient occlusion.
Div-heavy markup lacking semantic landmarks (<main>, <header>, <nav>).
Dangerous client-side DOM injections (innerHTML, eval) and tokens stored in localStorage.
mcp-ink-design enforces a human-grade architectural standard:
Perceptually Uniform OKLCH Color Spaces: Uniform lightness and chroma without dead gray zones in gradients.
Mathematical Fluid Typography: Smooth viewport scaling using clamp(min, preferred, max).
Tactile Micro-Interactions: Real physical response curves (cubic-bezier(0.16, 1, 0.3, 1)).
Purposeful 3D WebGL / Three.js: Responsive canvases with devicePixelRatio clamping and memory disposal cleanup.
Zero-Trust Security & Auth: Strict Content Security Policy (CSP), safe DOM sinks, and HttpOnly cookie architecture.
External Verification Suite: Automated Python linter for AST security, contrast calculations, and design heuristics.
Related MCP server: web-design-harvester
tools/list — 11 Standardized Tools)All 11 tools strictly follow the MCP Glama Benchmark standards (ink_<verb>_<noun>, explicit MCP tool annotations, typed output schemas, and operational usage guidelines):
Canonical Tool Name | Title | Verb + Noun | Annotations | Output Schema | Purpose |
| Scaffold Web Application Foundation | create + base |
|
| Scaffolds complete semantic HTML5, CSS architecture, OKLCH tokens, and main.js |
| Generate OKLCH Palette & Design Tokens | generate + palette_tokens |
|
| Generates bespoke OKLCH palettes, CSS custom properties, and WCAG AAA contrast ratios |
| Craft UI Component with Tactile Physics | craft + component |
|
| Crafts tactile components ( |
| Build 3D WebGL Canvas Experience | build + threejs_experience |
|
| Generates memory-safe Three.js canvas experiences ( |
| Generate Modular Architecture Logic | generate + script_logic |
|
| Generates zero-dependency logic modules ( |
| Audit Frontend Code Security & Headers | audit + security |
|
| Scans code for DOM XSS, eval, token leakage in localStorage, and generates tailored CSP headers |
| Validate Design Craft & Contrast Compliance | validate + design |
|
| Computes Craft Grade (S, A, B, C), checks anti-slop rules, evaluates contrast, and audits RTL/LTR logical properties |
| Run Python AST & Contrast Verification Suite | run + python_tests |
|
| Executes the dedicated Python testing suite ( |
| Capture Multi-Viewport Responsive Snapshots | capture + viewport |
|
| Captures 16:9 Desktop, 9:16 Story, and 390x844 Mobile snapshots with automated overflow checks |
| Inspect & Reverse-Engineer Website Style | inspect + website_style |
|
| Deconstructs any website (URL or HTML/CSS) into an OKLCH palette, font hierarchy, and design blueprint |
| Import & Configure Web Fonts and Assets | import + custom_assets |
|
| Configures dynamic Google Fonts imports (Arabic & Latin) and generates CSS variables with optical line-heights |
mcp-ink-design includes first-class engineering for Arabic and bilingual web apps:
Modern CSS Logical Properties: Automatically enforces margin-inline, padding-inline, inset-inline, and text-align: start instead of hardcoded physical directions.
Arabic Optical Compensation: Line-heights for Arabic glyphs are adjusted to 1.75 - 1.85 for body text to avoid diacritic and ascender clipping.
Curated Arabic Font Stacks: IBM Plex Sans Arabic, Cairo, Tajawal, Readex Pro, and Amiri.
Bidi Isolation: Automated <bdi> wrapping and unicode-bidi: isolate prevent punctuation jumping in mixed-language code snippets.
After modifying any layout, ink_capture_viewport captures:
16:9 Landscape (1600x900 / 1920x1080): Desktop container validation.
9:16 Tall Story (540x960 / 1080x1920): Vertical social and mobile story view.
Standard Mobile (390x844): Responsive mobile layout check, ensuring zero horizontal scrollbar leaks.
resources/list)ink://master/philosophy: The complete text of INK_MASTER.md constitution and tool execution pipeline.
ink://tokens/design-presets: Curated OKLCH presets (editorial, luxury-dark, cyber-tactile, neo-brutalist, organic-modern).
ink://security/owasp-frontend: Client-side OWASP security checklist and guidelines.
prompts/list)ink_creative_direction: Guided session to establish project aesthetics, color tokens, and layout before writing code.
ink_anti_slop_audit: Guided workflow to inspect any existing code, compute craft scores, and remediate slop.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"ink-design": {
"command": "npx",
"args": ["-y", "mcp-ink-design"]
}
}
}Or when developing locally:
{
"mcpServers": {
"ink-design": {
"command": "node",
"args": ["c:/Users/DKurdistan/Desktop/mcp-ink-design/dist/index.js"],
"env": {
"INK_PYTHON_PATH": "python"
}
}
}
}Add to your workspace .agents/mcp_config.json or global config:
{
"mcpServers": {
"ink-design": {
"command": "node",
"args": ["c:/Users/DKurdistan/Desktop/mcp-ink-design/dist/index.js"]
}
}
}python/ink_verifier)The server includes a dedicated Python testing and verification engine that runs independently or via ink_run_python_tests:
# Run python unit tests
python -m unittest discover -s python/test
# Test contrast ratio directly via CLI
echo '{"foreground": "#ffffff", "background": "#0b0f19"}' | python -m python.ink_verifier.cli --action contrast --stdin
# Test security linter
echo '{"code": "element.innerHTML = userVal;"}' | python -m python.ink_verifier.cli --action security --stdin# Typecheck
npm run typecheck
# Run Vitest test suite (unit, contract, integration)
npm test
# Build distribution bundle
npm run build
# Inspect package tarball
npm pack --dry-runMIT License — Created by MarwanDevMCP.
PURPOSE: Audit frontend and full-stack web code for client-side security vulnerabilities (DOM XSS, eval/Function sinks, innerHTML execution, plain-text token storage in localStorage, missing security headers, and strict CSP generation).
BEHAVIOR: Executes AST and regex static security scanning in-memory. Purely read-only; never executes or mutates the audited code, and never transmits source code over external networks. Emits severity ratings (critical, high, medium, low) and exact code remediations.
USAGE GUIDELINES:
When to use: Use prior to deployment or code review to ensure zero client-side injection vulnerabilities, secure token handling, and robust Content-Security-Policy headers.
When NOT to use: Do NOT use to validate CSS aesthetic quality, color contrast, or fluid typography rules (use ink_validate_design instead), nor for external URL penetration testing.
Alternatives: Use ink_validate_design for design system, contrast, and bidi compliance checks; use ink_run_python_tests for Python AST test suites.
RETURNS: ResultEnvelope containing 'securityScore', pass/fail boolean, structured 'findings' array with line numbers and remediations, recommended 'recommendedCspHeader', and safe authentication storage patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code string (HTML, JavaScript, or CSS) to inspect for client-side web vulnerabilities | |
| filename | No | Virtual file path context for reporting findings (e.g., 'src/main.js' or 'index.html') | index.html |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the read-only safety profile is covered. The description adds valuable context beyond annotations: in-memory AST/regex scanning, the guarantee that source code is never transmitted externally (a privacy promise), and the severity-rating emission. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured into PURPOSE/BEHAVIOR/USAGE GUIDELINES/RETURNS sections, with the purpose front-loaded. Each sentence earns its place given the tool's complexity (multiple vulnerability classes, remediation output, CSP recommendations). Slightly verbose but justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, an idempotent/read-only annotation set, and a description that covers usage timing, exclusions, alternatives, and the exact return envelope contents (securityScore, findings, recommendedCspHeader), nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (code and filename) are already documented in the schema with type and purpose. The description does not add parameter-specific syntax or format details beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (audit) and resource (frontend/full-stack web code), then enumerates exact vulnerability classes (DOM XSS, eval/Function sinks, innerHTML execution, localStorage token storage, missing headers, CSP generation). Explicitly differentiates from siblings by naming ink_validate_design and ink_run_python_tests. Purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains dedicated 'When to use', 'When NOT to use', and 'Alternatives' sections. Names the exact exclusion conditions (CSS aesthetics, color contrast, external URL pentesting) and the two sibling tools that cover those cases. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| 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 |
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.
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.
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.
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.
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.
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.
PURPOSE: Capture 3 high-resolution viewport snapshots (16:9 Desktop Landscape 1920x1080, 9:16 Vertical Story 1080x1920, and Mobile View 390x844) via headless Chromium to verify layout integrity, responsiveness, and optical centering.
BEHAVIOR: Launches local headless Chromium with an isolated temporary user-data profile. Renders the provided HTML string or URL, waits for network idle, and writes 3 PNG image files to the target outputDirectory (defaults to '.ink_snapshots/'). Detects horizontal scrollbar leaks and viewport overflow. Requires local Chromium/Chrome installed.
USAGE GUIDELINES:
When to use: Call after making HTML/CSS modifications or finishing a component to visually confirm that elements align properly across desktop, mobile, and tall vertical screens.
When NOT to use: Do NOT use for fast code syntax or contrast checks without browser rendering (use ink_validate_design instead).
Alternatives: Use ink_validate_design for fast static design linting; use ink_inspect_website_style to reverse-engineer design tokens from live URLs.
RETURNS: ResultEnvelope containing structured 'snapshots' list (with label, viewport, exact dimensions, file path, and size) and layout overflow metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Human-readable label used for image naming and output organization | Site Snapshot |
| htmlOrUrl | Yes | HTML markup string, local file path (e.g. 'file:///index.html'), or public HTTP/HTTPS URL to render and photograph | |
| outputDirectory | No | Target folder where 16:9, 9:16, and mobile PNG snapshots are written (defaults to '.ink_snapshots') |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly=false, idempotent=true, destructive=false), the description discloses key behaviors: launches headless Chromium with isolated temp profile, writes 3 PNG files, detects scrollbar leaks, and requires local Chromium. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (PURPOSE, BEHAVIOR, USAGE GUIDELINES, RETURNS) and front-loaded purpose. Every sentence adds value, and the length is justified for a tool with multiple behaviors and prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 viewports, output structure, prerequisites), the description is complete: it covers when to use, behavior, prerequisites, and return format. The output schema exists and is referenced, so no further detail needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds minimal parameter-specific detail beyond the schema (e.g., default output directory is already in schema), but it doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: capture 3 specific viewport snapshots via headless Chromium to verify layout integrity, responsiveness, and optical centering. It names the exact resolutions and differentiates from siblings by mentioning alternatives, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' and 'When NOT to use' guidance, and names specific alternatives (ink_validate_design, ink_inspect_website_style) with the conditions for choosing them. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| 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 |
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.
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.
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.
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.
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.
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.
PURPOSE: Scaffold a complete, production-grade semantic web application foundation featuring OKLCH color token architecture, fluid typography scales, modern CSS logical properties, and bilingual Arabic RTL/LTR layout balance.
BEHAVIOR: Generates complete in-memory application files (index.html, styles.css, main.js) within the structured result envelope. Operates purely in-memory with zero direct filesystem side effects; callers receive the code ready to be written to disk. Requires no external credentials or elevated permissions.
USAGE GUIDELINES:
When to use: Call at the start of a web project to establish root HTML semantics, CSS custom property foundations, viewport meta tags, and font configurations.
When NOT to use: Do NOT use to craft isolated UI widgets (use ink_craft_component instead) or to synthesize standalone color variables without project markup (use ink_generate_palette_tokens instead).
Alternatives: Use ink_craft_component for individual components; use ink_generate_palette_tokens for standalone CSS color tokens.
RETURNS: ResultEnvelope containing structured 'files' dictionary (index.html, styles.css, main.js), OKLCH tokensOverview, contrast verification analysis, and typography scales.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Primary language mode: 'ar' optimizes Arabic optical hierarchy, 'en' optimizes Latin, 'bilingual' isolates bidi text with <bdi> chips | bilingual |
| direction | No | Document writing direction: 'rtl' sets dir='rtl' for Arabic, 'ltr' for English, 'auto' configures bidirectional CSS logical properties | auto |
| arabicFont | No | Curated Arabic font family loaded from Google Fonts; pairs with Latin typography with matching optical x-height | ibm-plex |
| designStyle | No | Aesthetic foundation archetype governing OKLCH color harmonies, typography ratios, and border radius | editorial |
| projectName | No | Name of the web application or project folder (used in document title and manifest metadata) | ink-craft-app |
| includePwaMeta | No | When true, injects mobile viewport constraints, theme-color meta tags, and color-scheme dark/light preferences | |
| includeThreeJs | No | When true, mounts a responsive WebGL Three.js canvas in the hero section and includes CDN script tags |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds meaningful context by stating 'operates purely in-memory with zero direct filesystem side effects' and 'requires no external credentials or elevated permissions.' This goes beyond the annotation flags and clarifies the exact nature of the operation, though it could have mentioned the return envelope format in slightly more detail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections (PURPOSE, BEHAVIOR, USAGE GUIDELINES, RETURNS) with front-loaded purpose. Each sentence contributes meaning: it covers what, when, how, and what to expect in return. While lengthy, the structure makes it scannable and every sentence earns its place for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 optional parameters, full schema coverage, an output schema, and sibling differentiation, the description is complete. It explains the in-memory behavior, the return envelope contents (files dictionary, OKLCH tokensOverview, contrast verification, typography scales), and provides usage guardrails. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – every parameter has a detailed description in the schema, including enums and defaults. The tool description does not add parameter-level information, which is acceptable given the schema already carries the full burden. The baseline of 3 is appropriate because the schema fully documents parameters and the description does not need to repeat them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise purpose statement ('Scaffold a complete, production-grade semantic web application foundation') and immediately distinguishes itself from sibling tools by naming specific alternatives and their use cases. The verb 'scaffold' plus the resource 'web application foundation' leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidelines are explicit and actionable: they state when to call (at project start), when NOT to call (for isolated widgets or standalone color tokens), and name the two alternatives (ink_craft_component, ink_generate_palette_tokens) with the conditions that select them. This fully routes the agent to the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PURPOSE: Generate bespoke OKLCH color token ramps, layered shadow elevations, and fluid clamp() typography scales tailored to a creative aesthetic mood and base hue.
BEHAVIOR: Synthesizes CSS custom property tokens and typography steps purely in-memory. Zero filesystem writes and zero external network access. Guarantees WCAG AAA contrast compliance across all text/surface pairings with mathematical delta-E verification.
USAGE GUIDELINES:
When to use: Use when creating or refining a design system's color foundation, fluid typographic scales, or dark/light mode surface tokens.
When NOT to use: Do NOT use to extract colors from an existing live website (use ink_inspect_website_style instead) or to scaffold an entire project skeleton (use ink_create_base instead).
Alternatives: Use ink_inspect_website_style to reverse-engineer design tokens from existing sites; use ink_create_base for full-page scaffolding.
RETURNS: ResultEnvelope containing semantic OKLCH token map, computed contrast analysis, fluid typography scales, and a ready-to-use CSS :root variable stylesheet string.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | Creative aesthetic mood determining surface depths, text luminance steps, and brand accents | editorial |
| baseHue | No | Optional hue angle (0-360) on OKLCH color wheel (e.g., 210 for cyan, 260 for indigo, 30 for warm bronze, 145 for emerald) | |
| includeTypography | No | When true, calculates fluid clamp() typography scale tokens (steps -1 through 5) | |
| includeArabicTokens | No | When true, includes Arabic line-height ratios (1.7-1.85) and font fallback variables |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description goes further by adding 'Zero filesystem writes and zero external network access' and 'Guarantees WCAG AAA contrast compliance with mathematical delta-E verification', giving the agent concrete behavioral expectations beyond the structured hints. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections (PURPOSE, BEHAVIOR, USAGE GUIDELINES, RETURNS), front-loaded with purpose, and each sentence adds value. No redundant phrasing or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and annotations cover safety, the description still provides a concise return summary, explicit usage guidance, and behavioral guarantees. All necessary information for correct invocation and selection is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions 'base hue' and 'mood' but does not add parameter-specific details beyond the schema's own descriptions. It adequately supports the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (generate) and resource (OKLCH color palette & design tokens), and explicitly distinguishes from siblings by naming what it is not for (extracting colors from live websites, scaffolding projects). The purpose is clear and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'When to use' and 'When NOT to use' sections, plus named alternatives (ink_inspect_website_style, ink_create_base). This leaves no ambiguity about selection criteria and provides direct routing to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PURPOSE: Generate zero-dependency, memory-safe JavaScript and TypeScript architectural modules (State Store, Event Bus, Intersection Scroll Observer, Theme Switcher, Form Validator) with production error boundaries.
BEHAVIOR: Synthesizes modular ES6+ JavaScript and optional TypeScript declarations purely in-memory. Zero filesystem modifications. All generated code enforces memory cleanup paradigms (explicit unsubscribe functions, WeakMap caching, EventTarget/listener teardown).
USAGE GUIDELINES:
When to use: Use when creating application state management, event-driven decoupled messaging, viewport scroll animators, theme togglers, or accessible form validation.
When NOT to use: Do NOT use to render UI elements or write component styling (use ink_craft_component instead) or WebGL graphics (use ink_build_threejs_experience instead).
Alternatives: Use ink_craft_component for visual UI components; use ink_build_threejs_experience for 3D canvas rendering.
RETURNS: ResultEnvelope containing zero-dependency ES module 'code', optional 'typescriptTypes', architectural pattern documentation, and executable 'usageExample'.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Architectural runtime pattern: 'state-store' (pub/sub state container), 'event-bus' (typed decoupled messaging), 'scroll-observer' (IntersectionObserver animator), 'theme-toggle' (dark/light/system theme switcher with persistence), 'form-validator' (real-time accessible field validation) | state-store |
| moduleName | No | Name of the exported JavaScript/TypeScript class or module | AppStore |
| typescript | No | When true, emits strict TypeScript interfaces and generic typings alongside the implementation |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description complements them with concrete behavioral detail: 'purely in-memory', 'Zero filesystem modifications', and memory cleanup guarantees like 'explicit unsubscribe functions, WeakMap caching, EventTarget/listener teardown'. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with PURPOSE, BEHAVIOR, USAGE GUIDELINES, and RETURNS sections. It is front-loaded with the core purpose, and every section earns its place by covering invocation context, safety behavior, and output shape without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, all parameters are optional with default values, and the description documents the return envelope ('ResultEnvelope containing zero-dependency ES module code, optional typescriptTypes, architectural pattern documentation, and executable usageExample'), an agent has everything needed to invoke the tool correctly. Sibling routing and side-effect behavior are also covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents all three parameters with defaults and descriptions. The tool description restates the architectural patterns but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate zero-dependency, memory-safe JavaScript and TypeScript architectural modules' followed by an explicit list of module patterns. It clearly differentiates from siblings by naming ink_craft_component and ink_build_threejs_experience as the tools for UI and WebGL, so an agent can select the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The USAGE GUIDELINES section explicitly specifies when to use the tool, when NOT to use it, and names exact alternatives (ink_craft_component, ink_build_threejs_experience). This is the strongest possible routing guidance: both inclusion and exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PURPOSE: Dynamically configure and generate Google Fonts preconnect tags, CSS @import rules, optical line-height variables, and accessible font fallbacks for multilingual Arabic and Latin projects.
BEHAVIOR: Generates HTML link tags, CSS @import rules, and stylesheet font-family declarations purely in-memory. Does not download font binaries or write files to disk directly. Formulates tailored optical line-height variables (1.7-1.85 for Arabic, 1.5-1.6 for Latin) to eliminate clipping.
USAGE GUIDELINES:
When to use: Call when setting up web fonts, adding Arabic typographic scales, or loading bespoke font families into a project.
When NOT to use: Do NOT use to synthesize fluid clamp font-size scales (use ink_generate_palette_tokens instead) or to scaffold an entire project (use ink_create_base instead).
Alternatives: Use ink_generate_palette_tokens for fluid typography size scales; use ink_create_base for full HTML document scaffolding.
RETURNS: ResultEnvelope containing 'htmlLinkTags', 'cssImportRule', 'cssVariables' with font-family definitions, and an accessible 'fallbackStack'.
| Name | Required | Description | Default |
|---|---|---|---|
| weights | No | Array of numeric font weights to import (e.g. [400, 600, 700]) | |
| displayFont | No | Optional display/headline font family name (e.g. 'Amiri', 'Playfair Display', 'Clash Display') | |
| primaryFont | No | Primary font family name to import (e.g. 'IBM Plex Sans Arabic', 'Inter', 'Outfit') | IBM Plex Sans Arabic |
| includeArabic | No | When true, loads Arabic character subsets, sets optical line heights (1.7-1.85), and adds bidi fallbacks |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is known to be safe and side-effect-free. The description adds valuable context: it generates content purely in-memory, does not write files, and details specific optical line-height ranges (1.7-1.85 Arabic, 1.5-1.6 Latin). This enriches the behavioral profile beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with PURPOSE, BEHAVIOR, USAGE GUIDELINES, and RETURNS sections. It is front-loaded with the core purpose. While longer than minimal, every section adds distinct value and there is no redundancy. It earns a 4 for clear organization and purposeful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to use it (and when not), behavioral details, and the return envelope structure (htmlLinkTags, cssImportRule, cssVariables, fallbackStack). With an output schema present, it doesn't need to enumerate return values further. For a tool with 4 parameters and rich behavior, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all four parameters have descriptions). The tool description adds some context (e.g., linking includeArabic to line-heights and fallbacks) but does not significantly expand on what the schema already provides. Per the rubric, with high coverage the baseline is 3, and the description does not elevate beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: dynamically configure and generate Google Fonts preconnect tags, CSS @import rules, optical line-height variables, and accessible font fallbacks for Arabic/Latin projects. It clearly distinguishes itself from siblings by naming alternatives in the usage guidelines, making it easy for an agent to know when to select this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with named alternatives (ink_generate_palette_tokens, ink_create_base) provide clear routing. The description leaves no ambiguity about when to call this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PURPOSE: Deconstruct existing live websites or HTML/CSS templates to reverse-engineer color palettes, typography scales, elevation shadows, and layout DNA into modern OKLCH tokens.
BEHAVIOR: Fetches public website markup over HTTPS or parses local HTML/CSS code strings in-memory. Strictly read-only with zero disk modifications. Remote network requests enforce a 10s timeout, safe redirect limits, and private subnet IP blocking. Converts extracted HEX/RGB values into perceptual OKLCH color variables.
USAGE GUIDELINES:
When to use: Use when analyzing a reference website or mockup to extract its visual hierarchy, typography system, and color ramps.
When NOT to use: Do NOT use to generate novel color tokens from scratch (use ink_generate_palette_tokens instead) or to evaluate code for anti-slop compliance (use ink_validate_design instead).
Alternatives: Use ink_generate_palette_tokens to synthesize new design tokens; use ink_capture_viewport to capture visual screenshots.
RETURNS: ResultEnvelope containing detected 'archetype', extracted 'colors' (with HEX and OKLCH conversions), 'typography' hierarchy, 'shadows', 'layoutDna', and an actionable recommended OKLCH palette stylesheet.
| Name | Required | Description | Default |
|---|---|---|---|
| urlOrCode | Yes | Public website URL (e.g. 'https://stripe.com') or raw HTML/CSS code snippet to reverse-engineer | |
| extractOklchPalette | No | When true, converts extracted HEX and RGB colors into perceptual OKLCH color tokens |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing network behavior: HTTPS fetching, 10-second timeout, safe redirect limits, private subnet IP blocking, in-memory parsing, strict read-only behavior, and OKLCH conversion. It also explicitly states 'zero disk modifications,' reinforcing the readOnlyHint. This is rich, non-redundant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear labeled sections: PURPOSE, BEHAVIOR, USAGE GUIDELINES, and RETURNS. Every sentence contributes useful information, and the most important purpose and safety traits are front-loaded. Despite its length, nothing is wasteful or redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, behavior, safety boundaries, usage conditions, alternatives, and a detailed summary of the return envelope. With an output schema present, the extra RETURNS section is a bonus rather than a requirement. An agent has everything needed to decide when and how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions, achieving 100% coverage, so the baseline of 3 applies. The description adds helpful context about OKLCH conversion and output shape, but it does not add much detail about the parameters themselves beyond what the schema provides. No deduction for missing parameter info is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase, 'Deconstruct existing live websites or HTML/CSS templates to reverse-engineer color palettes, typography scales, elevation shadows, and layout DNA,' which clearly identifies the tool's resource and goal. It also distinguishes itself from generation and validation siblings by naming alternatives. An agent can immediately understand what this tool does and what it produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to use' and 'When NOT to use' sections, naming sibling tools like ink_generate_palette_tokens and ink_validate_design as the correct alternatives for out-of-scope tasks. It also lists additional alternatives such as ink_capture_viewport. This gives an agent concrete decision rules for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PURPOSE: Execute the external Python verification suite for deep AST static analysis, mathematical contrast matrix calculation, and headless layout audits.
BEHAVIOR: Spawns the local Python 3 ink_verifier engine in a sandboxed subprocess. Purely read-only; does not mutate source files or modify disk state unless 'capture' is specifically invoked. Requires Python 3.10+ installed in the environment PATH. Returns comprehensive structured test metrics.
USAGE GUIDELINES:
When to use: Use when running deep multi-pass Python AST analysis, mathematical APCA/WCAG contrast calculation, or comprehensive verification across an entire codebase.
When NOT to use: Do NOT use for fast in-memory CSS validation without Python (use ink_validate_design instead) or for standalone client-side security audits (use ink_audit_security instead).
Alternatives: Use ink_validate_design for fast TypeScript-native design verification; use ink_audit_security for native security scanning.
RETURNS: ResultEnvelope containing structured test outcomes from the Python verifier engine according to the invoked action ('contrast', 'security', 'visual', 'audit', 'full', 'bidi', 'inspect', or 'capture').
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Source code snippet to analyze with Python AST and regex engines (required when action is 'security', 'visual', 'audit', 'bidi', or 'full') | |
| action | No | Verification action: 'contrast' (WCAG/APCA matrix calculation), 'security' (Python AST sink linter), 'visual' (anti-slop rule engine), 'audit' (combined static analysis), 'full' (all static + dynamic checks), 'bidi' (RTL/LTR logical property AST analysis), 'inspect' (reverse-engineer URL design), 'capture' (headless browser multi-viewport snapshots) | full |
| target | No | Website URL or local HTML file path (required when action is 'inspect' or 'capture') | |
| backgroundHex | No | Background surface color in 6-digit hex (used when action is 'contrast') | |
| foregroundHex | No | Foreground text color in 6-digit hex (used when action is 'contrast') |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: annotations declare readOnlyHint=true, but the description states that the tool 'does not mutate source files or modify disk state unless 'capture' is specifically invoked.' This explicitly opens a path to disk modification, contradicting the read-only annotation. The description also discloses useful environmental details (Python 3.10+, sandboxed subprocess), but the contradiction forces a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear PURPOSE, BEHAVIOR, USAGE GUIDELINES, and RETURNS headings, and the purpose is front-loaded. It is somewhat longer than necessary because the alternatives are named twice and the action list is repeated from the schema, but the organization makes it easy to scan and each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 8 enum values, conditional requirements) and the presence of a rich output schema, the description is largely complete: it covers environment dependencies, sandboxing, read-only behavior, when to use vs. alternatives, and return structure. The only completeness gap is rooted in the read-only/capture contradiction, which is already penalized under behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter meanings are already fully documented in the schema. The description adds some contextual framing by explaining that returned outcomes depend on the invoked action)Skip and by repeating conditional use cases, but it does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Execute'), a specific resource (the Python ink_verifier suite), and the exact scope: deep AST static analysis, contrast matrix calculation, and headless layout audits. It also names the sibling alternatives it is not, so an agent can distinguish it from ink_validate_design and ink_audit_security without inspecting their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for deep Python AST analysis, explicit when-NOT-to-use guidance for fast CSS validation and client-side security audits, and names the alternative sibling tools. This is exactly the kind of decision routing an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PURPOSE: Evaluate HTML and CSS code against anti-AI-slop design heuristics (detecting generic AI purple gradients, hardcoded pixel font sizes, missing semantic tags), verify WCAG AAA color contrast ratios, and audit Arabic RTL/LTR logical properties.
BEHAVIOR: Executes in-memory static AST and regex analysis on the supplied code strings. Completely read-only with zero filesystem writes, no network requests, and deterministic score computation. Emits a letter grade (S, A, B, C, F), numerical score (0-100), and specific remediation diff advice.
USAGE GUIDELINES:
When to use: Call after creating or modifying web layouts, components, or stylesheets to verify craft quality, contrast compliance, and bidi readiness before committing.
When NOT to use: Do NOT use for JavaScript security vulnerability scanning (use ink_audit_security instead) or for capturing real-browser screenshots (use ink_capture_viewport instead).
Alternatives: Use ink_audit_security for security/XSS checks; use ink_capture_viewport for visual multi-viewport screenshot verification.
RETURNS: ResultEnvelope containing 'craftScore', 'craftGrade', 'isHighCraft' boolean, 'antiSlopChecks' results, computed 'contrast' analysis, 'bidiAndAlignment' report, and prioritized 'remediationAdvice'.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | HTML and CSS code string to evaluate for anti-slop rules, typography scaling, and alignment | |
| checkBidi | No | When true, audits CSS logical property compliance (e.g. flagging margin-left instead of margin-inline-start) | |
| backgroundHex | No | Surface background color in 6-digit hex (#RRGGBB) to verify contrast ratio against text | #0b0f19 |
| foregroundHex | No | Primary foreground text color in 6-digit hex (#RRGGBB) to verify against surface | #f8fafc |
| checkCentering | No | When true, verifies optical centering balance and checks for horizontal overflow risks (e.g. 100vw, fixed large widths) |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: in-memory static AST/regex analysis, zero filesystem writes, no network requests, deterministic scoring, and a clear output format. It fully aligns with readOnlyHint, idempotentHint, and destructiveHint, and enriches them with operational specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with PURPOSE, BEHAVIOR, USAGE GUIDELINES, and RETURNS sections. It is information-dense but every sentence contributes meaningful guidance, with the core purpose front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity, the description is complete: it covers purpose, behavior, usage, exclusions, alternatives, and a summary of return values. The output schema exists, so detailed return documentation is not required in the description. The annotations and schema cover safety and parameters, leaving no critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description does not need to repeat parameter details; it adds only high-level context about evaluating code, contrast, and bidi, which is consistent with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Evaluate HTML and CSS code') against distinct criteria: anti-AI-slop heuristics, WCAG AAA contrast ratios, and bidi logical properties. This is far more specific than the tool name and clearly differentiates the tool from security auditing and screenshot-capture siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context ('Call after creating or modifying web layouts... before committing'), explicit when-not-to-use cases, and names the correct alternatives (ink_audit_security, ink_capture_viewport). This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.0ink_audit_securityink_build_threejs_experienceink_capture_viewport4 fields changedInput schema / properties / htmlOrUrl / descriptionPrevious value: -"HTML code string, local file path, or public URL to capture"New value: +"HTML markup string, local file path (e.g. 'file:///index.html'), or public HTTP/HTTPS URL to render and photograph"Input schema / properties / outputDirectory / descriptionPrevious value: -"Target folder where 16:9, 9:16, and mobile screenshots are saved"New value: +"Target folder where 16:9, 9:16, and mobile PNG snapshots are written (defaults to '.ink_snapshots')"Input schema / properties / title / descriptionPrevious value: -"Title or label for the captured snapshot"New value: +"Human-readable label used for image naming and output organization"Output 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": {
+ "layoutMetrics": {
+ "additionalProperties": {},
+ "description": "Computed scrollWidth, scrollHeight, and overflow metrics",
+ "type": "object"
+ },
+ "outputDirectory": {
+ "type": "string"
+ },
+ "snapshots": {
+ "description": "List of 3 captured viewport images",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "aspect_ratio": {
+ "type": "string"
+ },
+ "dimensions": {
+ "description": "Exact pixel dimensions (e.g. '1920x1080', '1080x1920', '390x844')",
+ "type": "string"
+ },
+ "filePath": {
+ "description": "Absolute path to the saved PNG snapshot file",
+ "type": "string"
+ },
+ "fileSize": {
+ "description": "Size of the PNG file in bytes",
+ "type": "number"
+ },
+ "label": {
+ "description": "Viewport descriptor (e.g., '16:9 Desktop Landscape', '9:16 Vertical Story', 'Mobile View')",
+ "type": "string"
+ },
+ "viewport": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "viewport",
+ "dimensions",
+ "aspect_ratio",
+ "filePath"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "outputDirectory",
+ "snapshots"
+ ],
+ "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"
+}ink_craft_component6 fields changedInput schema / properties / componentType / descriptionPrevious value: -"Type of bespoke UI component to generate"New value: +"Type of bespoke UI component to synthesize"Input schema / properties / description / descriptionPrevious value: -"Descriptive body text"New value: +"Subheading or explanatory body copy"Input schema / properties / direction / descriptionPrevious value: -"Component writing direction"New value: +"Writing direction; 'auto' enforces CSS logical properties (margin-inline, inset-inline)"Input schema / properties / interactivePhysics / descriptionPrevious value: -"Include tactile spring micro-interaction JavaScript"New value: +"When true, attaches mouse spring drag, ripple physics, and keyboard navigation handlers"Input schema / properties / title / descriptionPrevious value: -"Headline or primary component label"New value: +"Primary headline or action label of the component"Output 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"
+}ink_create_base8 fields changedInput schema / properties / arabicFont / descriptionPrevious value: -"Curated Arabic typography stack"New value: +"Curated Arabic font family loaded from Google Fonts; pairs with Latin typography with matching optical x-height"Input schema / properties / designStyle / descriptionPrevious value: -"High-craft visual design style"New value: +"Aesthetic foundation archetype governing OKLCH color harmonies, typography ratios, and border radius"Input schema / properties / direction / descriptionPrevious value: -"Document writing direction (RTL for Arabic, LTR for English, auto for bidirectional)"New value: +"Document writing direction: 'rtl' sets dir='rtl' for Arabic, 'ltr' for English, 'auto' configures bidirectional CSS logical properties"Input schema / properties / includePwaMeta / descriptionPrevious value: -"Include mobile web app viewport and theme-color meta tags"New value: +"When true, injects mobile viewport constraints, theme-color meta tags, and color-scheme dark/light preferences"Input schema / properties / includeThreeJs / descriptionPrevious value: -"Include Three.js canvas setup in scaffold"New value: +"When true, mounts a responsive WebGL Three.js canvas in the hero section and includes CDN script tags"Input schema / properties / language / descriptionPrevious value: -"Language mode of the scaffolded application"New value: +"Primary language mode: 'ar' optimizes Arabic optical hierarchy, 'en' optimizes Latin, 'bilingual' isolates bidi text with <bdi> chips"Input schema / properties / projectName / descriptionPrevious value: -"Name of the web project or application"New value: +"Name of the web application or project folder (used in document title and manifest metadata)"Output 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": {
+ "arabicTypography": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "designStyle": {
+ "type": "string"
+ },
+ "direction": {
+ "type": "string"
+ },
+ "files": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "In-memory project files mapping (e.g. index.html, styles.css, main.js, manifest.json)",
+ "type": "object"
+ },
+ "language": {
+ "type": "string"
+ },
+ "projectName": {
+ "type": "string"
+ },
+ "threeJsConfig": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tokens": {
+ "additionalProperties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "projectName",
+ "designStyle",
+ "direction",
+ "language",
+ "files",
+ "tokens",
+ "arabicTypography",
+ "threeJsConfig"
+ ],
+ "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"
+}ink_design_palette_tokensink_generate_palette_tokensink_generate_script_logicink_import_custom_assets5 fields changedInput schema / properties / displayFont / descriptionPrevious value: -"Secondary/Display font family name"New value: +"Optional display/headline font family name (e.g. 'Amiri', 'Playfair Display', 'Clash Display')"Input schema / properties / includeArabic / descriptionPrevious value: -"Include Arabic optical sizing and fallback stacks"New value: +"When true, loads Arabic character subsets, sets optical line heights (1.7-1.85), and adds bidi fallbacks"Input schema / properties / primaryFont / descriptionPrevious value: -"Primary font family name to import"New value: +"Primary font family name to import (e.g. 'IBM Plex Sans Arabic', 'Inter', 'Outfit')"Input schema / properties / weights / descriptionPrevious value: -"Font weight numeric values to load"New value: +"Array of numeric font weights to import (e.g. [400, 600, 700])"Output 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": {
+ "cssImportRule": {
+ "description": "CSS @import statement for stylesheets",
+ "type": "string"
+ },
+ "cssVariables": {
+ "description": "CSS font-family and line-height custom property variables",
+ "type": "string"
+ },
+ "displayFont": {
+ "type": "string"
+ },
+ "fallbackStack": {
+ "description": "Accessible system fallback font stack",
+ "type": "string"
+ },
+ "htmlLinkTags": {
+ "description": "Preconnect and Google Fonts <link> tags ready for HTML <head>",
+ "type": "string"
+ },
+ "primaryFont": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "primaryFont",
+ "htmlLinkTags",
+ "cssImportRule",
+ "cssVariables",
+ "fallbackStack"
+ ],
+ "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"
+}ink_inspect_website_style3 fields changedInput schema / properties / extractOklchPalette / descriptionPrevious value: -"Convert extracted HEX/RGB colors into perceptual OKLCH tokens"New value: +"When true, converts extracted HEX and RGB colors into perceptual OKLCH color tokens"Input schema / properties / urlOrCode / descriptionPrevious value: -"Target website URL (e.g. https://example.com) or raw HTML/CSS to reverse-engineer"New value: +"Public website URL (e.g. 'https://stripe.com') or raw HTML/CSS code snippet to reverse-engineer"Output 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": {
+ "archetype": {
+ "description": "Detected aesthetic archetype (editorial, luxury-dark, brutalist, cyber-tactile, organic)",
+ "type": "string"
+ },
+ "colors": {
+ "description": "Extracted colors with HEX, RGB, OKLCH, and usage frequency",
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "layoutDna": {
+ "additionalProperties": {},
+ "description": "Layout DNA analysis (flexbox, grid, gap values, border radii)",
+ "type": "object"
+ },
+ "recommendedOklchPalette": {
+ "description": "Actionable CSS token block upgrade",
+ "type": "string"
+ },
+ "shadows": {
+ "description": "Extracted elevation shadow definitions",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "typography": {
+ "additionalProperties": {},
+ "description": "Detected font families, font sizes, line heights, and weights",
+ "type": "object"
+ }
+ },
+ "required": [
+ "archetype",
+ "colors",
+ "typography",
+ "shadows",
+ "layoutDna"
+ ],
+ "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"
+}ink_python_test_runnerink_run_python_testsink_script_logicink_security_auditink_threejs_experienceink_validate_design6 fields changedInput schema / properties / backgroundHex / descriptionPrevious value: -"Background surface color to test contrast"New value: +"Surface background color in 6-digit hex (#RRGGBB) to verify contrast ratio against text"Input schema / properties / checkBidi / descriptionPrevious value: -"Audit CSS logical properties and Arabic RTL/LTR balance"New value: +"When true, audits CSS logical property compliance (e.g. flagging margin-left instead of margin-inline-start)"Input schema / properties / checkCentering / descriptionPrevious value: -"Detect optical centering abuse and horizontal overflow risks"New value: +"When true, verifies optical centering balance and checks for horizontal overflow risks (e.g. 100vw, fixed large widths)"Input schema / properties / code / descriptionPrevious value: -"HTML and CSS code to evaluate for anti-slop rules, fluid scaling, and craft quality"New value: +"HTML and CSS code string to evaluate for anti-slop rules, typography scaling, and alignment"Input schema / properties / foregroundHex / descriptionPrevious value: -"Primary text color to test contrast"New value: +"Primary foreground text color in 6-digit hex (#RRGGBB) to verify against surface"Output 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": {
+ "antiSlopChecks": {
+ "description": "Results for anti-slop rules (generic AI gradients, fluid clamp, semantic markup)",
+ "items": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "bidiAndAlignment": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "CSS logical property and optical alignment audit details"
+ },
+ "contrast": {
+ "additionalProperties": false,
+ "description": "Mathematical WCAG contrast calculation results",
+ "properties": {
+ "background": {
+ "type": "string"
+ },
+ "foreground": {
+ "type": "string"
+ },
+ "grade": {
+ "type": "string"
+ },
+ "ratio": {
+ "type": "number"
+ },
+ "wcagAA": {
+ "type": "boolean"
+ },
+ "wcagAAA": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "foreground",
+ "background",
+ "ratio",
+ "grade",
+ "wcagAAA",
+ "wcagAA"
+ ],
+ "type": "object"
+ },
+ "craftGrade": {
+ "description": "Letter grade (S, A, B, C, F)",
+ "type": "string"
+ },
+ "craftScore": {
+ "description": "Overall design craftsmanship rating (0-100)",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "isHighCraft": {
+ "description": "True if craftScore >= 75 and contrast passes WCAG AA",
+ "type": "boolean"
+ },
+ "remediationAdvice": {
+ "description": "Specific, actionable code edits to reach Grade A/S craft",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "strengths": {
+ "description": "Design elements adhering to high-craft principles",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "craftScore",
+ "craftGrade",
+ "isHighCraft",
+ "antiSlopChecks",
+ "contrast",
+ "bidiAndAlignment",
+ "strengths",
+ "remediationAdvice"
+ ],
+ "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"
+}v1.1.0ink_capture_viewportink_craft_componentink_create_baseink_design_palette_tokensink_import_custom_assetsink_inspect_website_styleink_python_test_runnerink_script_logicink_security_auditink_threejs_experienceink_validate_designScored across 11 tools
Most tools have clearly distinct resources (project, component, palette, fonts, security, design validation), and the usage guidance reinforces those boundaries. However, ink_run_python_tests can be invoked with actions like 'contrast', 'security', 'inspect', and 'capture', which overlaps with ink_validate_design, ink_audit_security, ink_inspect_website_style, and ink_capture_viewport.
All tools follow the same ink_ + verb + object snake_case convention, such as create_base, generate_palette_tokens, craft_component, and capture_viewport. The naming pattern is highly predictable and reinforces the purpose of each tool.
11 tools is a well-scoped size for a design and verification toolkit, covering generation, component crafting, 3D, script logic, fonts, inspection, validation, security, and capture. Each tool maps to a meaningful stage in the design workflow without feeling bloated.
The toolset covers the full design lifecycle: scaffolding, palette token generation, font setup, component creation, 3D experiences, script logic, style inspection, design validation, security auditing, deep verification, and viewport capture. There are no obvious missing core operations for the stated semantic web design purpose.
18 color tools: OKLCH, WCAG and APCA contrast fixes, palettes, gradients, color blindness, tokens.
Generate design systems: OKLCH colors, fluid type scales, spacing, shape, icon and motion tokens.
Turn any live website into brand colors, fonts, design tokens, SVGs, Lottie and paste-ready code.
Give your agent a real design system: tokens, measured WCAG contrast, and rules to follow.
