A
licenseB
qualityD
maintenanceMCP server that integrates with Shopify API, allowing Claude Desktop users to retrieve and manipulate product information from Shopify stores.
5
1
MIT
FindMine Shopping Stylist
Officialby findmine
FindMine 쇼핑 스타일리스트
FindMine의 강력한 제품 스타일링 및 의류 추천 기능을 Claude 및 기타 MCP 호환 애플리케이션과 통합하는 MCP(Model Context Protocol) 서버입니다.
개요
이 MCP 서버는 FindMine의 스타일링 API에 연결하고 모델 컨텍스트 프로토콜을 통해 대규모 언어 모델(Large Language Models)에 해당 기능을 제공합니다. 사용자는 다음을 수행할 수 있습니다.
제품 및 의상 정보 탐색
특정 제품에 대한 의상 추천을 받으세요
시각적으로 유사한 제품 찾기
스타일 가이드 및 패션 조언에 액세스하세요
Related MCP server: Kroger MCP Server
특징
자원
제품 :
product:///URI 체계를 사용한 자세한 제품 정보룩 : look
look:///URI 체계를 활용한 완벽한 의상 추천
도구
get_style_guide : 자세한 패션 조언과 스타일링 가이드라인을 확인하세요
get_complete_the_look : 제품에 대한 의상 추천을 받으세요
get_visually_similar : 시각적으로 유사한 제품 찾기
프롬프트
outfit_completion : 완벽한 옷차림을 위한 스타일링 조언을 받으세요
styling_guide : 포괄적인 패션 스타일링 가이드라인을 확인하세요
findmine_help : FindMine의 도구와 리소스를 사용하는 방법을 알아보세요
설치
옵션 1: npm에서 설치
지엑스피1
옵션 2: Docker로 실행
docker run -e FINDMINE_APP_ID=your_app_id findmine/mcp-server:latest옵션 3: 소스에서 복제 및 빌드
# Clone the repository
git clone https://github.com/findmine/findmine-mcp.git
cd findmine-mcp
# Install dependencies
npm install
# Build the server
npm run build
# For development with auto-rebuild
npm run watch구성
환경 변수
변하기 쉬운 | 설명 | 기본 |
| FindMine API 기본 URL | |
| FindMine 애플리케이션 ID | 데모 앱 ID |
| 사용할 API 버전 | v3 |
| 기본 지역 코드 | 우리를 |
| 기본 언어 코드 | 엔 |
| 응답 캐싱 활성화 | 진실 |
| 캐시 수명(ms) | 3600000(1시간) |
| 샘플 데이터의 경우 "개발"로 설정 | - |
Claude Desktop과 함께 사용
서버는 설치 중에 Claude Desktop을 자동으로 구성합니다. 확인하려면 다음을 수행하세요.
맥OS:
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json윈도우:
type %APPDATA%\Claude\claude_desktop_config.json개발
MCP 검사관
MCP Inspector는 서버를 테스트하기 위한 개발 도구입니다.
npm run inspector이렇게 하면 http://localhost:5173 에서 웹 인터페이스가 열리고 여기서 서버와 상호 작용할 수 있습니다.
개발 모드
샘플 데이터로 서버를 실행합니다.
NODE_ENV=development npm run build && node build/index.js스타일 가이드 사용자 정의
스타일 가이드는 브랜드의 특정 스타일링 철학과 패션 트렌드에 맞춰 맞춤 설정할 수 있습니다. 스타일 가이드를 맞춤 설정하려면 다음 단계를 따르세요.
src/index.ts에서 스타일 가이드를 찾으세요(styleGuides검색)각 카테고리(
general,color_theory,body_types등)의 콘텐츠를 수정합니다.styleGuides객체를 확장하여 새로운 카테고리를 추가합니다.상황에 맞는 맞춤형 조언과 계절별 조언을 제공합니다.
사용자 정의 스타일 가이드 범주를 추가하는 예:
// In src/index.ts
const styleGuides: Record<string, string> = {
// Existing categories...
// Add your custom category
your_brand_style: `# Your Brand Style Guide
## Brand Aesthetic
- Key elements of your brand's visual identity
- Core style principles
- Signature looks and combinations
## Your Brand's Styling Do's
- Brand-specific styling recommendations
- Preferred color combinations
- Signature styling techniques
## Your Brand's Styling Don'ts
- Combinations to avoid
- Styling approaches that don't align with brand identity
- Common styling mistakes to avoid
`
};완벽한 사용자 정의를 위해 src/index.ts 에서 get_style_guide 핸들러 전체를 수정할 수 있습니다.
프로젝트 구조
src/index.ts: 주요 MCP 서버 구현src/api/: FindMine API 클라이언트src/services/: 비즈니스 로직 및 서비스 계층src/types/: TypeScript 유형 정의src/utils/: 유틸리티 함수 및 도우미
API 예제
스타일 가이드 받기
{
"name": "get_style_guide",
"arguments": {
"category": "color_theory",
"occasion": "wedding"
}
}완벽한 룩을 완성하세요
{
"name": "get_complete_the_look",
"arguments": {
"product_id": "P12345",
"product_color_id": "C789"
}
}시각적으로 유사한 제품 얻기
{
"name": "get_visually_similar",
"arguments": {
"product_id": "P12345",
"product_color_id": "C789",
"limit": 5
}
}출판
npm에 게시하기
# Login to npm
npm login
# Publish the package
npm publish
# Update the version for future releases
npm version patchDocker Hub에 게시
# Build the Docker image
docker build -t findmine/mcp-server:latest .
# Login to Docker Hub
docker login
# Push the image
docker push findmine/mcp-server:latest특허
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다.
Available Tools
3 toolsget_complete_the_lookC
Get outfit recommendations for a product
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_version | No | API version to use (overrides FINDMINE_API_VERSION env var) | |
| customer_gender | No | Customer gender (M = Men, W = Women, U = Unknown) | |
| customer_id | No | Customer ID for personalized recommendations | |
| in_stock | No | Whether the product is in stock | |
| on_sale | No | Whether the product is on sale | |
| product_color_id | No | Color ID of the product (if applicable) | |
| product_id | Yes | ID of the product | |
| return_pdp_item | No | Whether to return the original product in the response | |
| session_id | No | Session ID for tracking and personalization |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('Get outfit recommendations') without mentioning any behavioral traits such as rate limits, authentication needs, response format, or potential side effects. For a tool with 9 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get outfit recommendations for a product.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence earns its place by directly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits, usage guidelines, and output details, which are crucial for an AI agent to invoke the tool correctly. The description alone is insufficient to provide a full understanding of how to use this tool effectively.
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%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions, default behaviors, or usage examples. With high schema coverage, the baseline score is 3, reflecting that the description doesn't compensate but also doesn't detract from the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get outfit recommendations for a product.' It specifies the verb ('Get') and resource ('outfit recommendations'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_style_guide' or 'get_visually_similar,' which would require more specific language about the type of recommendations provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_style_guide' or 'get_visually_similar,' nor does it specify scenarios or prerequisites for usage. This lack of context leaves the agent to infer usage based on the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_style_guideB
Get styling advice and tips for creating effective fashion recommendations
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category of styling advice (e.g., 'color_theory', 'body_types', 'casual_outfits', 'formal_outfits', 'seasonal') | general |
| fashion_season | No | Fashion season to get styling advice for (e.g., 'spring_summer', 'fall_winter', 'resort', 'transition') | |
| occasion | No | Specific occasion to get styling advice for (e.g., 'office', 'wedding', 'date_night', 'casual_friday') |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool provides 'advice and tips,' implying a read-only, informational function, but doesn't clarify aspects like whether it requires authentication, has rate limits, or returns structured data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get styling advice and tips for creating effective fashion recommendations.' It's front-loaded with the core purpose and avoids unnecessary words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on output format, error handling, or integration with sibling tools. Without an output schema, the description should ideally hint at return values, but it doesn't, leaving room for improvement in completeness.
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%, with clear descriptions for all three parameters (category, fashion_season, occasion). The description doesn't add any extra meaning beyond the schema, such as explaining how parameters interact or providing usage examples. Since the schema already documents parameters well, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get styling advice and tips for creating effective fashion recommendations.' It specifies the verb 'Get' and the resource 'styling advice and tips,' making the function understandable. However, it doesn't differentiate from sibling tools like 'get_complete_the_look' or 'get_visually_similar,' which likely offer different types of fashion-related outputs, so it misses full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or specify contexts where this tool is preferred, such as for general advice versus specific outfit generation. Without any usage context, the agent lacks direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_visually_similarC
Get visually similar products
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_version | No | API version to use (overrides FINDMINE_API_VERSION env var) | |
| customer_gender | No | Customer gender (M = Men, W = Women, U = Unknown) | |
| customer_id | No | Customer ID for personalized recommendations | |
| limit | No | Maximum number of products to return | |
| offset | No | Offset for pagination | |
| product_color_id | No | Color ID of the product (if applicable) | |
| product_id | Yes | ID of the product | |
| session_id | No | Session ID for tracking and personalization |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get visually similar products' implies a read operation, but it doesn't disclose details like whether this is a search or recommendation system, potential rate limits, authentication needs, or what the return format might be. The description is too minimal to provide meaningful behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Get visually similar products' is front-loaded and to the point. Every word earns its place, making it highly concise and well-structured for quick understanding, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain the tool's domain (e.g., e-commerce, fashion), how results are returned, or key behavioral aspects. For a tool with rich parameters but minimal description, this leaves significant gaps in understanding for an AI agent.
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 the schema already documents all 8 parameters thoroughly. The description adds no additional meaning beyond what's in the schema, such as explaining how 'product_id' relates to visual similarity or how parameters interact. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get visually similar products' clearly states the verb ('Get') and resource ('visually similar products'), but it's vague about scope and doesn't distinguish from sibling tools like 'get_complete_the_look' or 'get_style_guide'. It doesn't specify whether this is for fashion, retail, or another domain, leaving the purpose somewhat ambiguous despite having a clear basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_complete_the_look' or 'get_style_guide'. The description lacks context about scenarios (e.g., for product recommendations, visual search) or prerequisites, leaving the agent to infer usage based on the tool name alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v1.0.0- First observed
get_complete_the_look - First observed
get_style_guide - First observed
get_visually_similar
TDQS
B3/5.0
Scored across 3 tools
Disambiguation4/5
The three tools have distinct purposes: get_complete_the_look focuses on outfit recommendations, get_style_guide provides styling advice and tips, and get_visually_similar finds visually similar products. While get_complete_the_look and get_visually_similar both involve product recommendations, their descriptions clarify that one is for outfits and the other for visual similarity, minimizing overlap. However, the boundary between get_complete_the_look and get_style_guide could be slightly ambiguous as both relate to fashion recommendations, but the descriptions help differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get_' as the prefix, followed by descriptive phrases (complete_the_look, style_guide, visually_similar). This uniformity makes the tools predictable and easy to understand, with no deviations in naming conventions or styles.
Tool Count3/5
With only 3 tools, the server feels thin for a shopping stylist domain, which might involve more operations like searching products, filtering by categories, or managing user preferences. While the tools cover key aspects (recommendations, advice, similarity), the limited count could restrict functionality and lead to gaps in handling complex styling tasks.
Completeness2/5
The tool surface is significantly incomplete for a shopping stylist. It lacks essential operations such as searching for products, retrieving product details, filtering by attributes (e.g., color, size), or handling user interactions (e.g., saving preferences, history). The existing tools focus only on recommendations and advice, leaving major gaps that could cause agent failures in real-world styling scenarios.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Get recommended by Amazon's AI. Hosted MCP server for Amazon listing compliance & generation.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Related MCP Servers
- AlicenseAqualityBmaintenanceA FastMCP server that provides AI assistants like Claude with seamless access to Kroger's grocery shopping functionality through the Model Context Protocol, enabling store finding, product searching, and cart management.3060 PyPI74MIT
- AlicenseNot gradedqualityDmaintenanceThe Vistoya MCP server gives AI agents direct access to a curated, multi-brand fashion catalog. Agents can search by structured filters, discover products through natural language, find similar items, and retrieve full product details — all over a single Streamable HTTP connection.8 npmMIT
- AlicenseAqualityDmaintenanceAn MCP server that wraps the Universal Commerce Protocol (UCP) Discovery and Catalog capabilities, letting you search and compare products across UCP merchants directly from Claude.4MIT