Skip to main content
Glama
enesjakozh
findmine

FindMine Shopping Stylist

Official
by findmine
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

FindMine Shopping Stylist

A Model Context Protocol (MCP) server that integrates FindMine's powerful product styling and outfitting recommendations with Claude and other MCP-compatible applications.

Overview

This MCP server connects to FindMine's styling API and exposes its functionality to Large Language Models through the Model Context Protocol. It allows users to:

  • Browse product and outfit information

  • Get outfit recommendations for specific products

  • Find visually similar products

  • Access style guidance and fashion advice

Related MCP server: Kroger MCP Server

Features

Resources

  • Products: Detailed product information with product:/// URI scheme

  • Looks: Complete outfit recommendations with look:/// URI scheme

Tools

  • get_style_guide: Access detailed fashion advice and styling guidelines

  • get_complete_the_look: Get outfit recommendations for a product

  • get_visually_similar: Find visually similar products

Prompts

  • outfit_completion: Get styling advice for complete outfits

  • styling_guide: Access comprehensive fashion styling guidelines

  • findmine_help: Learn how to use FindMine's tools and resources

Installation

Option 1: Install from npm

# Install and run directly (recommended)
npx findmine-mcp

# Or install globally
npm install -g findmine-mcp
findmine-mcp

Option 2: Run with Docker

docker run -e FINDMINE_APP_ID=your_app_id findmine/mcp-server:latest

Option 3: Clone and build from source

# 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

Configuration

Environment Variables

Variable

Description

Default

FINDMINE_API_URL

FindMine API base URL

https://api.findmine.com

FINDMINE_APP_ID

Your FindMine application ID

DEMO_APP_ID

FINDMINE_API_VERSION

API version to use

v3

FINDMINE_DEFAULT_REGION

Default region code

us

FINDMINE_DEFAULT_LANGUAGE

Default language code

en

FINDMINE_CACHE_ENABLED

Enable response caching

true

FINDMINE_CACHE_TTL_MS

Cache time-to-live in ms

3600000 (1 hour)

NODE_ENV

Set to "development" for sample data

-

Usage with Claude Desktop

The server automatically configures Claude Desktop during installation. To verify:

macOS:

cat ~/Library/Application\ Support/Claude/claude_desktop_config.json

Windows:

type %APPDATA%\Claude\claude_desktop_config.json

Development

Available Scripts

# Build and watch
npm run build              # Build the project
npm run watch             # Watch for changes and rebuild
npm run typecheck         # Run TypeScript type checking

# Testing
npm test                  # Run tests in watch mode
npm run test:run          # Run tests once
npm run test:coverage     # Run tests with coverage report

# Code quality
npm run lint              # Run ESLint
npm run lint:fix          # Run ESLint with auto-fix
npm run format            # Format code with Prettier
npm run format:check      # Check code formatting

# Development tools
npm run inspector         # Run MCP inspector (http://localhost:5173)

Testing

This project uses Vitest for testing. Tests are located in __tests__/ directories alongside source files.

# Run tests in watch mode
npm test

# Run tests once (useful for CI)
npm run test:run

# Generate coverage report
npm run test:coverage

Code Quality

Before committing code:

# Run all checks
npm run typecheck && npm run lint && npm run format:check && npm run test:run

The project uses:

  • ESLint for linting with TypeScript support

  • Prettier for code formatting

  • Vitest for testing

  • GitHub Actions for CI/CD

Development Mode

Run the server with sample data:

NODE_ENV=development npm run build && node build/index.js

Customizing the Style Guide

The style guide can be customized to match your brand's specific styling philosophies and fashion guidance. To customize the style guide:

  1. Locate the style guides in src/content/style-guides.ts

  2. Modify the content for each category (general, color_theory, body_types, etc.)

  3. Add new categories by extending the styleGuides object

  4. Customize occasion-specific and seasonal advice

Example of adding a custom style guide category:

// In src/content/style-guides.ts
export 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
`
};

For complete customization, you can modify the entire get_style_guide handler in src/handlers/tools.ts.

Project Structure

src/
├── index.ts              # MCP server bootstrap and initialization
├── config.ts             # Environment configuration
├── api/                  # FindMine API client
│   └── findmine-client.ts
├── handlers/             # MCP protocol handlers
│   ├── tools.ts          # Tool execution handlers
│   ├── resources.ts      # Resource handlers
│   └── prompts.ts        # Prompt handlers
├── tools/                # Tool definitions with MCP annotations
│   └── index.ts
├── schemas/              # Zod validation schemas
│   ├── tool-inputs.ts    # Input validation for all tools
│   └── index.ts
├── content/              # Static content
│   └── style-guides.ts   # Style guide content
├── prompts/              # Prompt definitions
│   ├── findmine-help.ts
│   ├── outfit-completion.ts
│   ├── styling-guide.ts
│   └── index.ts
├── services/             # Business logic layer
│   └── findmine-service.ts
├── types/                # TypeScript type definitions
│   ├── findmine-api.ts
│   └── mcp.ts
└── utils/                # Utility functions and helpers
    ├── cache.ts
    ├── formatters.ts
    ├── logger.ts
    ├── mock-data.ts
    └── resource-mapper.ts

Technical Details

This server is built with:

  • MCP SDK 1.24.2 with full spec compliance (2025-11-25)

  • Tool annotations for read-only, destructive, and open-world hints

  • Zod validation for all tool inputs

  • Modular architecture with separated concerns

  • 100% test coverage on utility functions

API Examples

Get Style Guide

{
  "name": "get_style_guide",
  "arguments": {
    "category": "color_theory",
    "occasion": "wedding"
  }
}

Get Complete the Look

{
  "name": "get_complete_the_look",
  "arguments": {
    "product_id": "P12345",
    "product_color_id": "C789"
  }
}

Get Visually Similar Products

{
  "name": "get_visually_similar",
  "arguments": {
    "product_id": "P12345",
    "product_color_id": "C789",
    "limit": 5
  }
}

Publishing

Publishing to npm

# Login to npm
npm login

# Publish the package
npm publish

# Update the version for future releases
npm version patch

Publishing to 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

License

This project is licensed under the MIT License.

Available Tools

3 tools
get_complete_the_lookC

Get outfit recommendations for a product

ParametersJSON Schema
NameRequiredDescriptionDefault
api_versionNoAPI version to use (overrides FINDMINE_API_VERSION env var)
customer_genderNoCustomer gender (M = Men, W = Women, U = Unknown)
customer_idNoCustomer ID for personalized recommendations
in_stockNoWhether the product is in stock
on_saleNoWhether the product is on sale
product_color_idNoColor ID of the product (if applicable)
product_idYesID of the product
return_pdp_itemNoWhether to return the original product in the response
session_idNoSession 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
NameRequiredDescriptionDefault
categoryNoCategory of styling advice (e.g., 'color_theory', 'body_types', 'casual_outfits', 'formal_outfits', 'seasonal')general
fashion_seasonNoFashion season to get styling advice for (e.g., 'spring_summer', 'fall_winter', 'resort', 'transition')
occasionNoSpecific 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
NameRequiredDescriptionDefault
api_versionNoAPI version to use (overrides FINDMINE_API_VERSION env var)
customer_genderNoCustomer gender (M = Men, W = Women, U = Unknown)
customer_idNoCustomer ID for personalized recommendations
limitNoMaximum number of products to return
offsetNoOffset for pagination
product_color_idNoColor ID of the product (if applicable)
product_idYesID of the product
session_idNoSession 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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
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
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Kroger MCP Server

    CupOfOwls
    A
    license
    A
    quality
    A
    maintenance
    A 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.
    30
    70
    MIT

  • Vistoya

    vistoya
    A
    license
    Not graded
    quality
    D
    maintenance
    The 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.
    14
    MIT

  • MCP Merchant Scout

    davillafer
    A
    license
    A
    quality
    D
    maintenance
    An 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.
    4
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/findmine/findmine-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server