Skip to main content
Glama
Sign In

Fashio AI

by com.fashiolabs
OverviewDiscussionsAdmin

Poll a Fashio generation job

get_generation

Returns a job's current state: {id, status: 'processing' | 'completed' | 'failed', resultUrls, errorMessage}; catalogue jobs also report packTotal, packCompleted and packFailed. Use it to poll a job from create_generation (its id) or create_catalog_job (its mediaItemId) every few seconds until status is no longer 'processing'; resultUrls then holds the output image/video URLs (for a catalogue job they fill in shot by shot). Free (no diamonds), but each poll is one request. 404 if the id does not exist or belongs to another account. Needs a valid Fashio API key (Bearer); every call counts toward the key's daily request cap (429 when reached, 401 for a missing or revoked key).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "get_generation"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesJob id: `id` from create_generation, or `mediaItemId` from create_catalog_job.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / id / description
      Added value: +"Job id: `id` from create_generation, or `mediaItemId` from create_catalog_job."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden, and it does: Bearer API key requirement, free of diamonds but each poll consumes one request against a daily cap, 429 on cap exhaustion, 401 on missing/revoked key, and 404 for unknown or cross-account ids. It also discloses that catalogue results fill in shot by shot, so partial resultUrls are expected rather than an error.

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?

Front-loaded with the return contract, then polling protocol, then cost/error semantics — a sensible order with no filler. It is dense and runs long with nested parentheses, but each clause carries operational information an agent needs.

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 no output schema and no annotations, the description must supply both the return contract and the safety/cost profile, and it does in full: status enum, result fields, catalogue counters, terminal state, and all relevant HTTP failure modes. An agent can implement the polling loop correctly from this text alone.

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 coverage is 100% and the schema's own id description already says "`id` from create_generation, or `mediaItemId` from create_catalog_job", which the prose essentially repeats. The baseline of 3 is appropriate since the schema, not the description, does the parameter documentation work.

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 first clause states the exact resource and return shape: "Returns a job's current state: {id, status: 'processing' | 'completed' | 'failed', resultUrls, errorMessage}", plus the catalogue-specific fields. This clearly separates it from the sibling creation tools (create_generation, create_catalog_job) whose outputs it polls.

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

Usage Guidelines5/5

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

It explicitly names both upstream producers and how to derive the argument from each ("its id" from create_generation, "its mediaItemId" from create_catalog_job), and states the loop condition: poll every few seconds until status is no longer 'processing'. The terminal condition and what to read afterwards (resultUrls) are both given, leaving nothing to inference.

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

All Fashio AI toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources