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购物造型师
模型上下文协议 (MCP) 服务器将 FindMine 强大的产品样式和装备推荐与 Claude 和其他 MCP 兼容应用程序相集成。
概述
此 MCP 服务器连接到 FindMine 的样式 API，并通过模型上下文协议将其功能开放给大型语言模型。它允许用户：
浏览产品和服装信息
获取特定产品的服装推荐
查找外观相似的产品
获得风格指导和时尚建议
Related MCP server: Kroger MCP Server
特征
资源
产品：带有
product:///URI 方案的详细产品信息外观：使用
look:///URI 方案提供完整的服装推荐
工具
get_style_guide ：获取详细的时尚建议和造型指南
get_complete_the_look ：获取产品的服装推荐
get_visually_similar ：查找外观相似的产品
提示
outfit_completion ：获取完整服装的造型建议
styling_guide ：获取全面的时尚造型指南
findmine_help ：了解如何使用 FindMine 的工具和资源
安装
选项 1：从 npm 安装
# Install and run directly (recommended)
npx findmine-mcp
# Or install globally
npm install -g findmine-mcp
findmine-mcp选项 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 |
| 默认区域代码 | 我们 |
| 默认语言代码 | 英文 |
| 启用响应缓存 | 真的 |
| 缓存生存时间（毫秒） | 3600000（1小时） |
| 设置为“开发”以获取示例数据 | - |
与 Claude Desktop 一起使用
服务器在安装过程中会自动配置 Claude Desktop。验证方法如下：
macOS：
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打开一个 Web 界面，您可以在其中与您的服务器进行交互。
开发模式
使用示例数据运行服务器：
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 patch发布到 Docker 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