Tintin Tryon

Create try-on generation job

create_tryon_job

Generate an on-model try-on photo from a garment/product image URL (e.g. straight from an audit_store work order). Charges 1 credit (2K) or 2 credits (4K) from the account's studio credits. Requires an API key.

Input Schema

TableJSON Schema

Name	Required	Description
`model`	No	Preset model (default woman)
`prompt`	No	Optional styling instructions
`api_key`	No	API key if the client can't send an Authorization header
`resolution`	No	Output resolution: 2K costs 1 credit, 4K costs 2
`aspect_ratio`	No	Output aspect ratio, e.g. 3:4 (default)
`product_type`	No	Top \| Bottom \| Dress \| Full-body (default Top)
`model_image_url`	No	Optional: custom model reference photo URL
`garment_image_url`	Yes	Public URL of the garment/product photo

Output Schema

TableJSON Schema

Name	Required	Description
`poll`	No	How to retrieve the result
`error`	No	Machine-readable error code (only present on failures)
`job_id`	No	Generation job UUID — poll with get_job_status
`status`	No	Initial job state (usually queued)
`message`	No	Human-readable explanation of the failure
`resolution`	No	Output resolution the job will render at
`credits_charged`	No	Studio credits debited for this generation

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses significant non-obvious side effects: charging credits ('1 credit (2K) or 2 credits (4K)') and requiring an API key. This adds value beyond the annotations, which only indicate readOnlyHint=false and openWorldHint=true, and aligns with the mutating nature of the 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?

The description is two sentences, front-loaded with the core action, followed by concise cost and auth information. There is no redundant or filler content.

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

Completeness4/5

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

For a job-creation tool with 8 parameters and an output schema, the description covers purpose, cost, and prerequisites. However, it omits the asynchronous nature of job processing (e.g., that the job returns a status to poll via get_job_status) and how results are retrieved, which would be valuable for a complete context.

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?

The input schema already provides descriptions for all 8 parameters (100% coverage), so the tool description adds little parameter-level detail. It mentions the garment_image_url concept but does not enrich any parameter meanings beyond what the schema already states.

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 identifies the tool's function: 'Generate an on-model try-on photo from a garment/product image URL'. The verb 'Generate' and resource 'try-on photo' are specific and distinguish this from sibling tools like audit_store and create_preview_job, even though no sibling is explicitly named.

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 provides clear usage context by giving an example ('e.g. straight from an audit_store work order') and specifying prerequisites (API key, credit cost). However, it does not explicitly state when to use this versus create_preview_job or any exclusions, so it's clear but not fully comparative.

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

All Tintin Tryon tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct function: auditing a store, creating preview/tryon jobs, polling their statuses, checking credits, and getting seasonal guides. The preview vs tryon separation is clear, and audit_store explicitly references create_tryon_job, avoiding confusion.

Naming Consistency5/5

All tool names follow a strict verb_noun pattern (audit_store, create_preview_job, create_tryon_job, get_credits_balance, get_job_status, get_preview_status, get_seasonal_guide). Verb choices are consistent and the pattern is immediately predictable.

Tool Count5/5

Seven tools is well-scoped for this domain. Each tool serves a distinct part of the workflow—audit, preview, tryon generation, status polling, credit management, and seasonal guidance—with no redundancy or unnecessary extras.

Completeness5/5

The tool set covers the full lifecycle for both preview and tryon workflows: audit to identify needs, create jobs, poll status, and manage credits. The seasonal guide provides context for the audit. There are no obvious dead ends or missing operations for the stated purpose.

Resources

Need Help?