Skip to main content
Glama

Nexscope Ecommerce Data MCP

Handheld Product Mockup API

nexscope_handheld_product_mockup

Generate natural hand-held product imagery from a person image and target product asset.

Input Schema

NameRequiredDescriptionDefault
imageUrlYesPublic URL of the product image. The image must be at most 20 MB and between 385 and 8192 pixels in both width and height.
outputNumNoNumber of images to generate, from 1 to 4. Defaults to 1.
targetMaskUrlYesPublic URL of the black-and-white hand-held area mask. Required because this API accepts custom pose images rather than saved upstream materials.
targetOriginUrlYesPublic URL of the person or hand pose image.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations only give readOnlyHint=false and openWorldHint=true, so the description carries most of the burden. It says nothing about this being an async generation job, how results are retrieved (a sibling nexscope_media_task_result exists), cost/latency, or what happens with the supplied mask.

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?

A single front-loaded sentence with no filler, stating action and inputs first. It is efficient but perhaps too compressed for a multi-input generation endpoint.

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 a multi-image, three-URL generation tool with no output schema and thin annotations, the description omits result retrieval, timing, and failure modes. An agent would not know from this text how to obtain the produced imagery.

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 description coverage is 100% and already documents every parameter including size limits and outputNum range. The description adds no parameter-level detail beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

Names a specific verb ("Generate") and resource ("natural hand-held product imagery") and identifies the two required input assets (person image, product asset). It is understandable against siblings like nexscope_ai_hand_repair or nexscope_product_replacement, though it does not explicitly contrast with them.

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?

No statement of when to use this versus adjacent generation tools (e.g., nexscope_product_replacement, nexscope_virtual_try_on, nexscope_ai_hand_repair), and no prerequisites or workflow notes. The agent must infer the selection criteria from the name alone.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources