Skip to main content
Glama

ebay_delete_store_category

Destructive

Delete a custom eBay Store category by categoryId, optionally moving active listings to another category, then poll the returned taskId until the async change completes or fails.

Instructions

Delete one custom eBay Store category (Stores API deleteStoreCategory). Pass the store categoryId and optionally listingDestinationCategoryId; active listings in or under the category move there, or to the store's Other category (ID 1) when omitted. Irreversible. Asynchronous: eBay accepts the change and returns { taskId, location } from the Location header; poll ebay_get_store_task with taskId (or ebay_get_store_tasks) until the task is COMPLETED or FAILED. Only one store category change (add, rename, move, or delete) can be in flight at a time; eBay rejects a new change until the previous task finishes. Requires an active eBay Store subscription (sell.stores scope).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryIdYeseBay Store custom category ID from ebay_get_store_categories (not an eBay marketplace category ID)
listingDestinationCategoryIdNoStore category that receives active listings in or under the deleted category; omitted, eBay uses the Other category (ID 1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.18.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark this destructive/not-readOnly, and the description substantially extends them: irreversibility, what happens to active listings (moved to listingDestinationCategoryId or Other ID 1), the asynchronous task model with taskId/location, the one-change-at-a-time concurrency limit, and the sell.stores scope plus active Store subscription requirement. This is the kind of context an agent needs to call a destructive async tool safely.

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?

Dense and front-loaded: action, irreversibility, then async/polling and constraints. Every sentence carries weight, though a few clauses (parameter restatement) duplicate the schema slightly.

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?

No output schema exists, and the description correctly supplies the return shape ({ taskId, location } from the Location header) plus the polling path. Auth scope, concurrency, and listing-destination behavior round out everything an agent needs.

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%, so both parameters are already documented; the description largely restates categoryId and listingDestinationCategoryId semantics. It adds no syntax or edge-case detail beyond the schema, so the baseline 3 applies.

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?

Names a specific verb and resource ('Delete one custom eBay Store category'), cites the underlying Stores API operation, and is clearly distinguishable from the sibling add/rename/move store category tools. The scope ('custom' store category, not marketplace category) is stated explicitly.

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?

Gives real operational context: irreversible, async acceptance, poll ebay_get_store_task/ebay_get_store_tasks until COMPLETED or FAILED, and only one store category change may be in flight. It does not name an alternative tool for the delete case (largely because none exists), but the prerequisites and follow-up path are well covered.

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

Deploy Server

Other Tools