mcp-ink-design

Overview Schema Source Related Servers Discussions Admin

Audit Frontend Code Security & Headers

ink_audit_security

Read-onlyIdempotent

Audit frontend code for client-side security flaws like DOM XSS, unsafe sinks, and plain-text token storage. Get severity ratings, recommended CSP header, and precise fixes.

Instructions

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.0Sep 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server