Claude Code를 위한 커서 스타일의 디자이너 펜입니다. 헤드(headed) Chromium에서 웹페이지를 클릭하거나, 영역을 지정하거나, 그림을 그리면 Claude가 정확한 소스 파일, 줄 번호, CSS 선택자 및 스크린샷을 받아 즉시 편집하고 확인할 수 있습니다.
시각적 요소에서 소스로 연결하는 세 가지 모드:
모드 | 상호작용 | Claude가 받는 정보 |
element | 요소 위로 마우스를 올리고 클릭 |
|
area | 영역 드래그 |
|
draw | 자유형 빨간 펜, Enter로 완료 |
|
모든 스크린샷은 /tmp에 PNG 파일로 저장되고 경로로 반환되므로, MCP 클라이언트가 base64로 인한 컨텍스트 제한에 걸리지 않습니다.
React 소스 해석은 @babel/plugin-transform-react-jsx-source에 의해 연결된 _debugSource fiber 속성을 통해 Next.js 개발 모드에서 작동합니다. 프로덕션 빌드에서는 이 속성이 제거됩니다. 아래의 프로덕션 소스 매핑을 참조하세요.
Related MCP server: software-design-mermaid-mcp
You: "Make this button rounder"
Claude: [designer_open http://localhost:3000/dashboard]
Claude: [designer_pick mode=element]
You: *click the button*
Claude: → source: Button.tsx:42
Claude: [Edit Button.tsx add rounded-full]
Claude: [designer_screenshot selector=#cta-btn] ← after screenshot for verification전제 조건: Node 18+, Claude Code, 작동 가능한 macOS/Linux (Playwright Chromium).
git clone https://github.com/YOUR_USER/designer-mcp.git
cd designer-mcp
npm install
npx playwright install chromium # one-time browser downloadClaude Code에 MCP를 등록합니다 (user-scope = 모든 세션에서 사용 가능):
claude mcp add --scope user designer-mcp node "$(pwd)/index.js"향후 세션에서 워크플로우를 인식할 수 있도록 Claude 스킬을 설치합니다:
mkdir -p ~/.claude/skills/designer
cp SKILL.md ~/.claude/skills/designer/SKILL.mdClaude Code를 재시작합니다. 세션에서 designer_* 도구와 designer: 스킬을 확인할 수 있습니다.
Next.js 개발 서버를 시작합니다 (소스 매핑을 위해):
cd your-nextjs-app && npm run dev그 다음, Claude Code에서:
"디자이너에서 http://localhost:3000/settings를 열고 헤더를 선택하게 해줘."
Claude가 designer_open(...)을 호출한 다음 designer_pick({ mode: "element" })를 호출합니다. Chromium 창이 앞으로 나타나고 커서가 십자선으로 바뀌면 헤더를 클릭합니다. Claude는 source.fileName과 lineNumber를 받아 직접 편집할 수 있습니다.
단일 요소 — element 사용
한 영역 내의 관련된 여러 요소 — area 사용 (박스를 드래그하면 중심이 박스 안에 포함된 모든 요소가 반환됨)
시각적 주석/설명 — draw 사용 (빨간 펜, Enter로 완료, Esc로 취소)
_debugSource는 개발 전용입니다. 프로덕션 빌드에서 선택기를 사용하려면 next.config.js에서 소스 맵을 활성화하세요:
module.exports = {
productionBrowserSourceMaps: true,
// ...
};현재 선택기는 프로덕션 환경에서 source: null을 반환합니다. 향후 버전에서는 배포된 소스 맵을 통해 선택기를 해석할 예정입니다. PR은 언제나 환영합니다.
모든 도구는 MCP를 통해 노출되며, Claude Code에서는 m Claude Code는 이를 mcp__designer-mcp__*`로 인식합니다.
designer_open(url: string)헤드(headed) Chromium 인스턴스를 실행하거나 재사용하여 탐색합니다. bringToFront()와 AppleScript를 사용하여 macOS에서 창을 맨 앞으로 가져옵니다.
designer_pick({ mode?: "element" | "area" | "draw" })선택기 오버레이를 활성화합니다. 사용자가 상호작용을 완료하면(또는 Esc로 취소하거나 180초 타임아웃 시) 반환됩니다.
designer_screenshot({ selector?: string })페이지 또는 특정 요소의 PNG를 생성합니다. { path, bytes }를 반환합니다.
designer_close()브라우저를 종료하고 Playwright 리소스를 해제합니다.
Playwright로 제어되는 Chromium이 헤드(headed) 모드로 실행됩니다. 프로세스당 싱글톤입니다.
designer_pick은 페이지에 작은 바닐라 JS 오버레이(picker.js)를 주입합니다. 오버레이 기능:
element 모드 — mousemove/click을 추적하고, 마우스가 올라간 대상을 파란색으로 표시하며, 고유한 CSS 선택자를 해석하고, _debugSource를 위해 React fiber 체인을 탐색한 후 MCP로 반환합니다.
area 모드 — 고무줄 방식의 마퀴(marquee) 선택; 마우스 버튼을 떼면 중심이 박스 안에 있는 모든 요소가 수집됩니다 (선택자로 중복 제거).
draw 모드 — 전체 뷰포트 캔버스 오버레이; 획을 점 배열로 캡처; Enter로 완료합니다.
서버는 최대 180초 동안 200ms마다 window.__designerResult를 폴링합니다.
완료 시 적절한 스크린샷(요소 / 영역 클립 / 전체 뷰포트)이 /tmp에 저장되고 경로가 반환됩니다.
다음 분야에 대한 PR을 환영합니다:
프로덕션 소스 맵 해석
Kestrel/React Native 선택기 (현재는 웹 전용)
요소 모드에서 다중 요소 선택 (Cmd-클릭으로 추가)
VS Code "편집기에서 보기" 통합
MIT
Close the designer browser and release resources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'release resources', which hints at cleanup behavior, but does not disclose critical details like whether this is destructive (e.g., closes without saving), requires specific permissions, or has side effects. For a tool with no annotations, this leaves significant behavioral gaps.
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 a single, efficient sentence that directly states the tool's purpose with no wasted words. It is appropriately sized and front-loaded, making it easy to understand immediately without unnecessary elaboration.
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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic action but lacks details on behavioral aspects like what happens to unsaved work or error conditions. For a tool that likely interacts with a browser, more context would be helpful despite the low complexity.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not add parameter details, which is unnecessary here. Baseline is 4 for 0 parameters, as no additional parameter semantics are needed beyond 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 clearly states the specific action ('Close') and resource ('the designer browser'), distinguishing it from sibling tools like designer_open (open), designer_pick (pick), and designer_screenshot (capture screenshot). It provides a complete verb+resource combination that is 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?
The description implies usage when the designer browser is open and resources need releasing, but it does not explicitly state when to use this tool versus alternatives or any prerequisites. It lacks explicit guidance on when-not-to-use or named alternatives, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a URL in the designer's headed Chromium (launches it if not running). Use this before designer_pick.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to navigate to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it opens a URL, launches Chromium if not running, and is intended as a preparatory step. However, it lacks details on error handling, timeouts, or what happens if the URL is invalid, which are important for a tool that interacts with a browser.
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 extremely concise and front-loaded, with two sentences that efficiently convey the action, conditional behavior, and usage context. Every sentence earns its place by providing essential information without redundancy or 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 tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and key behavior. However, it could improve by mentioning potential side effects (e.g., browser window focus) or error scenarios, slightly reducing completeness for a tool that launches external processes.
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%, with the schema fully documenting the 'url' parameter. The description does not add any meaning beyond the schema (e.g., URL format examples or constraints), so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.
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 specific action ('Open a URL') and the target resource ('in the designer's headed Chromium'), including the conditional behavior ('launches it if not running'). It distinguishes from siblings by mentioning designer_pick as a subsequent step, showing awareness of the tool's role in the workflow.
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?
It explicitly provides when-to-use guidance by stating 'Use this before designer_pick,' establishing a clear sequence in the workflow. This directly addresses when to use this tool versus alternatives (like designer_screenshot or designer_close) by positioning it as a prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate the picker in the designer browser. Three modes: element — user clicks one element; returns { selector, tag, classes, text, html, rect, source, screenshot_path } area — user drags a marquee; returns { rect, elements: [{selector, source, rect, ...}], screenshot_path } draw — user ink-annotates with a red pen, Enter to finish; returns { strokes, viewport, screenshot_path (strokes only), viewport_screenshot_path (full view with drawings) } Esc cancels in any mode. screenshot_path / viewport_screenshot_path point to PNGs in /tmp; open with the Read tool.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | element (default) = click one, area = drag marquee, draw = freeform pen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the interactive nature of the tool (user clicks/drags/annotates), cancellation behavior, and output file handling (PNGs in /tmp). However, it doesn't mention potential side effects like browser focus changes or performance considerations.
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 efficiently structured with bullet-like formatting for the three modes, each clearly explaining the user interaction and return values. Every sentence adds essential information about functionality, cancellation, or output handling with zero wasted text.
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 with no annotations and no output schema, the description provides comprehensive context about the interactive process, return data structures, and file outputs. The only minor gap is lack of explicit mention about whether this tool requires specific browser state or permissions.
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 schema has 100% description coverage with clear enum values and descriptions. The description adds significant value by detailing what each mode returns (specific data structures like selector, rect, strokes, etc.) and operational differences between modes, going well beyond the schema's basic mode definitions.
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: 'Activate the picker in the designer browser' with three specific modes (element, area, draw). It distinguishes from siblings like designer_close, designer_open, and designer_screenshot by focusing on interactive element/area selection and annotation rather than basic browser operations or screenshot capture.
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 guidance on when to use each mode: element for clicking one element, area for dragging a marquee, and draw for freeform pen annotation. It also specifies 'Esc cancels in any mode' and mentions using the Read tool to open resulting PNGs, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screenshot the current page or a specific element selector. Returns { path, bytes } — a filesystem path to a PNG in /tmp that you can Read with the Read tool.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No | Optional CSS selector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and effectively discloses key behaviors: it returns a filesystem path to a PNG in /tmp, specifies the output format ({ path, bytes }), and mentions a follow-up action (Read tool). However, it lacks details on potential errors or limitations.
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 front-loaded with the core purpose, followed by essential details on output and usage, with every sentence earning its place and no wasted words.
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 moderate complexity (screenshot functionality with one optional parameter) and no output schema, the description is mostly complete, covering purpose, output, and a follow-up action, though it could include more on error handling or constraints.
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 schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema by implying the selector is optional and used for targeting elements, but does not provide additional syntax or format details.
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 verb ('Screenshot') and resource ('the current page or a specific element selector'), distinguishing it from sibling tools like designer_close, designer_open, and designer_pick by specifying its unique screenshot functionality.
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?
It provides clear context for usage by specifying 'the current page or a specific element selector' and mentions an alternative action ('Read with the Read tool'), but does not explicitly state when not to use it or compare directly to sibling tools.
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.
v0.1.0designer_closedesigner_opendesigner_pickdesigner_screenshotScored across 4 tools
Each tool has a clearly distinct purpose with no overlap: open launches the browser, pick activates the picker with specific modes, screenshot captures images, and close terminates the session. The descriptions clearly differentiate their functions, eliminating any ambiguity in tool selection.
All tool names follow a consistent 'designer_' prefix with descriptive action suffixes (open, pick, screenshot, close), using snake_case uniformly. This predictable pattern makes the tool set easy to navigate and understand at a glance.
With 4 tools, this server is well-scoped for its purpose of browser-based design interactions. Each tool earns its place by covering essential operations: launching, picking elements, capturing screenshots, and cleaning up, without being overly sparse or bloated.
The tool set provides complete lifecycle coverage for the designer domain: it supports opening the browser, interactive element selection, screenshot capture, and proper resource closure. There are no obvious gaps, as all core workflows from initiation to termination are addressed effectively.
Build, clone & publish websites by chatting with Claude. Live in seconds, custom domains + SSL.
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Comment on AI-generated webpages; feedback flows back to your coding agent. Free, MIT, local-first.
Agent-Native design tool - create and edit visual designs with agent assistance
