Skip to main content
Glama
Jacques-Murray

WooCommerce MCP Server

Update WooCommerce Product

woocommerce_update_product
Idempotent

Update specific fields of an existing WooCommerce product. Change status, price, stock, or other attributes without affecting other fields.

Instructions

Update fields on an existing product. Only the fields you provide are changed; all other fields are left untouched.

Args:

  • product_id (number, required)

  • Any subset of: name, status, description, short_description, sku, regular_price, sale_price, manage_stock, stock_quantity, stock_status, category_ids, tag_ids, weight

  • response_format ('markdown'|'json'): default 'markdown'

Returns: The updated product object.

Examples:

  • Use when: "mark product 42 as out of stock" -> product_id=42, stock_status="outofstock"

  • Use when: "put product 42 on sale for $15" -> product_id=42, sale_price="15.00"

Error Handling:

  • Returns "Error: Resource not found (404)" if product_id doesn't exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skuNo
nameNo
statusNo
weightNo
tag_idsNoReplaces the product's tag assignments
product_idYesThe numeric WooCommerce product ID to update
sale_priceNo
descriptionNo
category_idsNoReplaces the product's category assignments
manage_stockNo
stock_statusNo
regular_priceNo
stock_quantityNo
response_formatNoOutput format: 'markdown' for human-readable text or 'json' for machine-readable structured datamarkdown
short_descriptionNo
Behavior5/5

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

Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds crucial context: partial update behavior, return format (markdown or json), and error handling (404 for missing product). This goes beyond annotations to inform the agent of expected outcomes.

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

Conciseness5/5

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

The description is well-organized with clear sections: purpose, args, returns, examples, error handling. Every sentence adds value, and there is no redundant information. It is concise and easy to parse.

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?

Given the tool's complexity (15 parameters, 1 required) and absence of output schema, the description covers key aspects: partial update, error handling, and return object. It could mention that tag_ids and category_ids replace existing assignments (though schema notes this), but overall it is sufficiently complete for an agent to use the tool effectively.

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 only 27%, so the description should compensate. It lists all parameters but provides no detailed semantics (e.g., valid values for status, how category_ids/tag_ids behave). The examples clarify a couple of parameters but leave most undocumented. Baseline is lower due to low coverage, and the description adds marginal value.

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?

The description clearly states 'Update fields on an existing product', which distinguishes it from create, delete, and other product operations. It also specifies that only provided fields are changed, leaving others untouched.

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?

Examples illustrate common use cases like marking out of stock or setting sale price, clearly implying when to use this tool. However, it does not explicitly state when not to use it (e.g., for creating a product), though that is implied by the sibling tool names.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jacques-Murray/woocommerce-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server