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
Estilista de compras de FindMine
Un servidor de Protocolo de Contexto de Modelo (MCP) que integra las potentes recomendaciones de estilo y equipamiento de productos de FindMine con Claude y otras aplicaciones compatibles con MCP.
Descripción general
Este servidor MCP se conecta a la API de estilos de FindMine y expone su funcionalidad a grandes modelos de lenguaje mediante el Protocolo de Contexto de Modelo. Permite a los usuarios:
Explorar información sobre productos y conjuntos
Obtenga recomendaciones de atuendos para productos específicos
Encuentre productos visualmente similares
Accede a orientación sobre estilo y consejos de moda.
Related MCP server: Kroger MCP Server
Características
Recursos
Productos : Información detallada del producto con el esquema URI
product:///Looks : Recomendaciones completas de atuendos con el esquema URI
look:///
Herramientas
get_style_guide : Accede a consejos de moda detallados y pautas de estilo.
get_complete_the_look : Obtén recomendaciones de atuendos para un producto
get_visually_similar : Encuentra productos visualmente similares
Indicaciones
outfit_completion : Obtén consejos de estilo para conjuntos completos
guía_de_estilo : Acceda a pautas completas de estilo de moda
findmine_help : Aprenda a utilizar las herramientas y recursos de FindMine
Instalación
Opción 1: Instalar desde npm
# Install and run directly (recommended)
npx findmine-mcp
# Or install globally
npm install -g findmine-mcp
findmine-mcpOpción 2: Ejecutar con Docker
docker run -e FINDMINE_APP_ID=your_app_id findmine/mcp-server:latestOpción 3: Clonar y compilar desde la fuente
# 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 watchConfiguración
Variables de entorno
Variable | Descripción | Por defecto |
| URL base de la API de FindMine | |
| Su ID de aplicación de FindMine | ID DE APLICACIÓN DEMO |
| Versión de API a utilizar | versión 3 |
| Código de región predeterminado | a nosotros |
| Código de idioma predeterminado | en |
| Habilitar el almacenamiento en caché de respuestas | verdadero |
| Tiempo de vida de la caché en ms | 3600000 (1 hora) |
| Establecer en "desarrollo" para datos de muestra | - |
Uso con Claude Desktop
El servidor configura automáticamente Claude Desktop durante la instalación. Para verificar:
macOS:
cat ~/Library/Application\ Support/Claude/claude_desktop_config.jsonVentanas:
type %APPDATA%\Claude\claude_desktop_config.jsonDesarrollo
Inspector de MCP
El Inspector MCP es una herramienta de desarrollo para probar su servidor:
npm run inspectorEsto abrirá una interfaz web en http://localhost:5173 donde podrá interactuar con su servidor.
Modo de desarrollo
Ejecute el servidor con datos de muestra:
NODE_ENV=development npm run build && node build/index.jsPersonalización de la Guía de Estilo
La guía de estilo se puede personalizar para que se ajuste a las filosofías de estilo y las directrices de moda específicas de su marca. Para personalizar la guía de estilo:
Localice las guías de estilo en
src/index.ts(busquestyleGuides)Modificar el contenido de cada categoría (
general,color_theory,body_types, etc.)Agregue nuevas categorías ampliando el objeto
styleGuidesPersonalice el asesoramiento según la ocasión y la temporada.
Ejemplo de cómo agregar una categoría de guía de estilo personalizada:
// 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
`
};Para una personalización completa, puede modificar todo el controlador get_style_guide en src/index.ts .
Estructura del proyecto
src/index.ts: Implementación del servidor MCP principalsrc/api/: Cliente de API de FindMinesrc/services/: Lógica de negocios y capa de serviciosrc/types/: definiciones de tipos de TypeScriptsrc/utils/: Funciones de utilidad y ayudantes
Ejemplos de API
Obtener la guía de estilo
{
"name": "get_style_guide",
"arguments": {
"category": "color_theory",
"occasion": "wedding"
}
}Completa el look
{
"name": "get_complete_the_look",
"arguments": {
"product_id": "P12345",
"product_color_id": "C789"
}
}Obtenga productos visualmente similares
{
"name": "get_visually_similar",
"arguments": {
"product_id": "P12345",
"product_color_id": "C789",
"limit": 5
}
}Publicación
Publicación en npm
# Login to npm
npm login
# Publish the package
npm publish
# Update the version for future releases
npm version patchPublicación en 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:latestLicencia
Este proyecto está licenciado bajo la licencia 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