End an active fixed-price eBay listing by providing its item ID and an optional reason. Stop the sale and remove the listing from the marketplace.
End/remove an active fixed-price listing.
Uses the Trading API (EndFixedPriceItem).
Required: User OAuth token.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | The eBay item ID to end | |
| reason | No | Trading API ending reason, defaulting to NotAvailable |
Changes observed during successful MCP inspections.
v1.14.1Input schema / properties / reason / descriptionPrevious value: -"Reason for ending (default: NotAvailable)"New value: +"Trading API ending reason, defaulting to NotAvailable"v1.8.10Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states the action (end/remove) but omits consequences (e.g., irreversibility, fees) or details about the Trading API call. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using only two sentences and a line break. It conveys the core purpose and requirement without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description lacks completeness. It does not explain the return value, error handling, or effects of ending a listing. For a simple tool, it still feels insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description does not add any additional meaning or context beyond what is in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ends/removes an active fixed-price listing, using specific verbs and resource. It distinguishes from sibling tools like ebay_relist_item or ebay_revise_listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required User OAuth token, indicating a prerequisite. However, it does not provide guidance on when to use this tool versus alternatives (e.g., relisting or revising).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.