Secondhand MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MARKETPLACES | No | Comma-separated list of marketplaces to enable (facebook, ebay, depop, poshmark). Defaults to all if not set. | |
| EBAY_CLIENT_ID | No | Your eBay Client ID for the Browse API. Optional; if missing, eBay marketplace is disabled. | |
| EBAY_CLIENT_SECRET | No | Your eBay Client Secret for the Browse API. Optional; if missing, eBay marketplace is disabled. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_marketplaceA | Search live listings on secondhand marketplaces by keyword. Marketplaces: . Returns up to |
| get_listing_detailsA | Get one listing in full using an id from search_marketplace or from a marketplace URL: description, every photo, location, seller and shipping options. Photos: by default (imageMode:"urls") you get direct full-resolution CDN image URLs to fetch yourself, which is the most reliable option because some CDNs block server-side fetches. Set imageMode:"inline" (or includeImages:true) to have the server fetch the photos and return them as base64 image blocks; if that fetch is blocked the server falls back to URLs. Use imageSize to trade resolution for payload and maxImages to cap the count. Requirements: the same as search_marketplace for that marketplace. Behavior: read-only, one listing per call, no login. Errors: a listing that has been removed, or an id from the wrong marketplace, returns an error message rather than a partial listing. Not for: searching (use search_marketplace) or fetching many listings at once. |
| list_marketplacesA | List the marketplaces this server can search right now, with each one's display name, whether it needs credentials, and whether it is currently reachable. Call it once when a search fails with an unknown-marketplace error or before offering a marketplace the user did not name. Behavior: read-only, no arguments, no network calls beyond a health check. Not for: searching or fetching listings. |
| searchA | Search every available secondhand marketplace at once with a single query string, following the ChatGPT deep research tool contract. Returns results whose ids (marketplace:listingId) can be passed to the fetch tool. Behavior: read-only; Facebook results use the server's default location because this contract carries no location, so prefer search_marketplace when a place matters. Not for: filtered or local searches. |
| fetchA | Fetch one listing in full for an id returned by the search tool, following the ChatGPT deep research tool contract. Id format: marketplace:listingId (for example "facebook:12345" or "ebay:v1|123|456"). Behavior: read-only. Errors: an id without the marketplace prefix, or for a removed listing, returns an error message. Not for: ids from search_marketplace, which take get_listing_details. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
The tool set has two overlapping pairs: search_marketplace/search and get_listing_details/fetch. The descriptions help clarify that one pair is marketplace-specific and the other follows the deep research contract, but an agent can still easily pick the wrong tool when the only distinguishing factor is the id format or contract convention.
Three tools follow a verb_noun pattern (search_marketplace, get_listing_details, list_marketplaces), while two bare generic verbs (search, fetch) break the pattern. This is inconsistent and makes the duplicated functionality harder to tell apart by name alone.
Five tools is a reasonable size for a read-only marketplace search server. However, the two contract-wrapper tools (search and fetch) duplicate the core capabilities of the marketplace-specific tools, making the set feel slightly padded even though it remains manageable.
The core read-only workflow is covered: searching listings, fetching full details, and discovering available marketplaces. Minor gaps exist, such as no pagination for searches and no seller-profile or category-browsing endpoint, but agents can generally accomplish the intended search-and-inspect task without dead ends.