MCP Server added

[kailashahirwar]

Description

Introduces an MCP server for OpenTryOn, built on FastMCP 3.x, that makes every model in the toolkit — Virtual Try-On, Image Generation/Editing, Video Generation, Multimodal Understanding (Kimi, LLaVA-NeXT), and Background Removal — available as an MCP tool for agents in Claude Desktop, Cursor, or any other MCP client.

Rather than hand-writing a wrapper function + JSON schema per model, tools are generated dynamically from the same tryon.cli.registry data that powers the opentryon CLI. This produces 27 tools at launch and means any model added to the registry going forward shows up as an MCP tool automatically, with zero MCP-server changes required.

Related Issue

#89

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Performance improvement
• Code refactoring (no functional changes)
• Test addition or update
• CI/CD or build configuration

Component Affected

• Virtual Try-On (Nova Canvas / Kling AI / Segmind)
• Image Generation (Nano Banana / FLUX.2 / Luma AI / OpenAI)
• Video Generation (Luma AI / OpenAI Sora)
• Preprocessing (Segmentation / Pose Estimation)
• Datasets Module
• AI Agents
• Demos / Web Apps
• CLI Tools
• Documentation
• Other: MCP Server (Model Context Protocol)

Changes Made

• Built mcp-server/ on FastMCP 3.4+ with a data-driven design from the ground up: no hand-written per-model Tool() definitions or manual dispatch chain
• mcp-server/server.py: dynamically builds one MCP tool per (service, model) pair straight from tryon.cli.registry.SERVICES — real inspect.Signatures are generated per model (correct types, Literal[...] enums for choices, required/optional fields) so FastMCP produces accurate JSON schemas with no hand-written duplication
• Added tryon.cli.runner.invoke_model(): a kwargs-based, non-argv sibling of run_service(), shared by both the CLI and the MCP server so they can never drift apart; always returns a structured {"success": ...} dict instead of raising
• Refactored run_service() / _split_kwargs() / result-saving logic in tryon/cli/runner.py to work off plain dicts so both entry points share the exact same execution path (no behavior change for the CLI)
• Added two discovery tools: list_opentryon_tools() (per-model tool name, required env vars, live configured/not-configured status) and opentryon_status() (human-readable readiness report), both generated from the registry so they can't go stale
• Every generated tool supports dry_run (preview the resolved adapter call, no API/GPU cost) and output_dir, matching the CLI's --dry-run / --output-dir flags
• mcp-server/config.py: loads the repo's .env and derives per-model readiness from each model's env_hint, instead of a hand-maintained list of API keys
• Added mcp-server/test_server.py: offline test suite (no network/API keys needed) covering registry↔tool parity, schema correctness (required fields, choices → enum), dry-run calls across all six services, and alt_method_on_image switching (veo / sora / luma-video)
• Added Claude Desktop and Cursor config examples, plus a fastmcp Client-based example_usage.py
• Updated mcp-server/README.md, root README.md, and CHANGELOG.md

Testing

• I have tested these changes locally

• I have added/updated tests that prove my fix is effective or my feature works

• New and existing unit tests pass locally with my changes

• Ran mcp-server/test_server.py end to end: 29 tools registered (27 models + 2 discovery tools), every registry model has a matching tool, schemas have correct required/optional fields and choices → enum, dry-run calls resolve correctly across vton/generate/edit/understand/video-generate/bg-remove, alt_method_on_image correctly switches to image-to-video only when an image is supplied, and unknown service/model + missing-local-extra cases return structured errors instead of crashing

• Verified full protocol-level round trips with fastmcp.Client (in-memory and real stdio subprocess), including a real tool call against the live .env

• Verified python server.py boots cleanly on stdio transport

• Re-ran the existing tests/test_cli.py suite (including a real BFL FLUX VTO API call) after refactoring tryon/cli/runner.py to confirm zero behavior change on the CLI side

Test Environment

• Python Version: 3.10
• OS: macOS
• GPU: N/A

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published

Screenshots / Examples

cd mcp-server
pip install -r requirements.txt
python server.py   # stdio transport, ready for Claude Desktop / Cursor

from fastmcp import Client

async with Client("server.py") as client:
    result = await client.call_tool("vton_flux_vto", {
        "person": "model.jpg",
        "garment": "garment.jpg",
        "dry_run": True,
    })
    print(result.data)

Additional Notes

Full tool list (grouped by service) and architecture notes are in mcp-server/README.md.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.