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., "@DesignPin MCP Server Upload this HTML as a new version to module mod_abc123"
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.
An MCP server that lets any AI assistant push HTML prototypes to DesignPin for team review and read back reviewer feedback.
DesignPin is a tool for reviewing HTML prototypes with DOM-anchored comments. This package wraps the DesignPin REST API as a Model Context Protocol server, exposing three tools — createShareLink, uploadVersion, listComments — to any MCP-compatible AI client.
Once configured, your AI assistant — Claude Desktop, Cursor, VS Code (Copilot), Gemini CLI, or any other MCP-compatible client — can ship a generated HTML prototype to a shareable review link, pull back reviewer comments to incorporate, and push iterations as new versions, all from inside the same conversation that produced the design.
For ChatGPT users: ChatGPT does not currently support MCP servers. Use the direct REST API via Custom GPT Actions instead — no MCP server needed.
Related MCP server: Lanhu MCP Server
The server is invoked by your MCP client; you don't run it directly during normal use. The simplest path is npx invocation, which fetches and runs without a global install:
npx -y @designpin/mcp-server --api-key dp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --project-id proj_example_abc123For most workflows you'll set this in your MCP client's config file rather than running it manually — see Client config examples below.
To verify the install works:
npx -y @designpin/mcp-server --version
# → 0.1.0
npx -y @designpin/mcp-server --help
# → usage infoOpen designpin.pro and sign in.
Open any project (or create one).
Click API & Integrations in the project header.
Click Generate new key, give it a name (e.g. "Claude Desktop").
Copy the key immediately — it's shown once and cannot be retrieved later.
Each key is scoped to a single project. Generate separate keys per client / use case so you can revoke them individually.
Both CLI flags and environment variables are supported. Flags win when both are present.
CLI flag | Env var | Required | Default | Description |
|
| for | — | Your |
|
| for | — | Project ID the key is scoped to |
|
| no |
| API base URL (override for testing) |
| — | no | — | Show usage and exit |
| — | no | — | Print version and exit |
Security note: CLI flags are visible in
psoutput on multi-user systems. Prefer environment variables on shared machines.
createShareLinkCreate a public review link for an HTML prototype. No project setup required — creates a brand-new throwaway project. Rate-limited to 10 requests/hour per IP.
Input | Type | Required | Description |
| string | yes | Complete HTML document to share |
| string | yes | Display name for the share, max 80 chars |
| string | no | Author name shown on review page |
Returns: JSON with url, reviewToken, projectId, moduleId, versionId.
Example prompt to your AI assistant:
"Take this HTML and create a DesignPin share link titled 'Landing page hero V3'."
uploadVersionUpload a new HTML version to an existing DesignPin module. Auto-increments versionNumber. Requires the API key + projectId from configuration plus a moduleId from the user.
Input | Type | Required | Description |
| string | yes | Complete HTML for the new version |
| string | yes | Target module within the configured project |
| string | no | Version description shown in the sidebar |
Returns: JSON with url, versionId, versionNumber.
Example prompt:
"Push this revised HTML as a new version to module
mod_example_def456with the description 'Address pin #3 contrast feedback'."
listCommentsFetch comments visible on a specific version of a DesignPin module. Uses chronological cutoff semantics matching the web UI: a comment is visible on version V if its origin version is V or any earlier version.
Input | Type | Required | Description |
| string | yes | Module ID |
| string | yes | Specific version to view comments on |
Returns: JSON with a comments array and a summary string like "3 open, 1 resolved".
Example prompt:
"Get the comments on module
mod_example_def456at versionver_example_ghi789and tell me what's blocking approval."
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"designpin": {
"command": "npx",
"args": ["-y", "@designpin/mcp-server"],
"env": {
"DESIGNPIN_API_KEY": "dp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"DESIGNPIN_PROJECT_ID": "proj_example_abc123"
}
}
}
}Restart Claude Desktop after saving.
Edit ~/.cursor/mcp.json:
{
"mcpServers": {
"designpin": {
"command": "npx",
"args": ["-y", "@designpin/mcp-server"],
"env": {
"DESIGNPIN_API_KEY": "dp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"DESIGNPIN_PROJECT_ID": "proj_example_abc123"
}
}
}
}Reload Cursor after saving.
Add to your VS Code user settings JSON or a workspace .vscode/mcp.json:
{
"servers": {
"designpin": {
"command": "npx",
"args": ["-y", "@designpin/mcp-server"],
"env": {
"DESIGNPIN_API_KEY": "dp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"DESIGNPIN_PROJECT_ID": "proj_example_abc123"
}
}
}
}Edit your Gemini CLI config (path varies by version). Both the env-style and the flag-style work; flag-style is shown here:
{
"mcpServers": {
"designpin": {
"command": "npx",
"args": [
"-y", "@designpin/mcp-server",
"--api-key", "dp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"--project-id", "proj_example_abc123"
]
}
}
}You: Generate a pricing page with three tiers (Free, Pro $12, Team $29).
Push it to DesignPin so my team can review.
AI: [generates HTML, calls createShareLink]
Share link created. Send this to your team:
https://designpin.pro/review/EXAMPLE_TOKEN_xyz
Project: proj_example_abc123
Module: mod_example_def456
Version: ver_example_ghi789
[team reviews and leaves 4 comments]
You: Pull the feedback from module mod_example_def456 at version
ver_example_ghi789 and address the must-fix comments.
AI: [calls listComments]
Open comments (4):
- P0 Pin #1 "CTA contrast fails WCAG AA on the Pro tier"
- P1 Pin #2 "Pricing hidden until hover — make always visible"
- P1 Pin #3 "Annual toggle is ambiguous — show savings %"
- P2 Pin #4 "Logo could link back to homepage"
I'll regenerate the HTML with the two P0/P1 issues addressed.
You: Push the revision.
AI: [generates updated HTML, calls uploadVersion]
v2 uploaded. Same review URL — your team can compare versions.If you want to call the DesignPin API without an MCP server, the OpenAPI 3.1 spec is published at:
https://designpin.pro/openapi.json
Import it into Postman, generate a client SDK, or use it directly with ChatGPT Custom GPT Actions.
DesignPin app: https://designpin.pro
OpenAPI spec: https://designpin.pro/openapi.json
Issues: https://github.com/opjhabuilds/designpin-mcp-server/issues
MIT © 2026 Omprakash Jha
Fetch comments visible on a specific version of a DesignPin module. Returns comments using chronological cutoff semantics matching the web UI: a comment is visible on version V if its origin version is V or any earlier version. Useful for fetching reviewer feedback to incorporate into design revisions.
| Name | Required | Description | Default |
|---|---|---|---|
| moduleId | Yes | Module ID to fetch comments for | |
| versionId | Yes | Specific version ID to view comments on (chronological cutoff) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the chronological cutoff semantics: 'a comment is visible on version V if its origin version is V or any earlier version.' This adds important behavioral context beyond a simple fetch.
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 two concise sentences plus a usage sentence. Every sentence adds value, and the key information (verb, resource, scope, semantics) is front-loaded. 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?
Without an output schema, the description could explain the return format, but the visibility semantics are well-covered. For a simple list fetch, it is mostly complete. Minor gap: no mention of pagination or structure of comments, but not critical.
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 baseline is 3. The description adds meaning to versionId by explaining the chronological cutoff semantics, which goes beyond the schema description. It does not add much for moduleId, but the incremental value justifies 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 clearly states the verb 'fetch' and resource 'comments' with the specific context of a DesignPin module and version. It is specific and leaves no ambiguity about what the tool does, distinguishing it from siblings like createShareLink and uploadVersion.
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 explicitly mentions a use case: 'fetching reviewer feedback to incorporate into design revisions.' However, it does not provide when-not-to-use guidance or compare with alternatives, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a new HTML version to an existing DesignPin module. Auto-increments versionNumber. Requires API key + projectId + moduleId. Use this to push design iterations into an existing project for review.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Complete HTML for the new version | |
| moduleId | Yes | Target module ID within the project | |
| description | No | Optional version description shown in sidebar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auto-increment of versionNumber and required credentials, but fails to mention side effects, error behavior, or security nuances. The inconsistency about projectId further reduces transparency.
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?
Three sentences, each adding value: purpose, details, usage context. No unnecessary words. Well-structured and efficient.
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 no output schema and simple parameters, description covers purpose and one behavioral detail. Missing return value description, error handling, and confirmation that projectId is required but not a parameter. Partially complete but with gaps.
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 all 3 parameters with descriptions (100% coverage). Description adds no new parameter information beyond stating the purpose. Baseline of 3 is appropriate; no enhancement but no detraction.
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?
Description clearly states 'Upload a new HTML version to an existing DesignPin module' with specific verb and resource. Auto-increment detail adds precision. Siblings are different tools, so no confusion.
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?
Description mentions 'Requires API key + projectId + moduleId' but projectId is not in input schema, which is inconsistent. It describes when to use ('push design iterations') but does not specify when not to use or compare with siblings. Adequate but with a notable gap.
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.2createShareLinklistCommentsuploadVersionScored across 3 tools
Each tool has a distinct purpose: creating share links, listing comments, and uploading versions. There is no overlap in functionality.
All tool names follow the same verb_noun pattern in camelCase (createShareLink, listComments, uploadVersion), making them predictable and easy to distinguish.
Three tools is a minimal but reasonable set for a focused server. It covers the core actions of sharing, versioning, and viewing feedback, though a few more could enhance utility.
The tool surface lacks key operations like adding or deleting comments, updating or deleting projects, and retrieving project details. Agents cannot perform a full review cycle without additional server capabilities.
Share prototypes for team review: publish HTML, reviewers pin notes, pull feedback back to apply.
Human feedback for AI agents: share HTML, get a live review link, read anchored notes as markdown.
Share prototypes as private links clients open without an account, attach specs, read comments.
Build and edit app screen mockups and clickable prototypes from your AI assistant.
