Skip to main content
Glama

submit_asset_references

Submit front, back, left, and right reference images to prepare immutable RGBA cutouts and run pixel gates before agent visual review.

Instructions

Prepare immutable RGBA cutouts and run pixel gates; agent visual review is next.

Input Schema

NameRequiredDescriptionDefault
asset_idYes
batch_idYes
key_colorNo
back_image_pathYes
background_modeNoauto
left_image_pathYes
front_image_pathYes
right_image_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

C2.2/5.0
Behavior2/5

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

With no annotations at all, the description carries the full disclosure burden, and it delivers very little. "Immutable" hints outputs are write-once and "pixel gates" implies validation can fail, but it never says what is created, what happens when a gate fails, whether re-submission is allowed, or whether this mutates batch state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short, front-loaded sentence with no filler, which is good, but the compression has been taken too far for a tool with this much surface area. Brevity here reads as under-specification rather than efficiency.

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

Completeness2/5

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

For an 8-parameter, 6-required mutation-style tool with no annotations, no output schema, and zero schema descriptions, one cryptic sentence is far from sufficient. Essentials an agent needs before calling — expected path format, gate failure behavior, and prerequisite state — are all absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters and the description explains none of them. It never mentions that four image paths are required, what key_color expects (RGB triple?), or how background_mode's auto/transparent/chroma options behave, so the agent is left guessing on a fully undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The sentence names effects ("immutable RGBA cutouts", "pixel gates") but never states the actual operation: submitting front/back/left/right reference images for an asset in a batch. It does not differentiate from siblings like record_asset_review or retry_asset_stage, so an agent must infer the intent from the tool name and schema.

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

Usage Guidelines2/5

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

"Agent visual review is next" is the only usage signal, and it only hints at workflow ordering relative to one unnamed downstream step. There is no statement of preconditions (e.g., batch must be open), no when-not-to-use case, and no comparison against record_asset_review or retry_asset_stage.

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