medusa-mcp

Delete variant

delete_variant

DestructiveIdempotent

Irreversibly deletes a product variant from Medusa after exact SKU or title confirmation; its inventory item is removed by default if none are reserved.

Instructions

DELETES one variant of a product. Irreversible – confirm with the user first. 'confirm' must equal the variant's SKU (or its title when it has no SKU). By default its inventory item is deleted too (only when nothing is reserved).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product_id": "<product_id>",
      "variant_id": "<variant_id>",
      "confirm": "<confirm>"
    },
    "name": "delete_variant"
  }
}

Input Schema

Name	Required	Description
`confirm`	Yes	The variant's exact SKU, or title when it has no SKU
`product_id`	Yes
`variant_id`	Yes
`delete_inventory_items`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description goes well beyond them: it states the operation is irreversible, discloses a side effect (the inventory item is deleted by default) plus the condition that limits it (only when nothing is reserved), and defines the confirmation contract. This is exactly the extra behavioral context annotations cannot carry.

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?

Three sentences, zero filler, and the destructive verb and irreversibility are front-loaded before the parameter mechanics. Every sentence carries distinct information (scope, safety, confirm contract, side effect).

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?

For a destructive single-resource delete with no output schema, the description covers what an agent actually needs: irreversibility, the human-confirmation requirement, the exact confirm value, and the conditional inventory side effect. The annotations handle the safety profile, so no material gap remains.

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 only 25% (only 'confirm' is documented), so the description must compensate. It restates the confirm semantics (SKU, or title when no SKU) and, more usefully, explains the meaning of the undocumented delete_inventory_items flag: on by default, deleting the inventory item only when nothing is reserved. product_id and variant_id remain unexplained, keeping this short of a 5.

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 first line gives a specific verb and a precisely scoped resource: 'DELETES one variant of a product.' The singular scope ('one variant') cleanly separates it from delete_product, delete_category, delete_collection, and delete_promotion in the sibling set, so an agent can route by resource without further inference.

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?

It provides one concrete operational rule ('confirm with the user first'), which is real usage guidance for a destructive call. However, it never names an alternative (e.g. update_variant or setting status instead of deleting) or states a when-not-to-use condition, so the routing guidance is implied rather than explicit.

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