Skip to main content
Glama

Edit my listing

seller_update_listing
DestructiveIdempotent

Edit one of the seller's own listings the way the website's Edit listing does: title, price (price_usd), lowest_acceptable_usd, category, condition, pickup location and photos. Give only what changes. Without confirmed: true nothing changes: the result lists the change and, when the price or category moves, would_result_in (take-home, buyer price, fees). What price_usd and lowest_acceptable_usd mean follows the listing's pricing_basis in seller_list_listings. take_home (every listing made from Sept 4 2026 on): price_usd is what the seller takes home, and our transaction and pickup fees and the delivery are added on top for buyers; lowest_acceptable_usd is the least they take home. asking_price (older listings): price_usd is the asking price before delivery (asking_usd), the take-home is that less our fees, and lowest_acceptable_usd is an asking price too. The platform adds the condition and city to the title, as it does at publish, and rebuilds them when the title, condition or pickup location changes; the preview's public_title is the exact result, and the listing's link does not change. photos is the whole ordered list after the edit, the first being the cover. A reserved or sold listing cannot be edited, and the description is not edited here (support corrects it).

Input Schema

NameRequiredDescriptionDefault
titleNo
photosNoThe listing's photos after the edit, in order, the first being the cover. "existing:N" keeps the photo now at index N (catalog_get_listing's photo_urls end in /N); an https image URL or a data:image URL adds one (at most 8 new per edit). Leave a photo out to remove it; at least one must remain. "file:N" places the Nth of photo_files, the photos attached in the chat.
categoryNoA category slug from catalog_list_categories or listing_resolve_category. It changes the fees and what buyers pay, so preview first.
conditionNoOne of the category's condition_options from listing_resolve_category.
confirmedYesfalse: nothing changes, and the result says what would. true: do it, once the seller has agreed.
price_usdNoNew price in US dollars, in the listing's pricing_basis: its take-home, or on an older listing its asking price.
listing_idYes
photo_filesNoPhotos the seller attached in the chat. The chat app fills these in (each a download_url and file_id); never write one by hand. They get the same checks as photo_urls. Place them with "file:N" in photos ("file:0" first makes it the cover); any not placed are added after the photos.
pickup_locationNoWhere the item is now: "City, ST", or a full address that contains it. A ZIP alone cannot move where the listing says it is.
lowest_acceptable_usdNoThe auto-accept floor, in the listing's pricing_basis: the least the seller takes home, or on an older listing the lowest asking price. Offers that reach it are accepted automatically. 0 removes it. It cannot be above price_usd.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true and idempotent=true, but the description adds substantial behavior beyond them: the confirmed:true gating, the would_result_in preview contents (take-home, buyer price, fees), automatic title rebuilds on title/condition/location changes, the immutable listing link, and the fact that photos are the whole ordered list with the first as cover. This is exactly the extra behavioral context annotations cannot convey.

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?

Front-loaded with purpose and editing constraints before the pricing-basis detail. It is long and the pricing-basis paragraph is dense, but each sentence carries operational information an agent needs (confirmation gating, preview output, auto-title behavior), so little is wasted.

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 10-parameter mutation tool with no output schema and destructive semantics, the description supplies the confirmation workflow, preview contents, pricing-basis interpretation, field-update semantics and explicit non-editable cases. Nothing essential for a correct call is missing.

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 80% (baseline 3), but the description adds real meaning: it resolves the ambiguous price_usd and lowest_acceptable_usd by tying them to the listing's pricing_basis (take_home vs asking_price), which the schema only hints at, and clarifies photos ordering/cover semantics. This goes beyond duplicating the schema.

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?

States a specific verb (edit) plus resource (one of the seller's own listings) and enumerates exactly which fields are editable. 'Give only what changes' further pins it as a partial-field update, distinguishing it from siblings like listing_add_photos or seller_relist_listing without the agent needing to open any schema.

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?

Clear when-to-use context: preview with confirmed:false, then commit with confirmed:true once the seller agrees. It also states exclusions — a reserved or sold listing cannot be edited and the description is not edited here (support corrects it). It stops short of explicitly routing to alternative siblings (e.g. photo-only additions), so it is strong rather than exhaustive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources