Skip to main content
Glama
Sign In
Hermoso

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Publish an image or video onto a Shopify product

publish_to_shopify_product
Destructive

Attach a finished image or video to a Shopify product listing as product media. Pass the product ID and a public HTTPS media URL to publish it, then read back Shopify's processing status.

Instructions

Attach a finished IMAGE or VIDEO to one of the merchant's Shopify product listings, as product media. Pass productId (from list_shopify_products, the gid://shopify/Product/… form) and a PUBLIC https mediaUrl, which is what every Hermoso render returns. Whether it is a video is read from the file (.mp4 / .mov / .webm, or the link's content type); pass kind to say so outright. An image is fetched by Shopify directly; a video is uploaded to Shopify for you (MP4, MOV or WEBM, up to Shopify's 1 GB and 10-minute product-video limits; a file over a limit is refused by name, never cut). Shopify processes media asynchronously: the reply is the status read back from Shopify, and READY means it is live on the listing while PROCESSING means it will appear when Shopify finishes. That is success, not a failure. Only works for accounts created by installing Hermoso from the Shopify App Store. Free: the render was already paid for.

Input Schema

NameRequiredDescriptionDefault
altNoalt text for accessibility and SEO; defaults to a generic credit
kindNoonly when the link does not say (no file extension and no content type)
imageUrlNoolder name for mediaUrl; still accepted
mediaUrlNoany public https image or video URL: a Hermoso render works, and so does ANY file of your own brought in with upload_file
productIdYesgid://shopify/Product/… from list_shopify_products

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.465
    • changedInput schema / properties / imageUrl / description
      Previous value: -"any public https image URL — a Hermoso render works, and so does ANY file of your own brought in with upload_file"New value: +"older name for mediaUrl; still accepted"
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "only when the link does not say (no file extension and no content type)",
+  "enum": [
+    "image",
+    "video"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / mediaUrl
      Added value: +{
+  "description": "any public https image or video URL: a Hermoso render works, and so does ANY file of your own brought in with upload_file",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "productId",
-  "imageUrl"
-]New value: +[
+  "productId"
+]
  2. Addedv0.1.161

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond annotations by explaining async processing (READY vs PROCESSING, and that PROCESSING is success, not failure), the 1 GB / 10-minute video limits with refusal-by-name rather than truncation, that videos are uploaded on the caller's behalf, and that the call is free. It does not address the annotated destructiveHint=true (e.g. whether prior media is replaced) or idempotentHint=false (whether re-publishing duplicates media), which are the remaining behavioral unknowns.

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-loads the action and the two key inputs in the first sentence, then layers limits and async semantics. It is dense rather than padded, though the parenthetical about file extensions/content-type and the 'kind' restatement slightly overlap with the schema.

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?

No output schema exists, and the description supplies what the reply looks like (Shopify status, READY/PROCESSING) plus failure semantics for oversized files. Combined with a fully documented 5-parameter schema, an agent has everything needed to invoke correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds genuine context by naming the gid://shopify/Product/… form, the public-https requirement, the Hermoso-render/upload_file provenance of mediaUrl, and the fallback role of kind. It adds nothing about alt or the legacy imageUrl alias, though the schema already documents both.

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 concrete verb+resource: attach a finished IMAGE or VIDEO to a Shopify product listing as product media. It distinguishes itself from nearby siblings by naming list_shopify_products as the source of productId and by clarifying that any file brought in with upload_file also works as mediaUrl.

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 prerequisites (account must be created by installing Hermoso from the Shopify App Store) and explicit input routing (productId comes from list_shopify_products in gid:// form; mediaUrl must be a public https URL). It also states when to supply kind ('only when the link does not say'), which heads off ambiguous calls.

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

Deploy Server

Other Tools