Skip to main content
Glama

set_list_membership

Add or remove a product from an Ozon collection or wishlist by providing SKU and list ID. Use the add flag to control whether the product is inserted or removed.

Instructions

[GATED by writes_enabled] Put a product into a collection or wishlist, or take it out. Ozon reports no outcome for this, so detail names the read that confirms it — get_lists(sku).

Input Schema

NameRequiredDescriptionDefault
addNoTrue puts the product in the list, False takes it out.
skuYesA product SKU ("3077454533"). For apparel use the variant SKU, not the base one.
list_idYesTarget list, from get_lists()[].list_id.

Output Schema

NameRequiredDescriptionDefault
okNo
detailNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.1

TDQS

A3.6/5.0
Behavior4/5

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

The description discloses a critical behavioral trait: Ozon reports no outcome for this operation, so the agent must confirm via get_lists(sku). This goes beyond annotations (none provided) and adds actionable context about side effects and confirmation workflow. The writes_enabled gating is also mentioned, though its exact meaning is not elaborated.

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 sentences deliver the core purpose, the permission gate, and the confirmation read. No filler, front-loaded with the gating context, and every word earns its place.

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 moderate complexity, the description covers purpose, permission gating, no-outcome behavior, and confirmation path. An output schema exists (though its content isn't shown here), which reduces the need to explain return values. Missing are explicit usage conditions and edge-case callouts, but the essential details are present.

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 100%, and the parameter descriptions are detailed: add explains boolean semantics, sku notes variant guidance, list_id references get_lists()[].list_id. The description itself adds no extra parameter information beyond the schema, so baseline 3 is appropriate.

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?

The description clearly states the action: put a product into a collection or wishlist, or take it out. It specifies the resource (list membership) and direction (add/remove). While it doesn't explicitly differentiate from sibling tools like set_favorite, the operation is distinct enough.

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?

No explicit guidance on when to use this tool versus alternatives. The '[GATED by writes_enabled]' hint implies a permission prerequisite, but there is no mention of preconditions, typical use cases, or when other tools (like set_favorite) should be preferred. The agent must infer usage from the schema and context.

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