Skip to main content
Glama

manage_product

Read and update the products the user sells, saved to their account for product ads and selling videos in any project. The user edits a product's photos, description, page link and voice/video reference clips in My assets; the selling points, price, specs, appearance and audience fields are optional and only you fill them. The section of your context lists them. Actions: list, get, create, update, delete. get returns photo URLs: pass them directly as video or image generation references (refImages, firstFrame), front shot first; you do not need the user to upload them again. Saved reference clips (audios, videos, with their seconds) go to video generation as refAudios / refVideos when the shot calls for that voice, sound or motion and the model accepts them. Write scripts only from what is saved (the description first, then any selling points, price and specs); never invent claims, prices or ingredients. Keep the appearance details exact in generation prompts. Use a product when the user names it, says "my product", or attaches it from + → 我的资产. Save a product they clearly sell as soon as you learn it, from what they gave you or from a product page. addImages takes a current-project asset reference or an https URL. After a successful save, tell the user in one sentence what was saved and that it is in 我的资产 > 产品 (the app's own labels); never claim a save that failed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "manage_product"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoRequired for create: the product name as the user sells it.
priceNoAs written by the user or page, e.g. "¥29.9 / 3 bags".
specsNoSize, flavor, ingredients and other facts scripts must not invent.
actionNolist: every product with a one-line summary; a call without action lists. get: one product in full, including photo URLs. create: a new product. update: change one. delete: remove one.
audienceNo
categoryNo
addImagesNoFor create and update: product photos to add.
productIdNoFor get, update and delete: the product id from list.
projectIdNoProject for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
sourceUrlNo
appearanceNoWhat it looks like and which details must stay exact in generated shots, e.g. label text, logo position, colors.
timelineIdNoOnly for a project asset in addImages when no editor is attached to this chat, as on a connector: the full timeline UUID from read_project or manage_timelines action="list". ChatCut uses it to fetch the file from the open editor.
descriptionNoOne or two sentences on what it is.
sellingPointsNoThe complete list of selling points, replacing the previous one; only claims the user or the product page states.
removeImageIdsNoFor update: ids of photos to remove, from get.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: which fields are agent-authored vs user-authored, that photos are copied into user storage and outlive the project, that get's photo URLs can be passed straight into refImages/firstFrame, and the post-save confirmation requirement. One gap: destructiveHint=false while the definition lists a delete action that removes a saved product — the description does not reconcile that, leaving the risk profile for delete unclear.

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?

Reasonably front-loaded — purpose first, then an explicit "Actions:" line, then usage guidance — but the prose is dense and runs long, with generation-workflow advice (refImages, refAudios, voice/motion matching) that drifts beyond this tool's own contract. Several clauses could be tightened without losing meaning.

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 15-parameter tool with no output schema, it covers the important ground: action semantics, id derivation (productId from list), image sourcing, and what a get returns. Missing pieces are minor — no pagination/limits for list and no explicit statement of what delete removes or whether it is reversible.

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 already 80%, but the description adds cross-tool semantics the schema cannot: that get's returned photo URLs feed video/image generation with the front shot first, and that saved clips map to refAudios/refVideos when the model accepts them. It also constrains what may be written into description/sellingPoints/specs (no invented claims, prices or ingredients).

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?

Opens with a specific verb+resource ("Read and update the products the user sells") plus the retention scope ("saved to their account ... in any project") and then enumerates all five actions. This clearly separates it from the neighboring manage_avatar / manage_character / manage_design_style tools, which manage other asset types.

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?

Gives concrete invocation triggers: "when the user names it, says 'my product', or attaches it from + → 我的资产," plus a proactive rule to save a product as soon as the user reveals one. It also states which fields the agent fills versus which the user edits in My assets. It stops short of naming explicit alternatives or exclusion cases, so it is strong but not a full when/when-not rubric.

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.