spriteship

Retry an unusable AI result

retry_unusable_result

Quality Retry is the subscription compensation for AI art that invents details, ignores the request, or arrives unusable, letting the user try again without asking support for a credit refund. Costs ONE quality retry and ZERO credits; it is not a refund and preserves the original. Use get_subscription_allowances first and proceed only when features.retry is true; explain the purpose/cost and obtain approval before confirmed=true. This is distinct from retry_job (technical recovery) and ordinary paid revision. Do not use for arbitrary new ideas or imported still images. Persist requestId and reuse it after network errors; a returned allowance requires a new requestId.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	Yes	Use character_pose with poseId for a completed generated pose with saved inputs, creating a new pose on the same character. Extracted/mirrored poses are excluded. Use character_animation for ordinary character animations and completed standalone or automatic setup 360 video turns. Setup requires a completed owned job with an approved review and retained padded input. Turn retries create a new standalone turn without replacing approved poses or rerunning dependent animations. Grid-sheet rotations and unidentifiable sources are excluded.
`poseId`	No
`reason`	Yes
`entityId`	Yes
`confirmed`	No	True only after the user approved using one quality retry.
`requestId`	Yes
`revisionId`	No
`animationId`	No
`issueDetails`	No	Required for reason=other. Describe the unusable result in up to 1000 characters; stored for support, not sent to AI or used to change the original prompt. Preserve on requestId replay.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 11, 2026

changedInput schema / properties / kind / description

Previous value: -"Use character_animation for ordinary character animations and completed standalone 360 video turns. Turn retries preserve the saved seed pose/strategy in a new turn; internal setup captures and grid-sheet rotations are excluded."New value: +"Use character_pose with poseId for a completed generated pose with saved inputs, creating a new pose on the same character. Extracted/mirrored poses are excluded. Use character_animation for ordinary character animations and completed standalone or automatic setup 360 video turns. Setup requires a completed owned job with an approved review and retained padded input. Turn retries create a new standalone turn without replacing approved poses or rerunning dependent animations. Grid-sheet rotations and unidentifiable sources are excluded."

changedInput schema / properties / kind / enum

Previous value: -[
-  "asset_image",
-  "asset_animation",
-  "character_image",
-  "character_animation"
-]New value: +[
+  "asset_image",
+  "asset_animation",
+  "character_image",
+  "character_animation",
+  "character_pose"
+]

addedInput schema / properties / poseId
```
Added value: +{
+  "type": "string"
+}
```

AddedSep 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare the safety envelope (non-read-only, non-destructive, non-idempotent, open-world). The description adds substantial context beyond that: cost is one quality retry and zero credits, it is not a refund, it preserves the original, and requestId must be persisted/reused after network errors while a spent allowance requires a new requestId.

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 what the tool is and its cost, and every clause carries information. It is dense and slightly run-on across cost, prerequisites, exclusions, and replay semantics, but no sentence is filler.

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 complex, 9-param mutation with no output schema, the description covers purpose, cost, prerequisite checks, approval gating, requestId replay, and exclusions. The remaining gap is per-parameter meaning for the id fields, which is not resolved anywhere.

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 only 33% across 9 params, so the description must compensate. It adds real meaning for requestId (persist/reuse, new id when allowance returned) and confirmed (approval gate), but leaves entityId, poseId, revisionId, and animationId undocumented in either place. kind and issueDetails are already well covered by 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?

States a specific verb+resource with a clear scope: a subscription 'Quality Retry' compensation for unusable AI art, distinct from a refund. It explicitly separates itself from retry_job (technical recovery) and ordinary paid revision, so an agent can pick the right sibling without opening schemas.

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?

Gives explicit when-to-use (hallucinated/ignored/unusable output), a prerequisite sequence (call get_subscription_allowances, proceed only when features.retry is true, obtain approval before confirmed=true), and when-not-to-use ('arbitrary new ideas or imported still images'). Alternatives are named directly.

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

All spriteship tools Inspect

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

Need Help?