medusa-mcp

Create or update category

save_category

Idempotent

Create a new product category or update an existing one by ID, and add or remove products. Requires name for creation; updates only specified fields.

Instructions

Without category_id creates a product category (name required); with category_id updates only the given fields. Can also add or remove products.

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": "save_category"
  }
}

Input Schema

Name	Required	Description
`name`	No
`rank`	No	Position among siblings
`handle`	No
`metadata`	No	Merged into existing metadata; an empty string deletes a key
`is_active`	No	Visible in the storefront (new categories default to inactive in Medusa)
`category_id`	No
`description`	No
`is_internal`	No	Hidden from the storefront
`add_products`	No	Product IDs to add
`remove_products`	No	Product IDs to remove
`parent_category_id`	No	null moves it to the top level

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 4, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare idempotent=true, destructiveHint=false and openWorld=true. The description adds meaningful semantics beyond them: updates are partial ('only the given fields'), name is required only on creation, and the call can mutate product associations. It doesn't clarify permissions or what happens to omitted fields on update, but it is well above the annotation-only bar.

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?

Two dense sentences, front-loaded with the mode switch, no filler. Every clause carries information an agent needs.

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 an 11-param, no-required, no-output-schema tool, the description covers the essential decision logic and the side-effect on product associations. Return shape and behavior when category_id is absent/invalid are unaddressed, but the core calling contract is clear.

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 coverage is 64%, so the schema documents the more subtle params (metadata merge, rank as sibling position, parent_category_id null behavior). The description supplies the critical semantic that category_id switches create vs update, and that add_products/remove_products are side-effect lists, but says nothing about the remaining params (is_active, is_internal, handle).

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+resource (create/update a product category) and disambiguates the two modes by the presence of category_id. It also flags a secondary effect (add/remove products). It doesn't explicitly differentiate itself from the similarly named save_collection or delete_category, but the 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear branching rule for when to use each mode (no category_id = create, with category_id = update), which is genuine usage guidance. However, it names no alternatives (e.g. delete_category for removal) and states no prerequisites or exclusions.

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