Skip to main content
Glama
myselfshravan

klydo-mcp

by myselfshravan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Klydo MCP Server

CI PyPI version Python 3.11+ License: MIT MCP Compatible

Fashion discovery MCP server for Indian Gen Z.

Enables AI assistants like Claude to search and discover fashion products from Klydo — India's Gen-Z quick tech fashion commerce platform based in Bangalore.

✨ Features

  • 🔍 Search Products — Search fashion items with filters (category, gender, price range)

  • 📦 Product Details — Get complete product info including images, sizes, colors, ratings

  • 🔥 Trending Products — Discover what's popular right now

  • 📝 Structured Logging — Debug-friendly logs with Loguru

  • ⚡ Fast & Cached — In-memory caching for quick responses

Related MCP server: Vistoya

🚀 Quick Start

Installation

Option 1: Install from PyPI (Recommended)

# Using pip
pip install klydo-mcp

# Or using pipx (isolated environment)
pipx install klydo-mcp

# Or using uvx (no installation needed)
uvx --from klydo-mcp klydo

Option 2: Install from Source

# Clone the repository
git clone https://github.com/myselfshravan/klydo-mcp.git
cd klydo-mcp

# Install dependencies with uv
uv sync

Usage with Claude Desktop

If installed via PyPI (pip/pipx)

Add to your Claude Desktop configuration:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "klydo": {
      "command": "klydo"
    }
  }
}

If using uvx (recommended for easy updates)

{
  "mcpServers": {
    "klydo": {
      "command": "uvx",
      "args": ["--from", "klydo-mcp", "klydo"]
    }
  }
}

If installed from source

{
  "mcpServers": {
    "klydo": {
      "command": "uv",
      "args": ["--directory", "/path/to/klydo-mcp", "run", "klydo"]
    }
  }
}

Then restart Claude Desktop.

Run Standalone

uv run klydo

🛠️ MCP Tools

search_products

Search for fashion products.

Parameter

Type

Description

query

string

required — Search terms (e.g., "black dress", "nike shoes")

category

string

Filter by category (e.g., "dresses", "shoes")

gender

string

Filter by gender ("men" or "women")

min_price

int

Minimum price in INR

max_price

int

Maximum price in INR

limit

int

Max results (default 10, max 50)

get_product_details

Get complete product information.

Parameter

Type

Description

product_id

string

required — Product ID from search results

Returns: Full details — images, sizes, colors, ratings, and purchase link.

get_trending

Discover what's hot rn 🔥

Parameter

Type

Description

category

string

Category filter

limit

int

Max results (default 10, max 50)

⚙️ Configuration

Copy .env.example to .env and customize:

# Request settings
KLYDO_REQUEST_TIMEOUT=30
KLYDO_CACHE_TTL=3600

# Debug mode (set to false in production)
KLYDO_DEBUG=false

# API token for klydo.in (required)
KLYDO_KLYDO_API_TOKEN=your-token

📁 Project Structure

klydo-mcp/
├── src/klydo/
│   ├── __init__.py
│   ├── server.py          # MCP server entry point
│   ├── config.py          # Configuration (Pydantic Settings)
│   ├── logging.py         # Loguru configuration
│   ├── models/
│   │   └── product.py     # Product, Price models
│   └── scrapers/
│       ├── base.py        # Scraper protocol (interface)
│       ├── cache.py       # In-memory cache with TTL
│       └── klydo_store.py # Klydo.in API client
├── tests/                 # Test suite
├── .github/workflows/     # CI/CD pipelines
├── pyproject.toml
└── README.md

🧪 Testing

# Run all tests
uv run pytest

# Run with verbose output
uv run pytest -v

# Run specific test file
uv run pytest tests/test_models.py

🔧 Development

# Install dev dependencies
uv sync --dev

# Run linting
uv run ruff check src/

# Format code
uv run ruff format src/

# Run the server locally
uv run klydo

🤝 Contributing

We welcome contributions! Please see our Contributing Guide for details.

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

🔐 Security

For security issues, please see our Security Policy.

📄 License

MIT License — see LICENSE for details.

🏢 About Klydo

Klydo is a Bangalore-based startup building quick tech fashion commerce for Gen-Z (18-32 age group). We're making fashion discovery seamless, fast, and accessible. This MCP server extends our platform to AI assistants, enabling natural language fashion search.

Backed by innovation. Built for Gen-Z. Made in India. 🇮🇳

Made with ❤️ in Bangalore, India

Available Tools

3 tools
get_product_detailsA

Get complete product information including all images, sizes, and specifications.

Args: product_id: The product ID from search results (the 'id' field)

Returns: Full product details with: - images: ALL product images from multiple angles (show all to users) - image_url: Primary product image - url: Buy link on klydo.in (may be null — only show when present) - sizes, colors, description, specifications - Returns None if product not found.

ParametersJSON Schema
NameRequiredDescriptionDefault
product_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It details return fields, null handling for 'url', an instruction to show all images, and notes that None is returned for missing products. This fully discloses behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args and Returns sections. It is slightly verbose but every sentence adds value. Could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one parameter, the description covers input, output, and edge cases. The presence of an output schema does not reduce need for description, and the description provides helpful usage hints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, but description compensates by explaining that product_id is 'The product ID from search results (the 'id' field)'. This adds meaning beyond the schema type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/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 complete product information including all images, sizes, and specifications.' The verb 'Get' and resource 'product details' are specific. Implicitly distinguishes from sibling tools (get_trending, search_products) by focusing on a single product ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies that product_id comes from search results, providing context for when to use the tool. It also notes return behavior (None if not found). However, it does not explicitly compare with siblings or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_productsA

Search for fashion products on Klydo.

Args: query: Search terms (e.g., "black dress", "nike shoes", "cotton kurta") category: Filter by category (e.g., "dresses", "shoes", "tshirts", "kurtas") gender: Filter by gender ("men" or "women") min_price: Minimum price in INR (e.g., 500) max_price: Maximum price in INR (e.g., 2000) limit: Maximum number of results (default 10, max 50)

Returns: List of matching products. Each product has: - image_url: Direct CDN image link (always show this) - url: Buy link on klydo.in (may be null — only show when present) - price, brand, name, category

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
categoryNo
genderNo
min_priceNo
max_priceNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses return structure, null conditions for url, and search behavior. Adequate for a read-only search tool.

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?

Well-structured with Args and Returns sections, front-loaded with purpose. Every sentence is informative, no fluff. Concise yet comprehensive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists and description explains return fields thoroughly. Covers all aspects of a search tool with multiple filters. Complete and self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage on parameters. Description compensates fully with detailed explanations, examples, and defaults for each of the 6 parameters, adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states tool searches for fashion products on Klydo, with specific examples. Distinguishes from sibling tools like get_product_details and get_trending by focusing on search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description provides clear usage context with examples for each filter parameter. Lacks explicit when-not or alternative tool guidance, but sufficiently implies search vs details/trending.

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.

  1. 3 tool updatesv0.1.6
    • First observedget_product_details
    • First observedget_trending
    • First observedsearch_products
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: searching, getting trending products, and retrieving full product details. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_product_details, get_trending, search_products), making it easy to predict tool function.

Tool Count5/5

Three tools is appropriate for a focused fashion product server: search, trending, and details. No unnecessary bloat or missing essentials.

Completeness4/5

The set covers core operations (search, browse trending, view details). Minor gap: no explicit way to list categories or brands, but search and trending cover most use cases.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers