Skip to main content
Glama

Create a listing

listing_create
Idempotent

Use when the user is selling a large or valuable item (fitness equipment, hot tubs, saunas, golf carts, furniture, appliances), including when also posting to Facebook Marketplace, Craigslist, or OfferUp. Publish a listing for the seller (terms as in the server instructions). Resolve the category with listing_resolve_category first. Condition is required. The category's other questions are optional and can be added after the listing is up. The price the seller asked for on Facebook Marketplace, Craigslist, or OfferUp becomes their take-home on Commonplace. The buyer price includes pickup and delivery. With a photo it publishes live (status live, or in_review outside our categories); with none, a draft is saved and finish_url is where the seller adds photos (or use listing_add_photos). A connection that cannot publish can save a no-account draft with listing_crosslist_draft instead. Drafts never expire or show to buyers; seller_list_listings lists them and listing_discard_draft removes one. Without confirmed: true nothing is saved: the result is a preview of what would be published (public_title, answers as stored, take_home_usd, buyer_price_usd and the fees added on top), with problems listing anything a confirmed call would refuse and ignored_answers any key the category does not ask. Listing is free. The seller is paid their take-home at pickup (bank transfer, Venmo, Cash App, or PayPal), not after delivery. Promote is an optional add-on and this never turns it on. Within minutes of publishing, a description is generated from details and may retitle the listing; it can state things the seller never said, so check it on the listing page (support corrects it; no tool edits one). environment in the result names the deployment: only production reaches real buyers.

Input Schema

NameRequiredDescriptionDefault
titleYesJust the item, e.g. "Peloton Bike+ 2022": the platform adds condition and city, and the preview's public_title is the exact result.
answersNoAnswers to the category's required_questions, keyed by the `key` values from listing_resolve_category. Use its exact option strings; where none fits (a brand that is not listed, say), give the real value as written. Condition is not one of them; give it as `condition`. Every answer is a string: a number as digits ("2021"), and for a question of type chips several choices separated by commas, options and the seller's own words alike (the preview's answers show how each is stored). The preview's ignored_answers lists any key this category does not ask.
detailsNoAnything else the seller said about the item: age, wear, what is included. Contact details are removed, and the listing's description is generated from it.
categoryYesThe category from listing_resolve_category. An exact slug or name is used as given; anything else is matched with the title, and the preview shows which category it landed in.
conditionNoAn exact option from the category's condition_options, given here and not in answers. Where the options name a usage band (rides, uses), grade by usage and put cosmetic wear in details.
confirmedYesfalse: nothing is saved, and the result is a preview. true: publish, once the seller has agreed to exactly this; with no photos it saves a draft instead, finished at finish_url.
price_usdYesWhat the seller wants to take home, in US dollars. The transaction and pickup fees and delivery are added on top for buyers.
photo_urlsNoUp to 8 photos. Prefer https image URLs (JPEG, PNG, WebP or GIF, up to 5MB each). A data:image URL works only for a small image: the whole request is limited to 256KB and a larger one is refused before the tool runs. A photo the seller attached in the chat goes in photo_files, never written out here; if the chat app cannot attach it, publish without photos to save a draft and give the seller finish_url. A preview does not download photos: include https links in it anyway so they are checked (a Commonplace link such as /api/img/<listing id>/0 belongs to that listing, and another seller's is a problem there), but send an inline image only with the confirmed call, since writing one out twice costs the seller minutes. EXIF location data is removed.
pickup_zipYesWhere the item is: a 5-digit ZIP or "City, ST". The exact address is confirmed before pickup.
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.
seller_nameNoOnly if the account has no name on file.
seller_phoneNoRequired when the account has no phone on file (account_get_profile shows phone: null); otherwise only to use a different number. A US number that receives texts: pickup is arranged by text, and a landline is accepted but gets none. 10 digits, with or without +1, spaces or dashes. It is saved with this listing. If the account has no phone, it is also saved as a contact number so the next listing does not ask again. It is not used to sign in.
lowest_take_home_usdNoOptional: the least the seller would take home. Offers that reach it are accepted automatically; it is never shown to buyers. Above price_usd it is set to price_usd.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations are sparse (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false), and the description carries the behavioral load: publishing vs draft outcomes based on photos, the preview-only behavior without confirmed:true, required seller_name/seller_phone only when the account lacks them, payment timing (paid at pickup), fees added on top for buyers, and post-publish auto-generated descriptions that may retitle the listing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The usage trigger is correctly front-loaded, but the body is a dense single block of roughly 20 sentences that jumps between publishing rules, payment, drafts, previews, description generation, and environment. Most content earns its place given the tool's complexity, yet the flowing prose makes it hard to scan for exclusions.

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 13-parameter publishing tool with no output schema, the description covers outcome modes (live vs draft vs crosslist draft), what a preview returns (public_title, answers, take_home_usd, buyer_price_usd, problems, ignored_answers), and the environment field. An agent has enough to call it correctly and interpret results.

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 the baseline is 3; the schema already documents title, price_usd, condition, answers, photos, phone, etc. in depth. The description reinforces cross-cutting semantics (condition required, price is take-home, photo presence determines live vs draft) but adds little parameter detail the schema does not already contain.

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 and resource ("Publish a listing for the seller") and scopes the trigger to a concrete seller situation (large/valuable items such as fitness equipment, hot tubs, furniture). It also distinguishes itself from siblings by naming listing_resolve_category, listing_add_photos, and listing_crosslist_draft for adjacent cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use (selling a large/valuable item, also cross-listing to Facebook Marketplace/Craigslist/OfferUp) plus named alternatives and their conditions: listing_crosslist_draft for connections that cannot publish, listing_add_photos/finish_url when there are no photos, seller_list_listings and listing_discard_draft for drafts. Nothing is left to inference.

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