Skip to main content
Glama
kisasa

Shopify MCP Server

by kisasa

update-product

Modify an existing Shopify product's fields—title, description, status, tags, SEO, and metafields—by specifying its product ID. Use it to keep listings accurate without recreating products.

Instructions

Update an existing product's fields (title, description, status, tags, etc.)

Input Schema

NameRequiredDescriptionDefault
idYesShopify product GID, e.g. gid://shopify/Product/123
seoNoSEO title and description for search engines
tagsNo
titleNo
handleNoURL slug for the product
statusNo
vendorNo
metafieldsNoMetafields to create or update inline. Pass 'id' to update existing, or 'namespace'+'key' to upsert. For standalone metafield operations, prefer the set-metafields tool instead.
productTypeNo
descriptionHtmlNo
collectionsToJoinNoCollection GIDs to add the product to
redirectNewHandleNoIf true, old handle redirects to new handle
collectionsToLeaveNoCollection GIDs to remove the product from

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permissions required, whether unspecified fields are preserved (partial vs. full replace), whether the update is reversible, or what side effects occur on handle changes. For a 13-parameter mutation tool with nested metafield objects, this is a substantial gap.

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 compact sentence with no filler, and the verb/resource is front-loaded. It is efficient but arguably too terse given the tool's parameter surface.

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?

With 13 parameters, nested objects, no annotations, and no output schema, the one-sentence description is far too thin. An agent is left guessing about partial-update semantics, collection membership changes, and metafield upsert behavior without any descriptive support.

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

Parameters2/5

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

Schema coverage is only 54%, so the description should compensate, but it merely echoes the obvious fields (title, description, status, tags) and omits any explanation of handle, seo, metafields, collectionsToJoin/Leave, or redirectNewHandle. It adds no meaning beyond what the schema already states where descriptions exist, leaving roughly half the parameters underspecified.

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?

States a specific verb (Update) and resource (an existing product's fields) and names several updatable fields, so an agent can tell it apart from create-product or delete-product immediately. It stops short of distinguishing it from finer-grained siblings like manage-product-variants or set-metafields, but the core purpose is unambiguous.

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?

The description gives no guidance on when to choose this tool over create-product, manage-product-variants, or the standalone set-metafields tool mentioned only inside the schema. There are no prerequisites, no exclusions, and no conditions stated in the description text itself.

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