spriteship

Get asset

get_asset

Read-onlyIdempotent

One asset with its revision iterations and typed animation projection. Accepts the asset id OR its slug. Texture assets carry metadata.seamless.seamMetric (a FREE wrap-edge verdict) and metadata.seamless.fixed — read seamMetric.pass to decide whether a cell needs the paid fix_asset_seams call at all. Generation Contract assets expose generationPlan plus extraction. extraction.status:"exact" means the planned number of logical foreground objects was recovered; "recovered" means small detached decorations were safely grouped; "needs_review" preserves every detected object and carries a warning instead of silently deleting or inventing one. grid.tiles[].url returns each extracted object as its own transparent PNG; the grid is a rebuilt presentation layout, not the geometry used to cut the model output. Legacy assets without extraction retain their historical fixed-grid metadata and should still be reviewed with the old grid fields. Backgrounds carry a background block echoing the sub-type, view and the aspect ratio actually generated — read it back to confirm the shape when you left aspectRatio unset.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`assetId`	Yes	Asset id or slug.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description adds rich behavioral context around extraction.status, the grid-tiles presentation layer, legacy fallback, and background shape confirmation. This adds meaningful transparency about output semantics without contradicting the annotations.

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?

The description is long, but every sentence carries decision-relevant detail for the states and shape of the returned asset. The information is well ordered by asset type and status, though the single large paragraph makes it harder to scan than structured bullets would.

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 read-oriented asset lookup with no output schema, the description does a strong job of explaining extraction status enums, grid tile semantics, legacy behavior, and background results. It still leaves some output concepts like typed animation projection explained only at a very terse level, which is a real but minor gap.

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 schema already documents assetId with full coverage, including accepted forms. The description repeats the id-or-slug fact but adds no deeper syntax, format, or edge-case meaning beyond the existing 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?

Clearly states a singular 'asset' as the resource, marking this as the single-asset lookup tool among siblings like list_assets, get_character, and get_map. It also describes the full asset payload scope: revision iterations and animation projection.

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?

Tells the agent it accepts an asset id OR slug, making the invocation decision straightforward, and explicitly explains how seamMetric.pass informs whether fix_asset_seams is even needed. It does not explicitly set exclusion boundaries against list_assets, so it stops just short of full alternative routing.

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

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

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, and the descriptions are extremely detailed with cross-references (e.g., animate_asset vs frame_animation vs generate_character_animation). A few pairs like reprocess_asset vs revise_asset could be confused initially, but their descriptions and use cases are explicit enough to prevent misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_project, get_asset, cancel_job). Verbs are imperative and nouns are appropriately singular/plural, making the API predictable and readable.

Tool Count2/5

At 41 tools, the server is far beyond the 15-25 range considered reasonable for most APIs. While the domain is broad (project, assets, characters, animations, jobs, exports, credits), the sheer number creates a heavy surface that may overwhelm agents and suggests the API could be consolidated into higher-level operations.

Completeness4/5

The tool set covers the full creative pipeline: project creation, asset/character generation, animation (both AI and frame-based), revisions, exports, and job management. Minor gaps include lack of delete operations for assets/characters/projects and no listing of all jobs, but these are not critical for the core workflow and are likely intentional for a generative art platform.

Resources

Need Help?