Uwear

Read official Uwear QA status, decision, and structured QA JSON for existing generation results. Call this after queue_generation_result_qa when the user asks to QA/check/validate/review generated outputs; summarize the structured decision and issues, not a manual view_image opinion.

FIRST tool to call for a new photoshoot only when the user has not supplied garment/outfit IDs or textual selectors such as tag names, saved ArtDirection names, location names, or outfit names. Opens the MCP app/gallery so the user can choose assets, add them to the Shoot Board, and press Confirm context. BLOCKS until the user confirms their selection. Do not use this when a no-UI path can resolve the request with list_tags/get_items_by_tag/list_garments or the ArtDirection lookup tools. Do not tell the user to drag assets into chat. If the user has no garments/outfits, ask them to attach garment/product images and use upload_garment_from_chat_file, upload_garment_from_public_url, or create_outfit_from_garment_ids before trying to create a brief. Do not request models when inventory shows avatars=0. Avatar/model is optional; only ask for one when the user wants a specific or consistent person. If they want a model and have none, ask for a person photo and use upload_avatar_from_chat_file, or use generate_avatar if they want Uwear to create a reusable model.

Save completed generate_avatar image results as one reusable avatar/model. Pass the identity-anchor result as generation_result_id and optional view results as additional_result_ids; each result fills the slot recorded in its avatar_creator.view metadata. Use only after generation finishes and the user chooses the candidates. Normal text-to-image results are not eligible.

Batch save reference images from chat attachments into the Files library. Keep file metadata in files[] and pass top-level image_file_1, image_file_2, etc. in the same order. No base64, no local paths. Use for mood boards, backgrounds, and other reference images that are not garments or avatars.

Create a canonical company template, or replace one by passing template_id with expected_revision. Send typed GenerationCommand objects; updates are complete replacements. This persists the template and does not generate images. Templates are single-generation presets. Use Production Workflows in the Automation workspace for reusable multi-step generation. Legacy batch Templates are read-only history and cannot be created, edited, or imported.

Universal hybrid retrieval across the user's visible Uwear library: garments, avatars/models, locations, ArtDirections, uploaded files, and generation results. Use this before opening the picker when the user describes assets or saved creative direction by exact name/SKU or natural language, e.g. 'SKU 42', 'urban art direction', 'summer denim', or 'studio model'. For saved outfits, retrieve matching garments first, then call list_outfits with clothing_item_ids or propose_outfits from the garment IDs. Returns stable typed IDs, ids_by_type, detail_tool/detail_arguments, and selection hints; for saved ArtDirections, use the returned art_direction_id in briefs. This combines indexed lexical matching with vector retrieval; do not run separate substring searches.

Submit a bug report or feature request to Uwear and return a private receipt. This creates a support record and can notify Uwear staff. Call it only when the user explicitly asks to submit, send, or report feedback, or after they confirm the exact summary. Never submit automatically because an error occurred, and never include the full conversation, credentials, secrets, raw provider payloads, or private URLs.

Update a company ArtDirection. System ArtDirections are read-only. When changing markdown directly, preserve the Variation Controls parser contract: reusable alternatives must be under `## Variation Controls`, not only in prose.

Replace the visible Uwear BriefProposal with a complete canonical command list. Edit commands[].input directly using the MCP-safe GenerationIntent fields and preserve every unchanged field and durable source. This is replacement state, not a partial diff. For video_garment_view_not_attached warnings, follow the capacity-aware remediation: never mix reference_attachments with img_ref_urls or append recommendations beyond remaining capacity. Include updated creative_context for photoshoot rewrites and explain the changed art direction. Webhook callback configuration is API-only.

Update a garment's metadata or patch its product photos. Send image changes through assets[] with front/back/side/detail roles. Provided front/back assets replace those singleton roles; provided side/detail assets are added. Omitted existing assets are preserved.

Patch the latest MontageProposal already shown in the UI. Use only for an existing video montage/reel/stitched sequence proposal; do not use this to modify a photoshoot brief. For photoshoot brief changes, call update_brief instead. Prefer `operations`, an ordered list of typed montage edits such as `clear_trim`, `remove`, `set_duration`, `set_trim_range`, `set_speed`, `set_muted`, `set_prompt`, `set_video_model`, `set_generate_audio`, `set_last_frame`, `set_aspect_ratio`, and `set_base_resolution`. Use `set_trim_range` for requests like 'use the second half', 'start at 3s', or 'trim from 3s to 6s'. Operations are applied in order to the current montage state. Legacy flat fields are still accepted as a compatibility shim. This updates the proposal only; it does not execute export or generation.

Update durable user preferences, photoshoot processes, or add a prompt. Treat all model fields as explicit model pins: leave model fields unset for normal backend defaults unless the user deliberately selected a specific model. The preferred way to save how a user generates is a template (save_template): a generation-preset template for reusable concrete single-shoot settings, a batch-workflow template for an ordered repeatable multi-shot flow — see the `Demo — …` system templates for worked examples. Use preferences for durable raw-text guidance that is not a concrete shoot setup.

Batch upload reusable avatars/models from person photos the user attached in chat. Each photo becomes the upper_body_front identity anchor. Keep names and optional user-given age_range, build, and height_cm in avatars[], then pass top-level image_file_1, image_file_2, etc. in the same order. Traits are never guessed. No base64, no local paths. Do not use ordinary text-to-image results as an upload fallback; use generate_avatar followed by save_generated_avatar for Uwear-created avatars. Use only when the user explicitly wants a specific or consistent person.

Batch upload garments from ChatGPT attachments. Defaults to background removal; pass processing_mode='none' to store original images as-is. Pass actual file objects only in top-level image_file_1, image_file_2, etc. Prefer garments[].assets with {asset_kind: full|detail, asset_view: front|back|side, image_file: 'image_file_N'}; exactly one full front is required, every full view is unique, and detail views can repeat. Do not rely on array position to pair assets; every asset must reference its exact top-level field name. No image_url here; use upload_garment_from_public_url for URLs. For local filesystem files, use prepare_local_garment_upload instead. No base64 and no local paths.

Queue a recoverable batch upload from public HTTP(S) image URLs and return an operation immediately. Retry with the exact same arguments to read the stable operation state; retries do not create another upload. Defaults to background removal; pass processing_mode='none' to store original images as-is. Prefer assets with {asset_kind: full|detail, asset_view: front|back|side, asset_url}; exactly one full front is required, every full view is unique, and detail views can repeat. For ChatGPT attachments, use upload_garment_from_chat_file instead. For local filesystem files, use prepare_local_garment_upload instead. No base64, chat file objects, or local paths.

Analyze any image using AI vision for manual inspection, debugging, visual description, or supplemental critique. Provide exactly one source: generation_result_id for a Shoot Board generation, uploaded_file_id for a Files item, or image_url for a public HTTPS image. Do not use this as the primary QA mechanism when the user asks to QA, quality-check, validate, review, approve/reject, or assess generated results; for QA requests use queue_generation_result_qa first, then read_generation_result_qa.