Shopping Deals MCP Server
This server lets you search, compare, and rank product deals across multiple online marketplaces (eBay, Facebook Marketplace, Amazon, Craigslist, OfferUp, Google Shopping) from a single MCP interface.
Tools:
list_sources: View all configured shopping sources and their required API credentials or setup flags.search_products: Search across multiple platforms and get normalized listings with consistent pricing fields. Supports filtering by condition, price range, location, and per-source result limits.find_best_deals: Rank results by deal strength, factoring in price, relevance, condition, source reliability, and warnings (e.g., accessories, wrong variants, suspiciously high shipping).find_cheapest_offers: Filter to exact-model matches and sort by total landed cost (price + shipping + estimated tax).compare_prices: Group comparable listings and summarize observed price ranges (low, high, average) across marketplaces.get_listing_details: Fetch detailed information for a specific listing from sources that support it (e.g., eBay).
Additional Features:
Normalizes listings into a common schema with separated
price,shipping_cost,total_price,estimated_tax, andtotal_with_taxfields.Penalizes accessory, parts, and wrong-variant listings.
Handles product name/model variant edge cases.
Optional tax estimation based on a configurable rate.
Supports local (stdio/HTTP) and remote (Cloudflare Worker) deployment.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Shopping Deals MCP Serverfind the cheapest PlayStation 5 Digital Edition"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Shopping Deals MCP Server
Shopping Deals MCP Server is a Model Context Protocol server for finding products, comparing marketplace listings, and ranking the cheapest real offers across eBay, Facebook Marketplace, Amazon, Craigslist, and OfferUp.
It is built for agents that need to answer questions like:
"Find the cheapest DJI OSMO Pocket 4P shipped to me."
"Compare exact-model prices across marketplaces."
"Compare the same item across Miami, New York, Los Angeles, and other local markets."
"Avoid accessory listings, wrong variants, and fake low prices with high shipping."
"Estimate tax and sort by final landed cost."
"Find marketplace items I can buy and flip profitably on eBay."
"Research whether a used car is worth flipping on eBay Motors before I inspect it."
"Track Florida dealer-threshold exposure while evaluating vehicle flips."
"Track resale leads, inventory, listed items, sold items, and business metrics."
What It Does
Searches multiple shopping sources from one MCP interface.
Normalizes listings into a common schema.
Defaults OfferUp searches to Miami Beach while allowing explicit location overrides.
Separates item price, shipping cost, shipped total, estimated tax, and estimated final total.
Penalizes accessories, parts, and wrong model variants.
Handles edge cases like
Pocket 4PvsPocket 4.Scores reseller/arbitrage opportunities using eBay comps, estimated fees, shipping, tax, ROI, and risk.
Scores vehicle flips separately with eBay Motors listing fees, title/VIN risk, transport, inspection, repairs, storage, and Florida dealer-threshold awareness.
Tracks a simple resale pipeline: leads, purchases, inventory, listings, sold items, and realized profit.
Can run locally over stdio or remotely as a Cloudflare Worker MCP endpoint.
Related MCP server: geizhals-mcp
MCP Tools
Tool | Purpose |
| Show configured sources and setup requirements. |
| Return normalized listings across selected platforms. |
| Rank strongest deals using price, relevance, condition, source, and warnings. |
| Filter exact-model offers and sort by shipped total plus estimated tax when supplied. |
| Group comparable listings and summarize observed price ranges. |
| Search the same product across multiple areas and compare local listing price ranges. |
| Fetch source-specific listing details where supported. |
| Estimate resale value from eBay comps. Currently returns active-listing comps as a labeled proxy, not fabricated sold data. |
| Calculate eBay-style flip profit, ROI, fees, tax, break-even sale price, and max buy price. |
| Search buy-side marketplaces and rank listings that may be profitable to resell on eBay. |
| Draft an eBay title, description, price hint, shipping guidance, and photo/disclosure checklist. |
| Create the OAuth consent URL for connecting an eBay seller account. |
| Exchange an eBay authorization code and store the seller refresh token in Worker KV. |
| Check seller-token configuration and retrieve the connected eBay user profile when possible. |
| Fetch seller business policies, inventory locations, and account readiness. |
| Create a specific eBay payment, return, or fulfillment policy from an Account API payload. |
| Create or reuse default payment, return, and USPS Priority shipping policies. |
| Create the inventory location required before publishing listings. |
| Create or update an eBay Inventory API SKU with title, description, photos, aspects, quantity, and videos. |
| List Inventory API items for the connected seller account. |
| List Inventory API offers for a specific connected seller SKU. |
| List active My eBay selling listings using the Trading API, including listings not created by this MCP. |
| Fetch detailed title, description, category, photos, item specifics, and selling status for one listing. |
| Return actual listing photo URLs, local download commands, edit briefs, video prompts, and upload/revise steps for AI-assisted asset work. |
| Preview or apply live eBay title/description revisions through Trading API. |
| Fetch eBay Analytics listing/day traffic metrics such as impressions, views, CTR, conversion rate, and transactions. |
| Audit active listing assets and performance signals, including photo/video counts, watches, bids, views, and traffic when available. |
| Save a listing performance dashboard into Worker KV for before/after optimization tracking. |
| Compare two saved snapshots and return listing-level deltas. |
| Upload an HTTPS image URL to eBay Picture Services and return the EPS image URL/image ID. |
| Retrieve eBay Media API image details after upload. |
| Preview or apply live eBay photo/video revisions through Trading API. |
| Create an eBay offer for a SKU without publishing it. |
| Publish an offer as a live eBay listing. |
| Create inventory, create an offer, and optionally publish after explicit approval. |
| Create a listing video asset and upload video bytes from a URL. |
| Check listing video processing status. |
| Fetch seller orders from eBay Fulfillment API. |
| Add carrier/tracking information to an eBay order. |
| Save an arbitrage lead into the reseller pipeline. |
| Move a lead through |
| Create a purchased item for inventory tracking. |
| Mark inventory as listed for sale. |
| Mark inventory sold and calculate realized profit. |
| Summarize leads, inventory, invested cash, sold revenue, realized profit, and ROI. |
| Validate basic VIN format/check digit and estimate model year/country offline. |
| Calculate vehicle flip economics using eBay Motors fees and vehicle-specific costs. |
| Score title, VIN, lien, odometer, seller-name, and flood-market risk. |
| Track Florida's three-vehicle dealer-activity presumption threshold. |
| Search vehicle leads and rank potential eBay Motors flips. |
| Draft vehicle listing copy, photo checklist, and required disclosures. |
| Save a vehicle research lead. |
| Update a vehicle lead status and append notes. |
Sources
Source | Coverage | Requires |
eBay Browse API | Official eBay item search, shipping, and detail lookups |
|
Facebook Marketplace public search | Local used marketplace listings |
|
Craigslist static search HTML | Local used marketplace listings | none, configure |
OfferUp public search | Local used marketplace listings, defaulting to Miami Beach with location override support | none |
Amazon public search | Amazon product search HTML parser |
|
Google Shopping via SerpApi | Broad retail coverage such as Amazon, Walmart, Target, eBay, merchant sites |
|
Scraped/public sources can change or block automated traffic. Official APIs are more reliable.
Requirements
Python 3.10+
Node.js 20+ for the Cloudflare Worker version
eBay developer credentials for reliable eBay results
Optional: SerpApi key for broad Google Shopping coverage
Optional: Cloudflare account for remote hosting
Use The Hosted MCP Server
You can use the public hosted MCP server without cloning this repo:
https://shopping-deals-mcp.jonathang132298.workers.dev/mcpAdd it to Codex:
codex mcp add shopping-deals-remote --url https://shopping-deals-mcp.jonathang132298.workers.dev/mcp
codex mcp get shopping-deals-remoteUse it from any MCP client that supports Streamable HTTP:
{
"mcpServers": {
"shopping-deals": {
"url": "https://shopping-deals-mcp.jonathang132298.workers.dev/mcp"
}
}
}Health and source status:
https://shopping-deals-mcp.jonathang132298.workers.dev/healthThe hosted Worker uses the maintainer's configured API keys and public marketplace parsers. If you want to use your own eBay, SerpApi, or Cloudflare account, follow the local setup or deployment steps below.
The hosted Worker exposes the reseller and vehicle research tools. Stateful business tools require the Worker's RESALE_KV binding; if a deployment has no KV binding, stateless tools such as find_arbitrage_opportunities, find_vehicle_arbitrage_opportunities, calculate_resale_profit, calculate_vehicle_flip_profit, get_ebay_sold_comps, decode_vin, and listing-draft tools still work, while lead/inventory tools return a clear persistence configuration error.
Quick Start: Local MCP Server
git clone https://github.com/jongan69/shopping-deals-mcp-server.git
cd shopping-deals-mcp-server
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
cp .env.example .envEdit .env with your own credentials:
EBAY_APP_ID=your-ebay-client-id
EBAY_CERT_ID=your-ebay-client-secret
EBAY_DEV_ID=your-ebay-dev-id
EBAY_MARKETPLACE_ID=EBAY_US
EBAY_USE_SANDBOX=false
EBAY_REDIRECT_URI=your-ebay-oauth-redirect-uri-or-runame
# Optional single-seller shortcut. Prefer OAuth/KV for production.
EBAY_SELLER_REFRESH_TOKEN=your-connected-seller-refresh-token
SHOPPING_ENABLE_AMAZON_SCRAPE=true
SHOPPING_FACEBOOK_MARKETPLACE_LATITUDE=40.7128
SHOPPING_FACEBOOK_MARKETPLACE_LONGITUDE=-74.0060
SHOPPING_OFFERUP_DEFAULT_CITY=Miami Beach
SHOPPING_OFFERUP_DEFAULT_STATE=FL
SHOPPING_OFFERUP_DEFAULT_ZIP=33139
SHOPPING_OFFERUP_DEFAULT_LATITUDE=25.7907
SHOPPING_OFFERUP_DEFAULT_LONGITUDE=-80.1300
SHOPPING_OFFERUP_RADIUS_MILES=30
SHOPPING_RESALE_STORE_PATH=.shopping-deals/resale-business.jsonRun over stdio:
shopping-deals-mcp --transport stdioRun over Streamable HTTP for local testing:
shopping-deals-mcp --transport streamable-http --host 127.0.0.1 --port 8000Local HTTP MCP endpoint:
http://127.0.0.1:8000/mcpAdd To Codex
Local stdio server:
codex mcp add shopping-deals -- /absolute/path/to/shopping-deals-mcp-server/.venv/bin/shopping-deals-mcp --transport stdioRemote Streamable HTTP server:
codex mcp add shopping-deals-remote --url https://shopping-deals-mcp.jonathang132298.workers.dev/mcpVerify:
codex mcp get shopping-deals-remoteAdd To Any MCP Client
Use the local stdio command:
{
"mcpServers": {
"shopping-deals": {
"command": "/absolute/path/to/shopping-deals-mcp-server/.venv/bin/shopping-deals-mcp",
"args": ["--transport", "stdio"]
}
}
}Or use a remote Streamable HTTP endpoint:
https://shopping-deals-mcp.jonathang132298.workers.dev/mcpCloudflare Worker Deployment
This repo includes a TypeScript Worker implementation for remote MCP clients.
Install dependencies:
npm install
cp .env .dev.vars
npm run typecheck
npm run dev -- --port 8787Test locally:
http://127.0.0.1:8787/health
http://127.0.0.1:8787/mcpBefore deploying, change the Worker name in wrangler.jsonc if shopping-deals-mcp is already taken in your Cloudflare account:
{
"name": "your-shopping-deals-mcp"
}Upload secrets:
printf '%s' "$EBAY_APP_ID" | npx wrangler secret put EBAY_APP_ID
printf '%s' "$EBAY_CERT_ID" | npx wrangler secret put EBAY_CERT_ID
printf '%s' "$EBAY_DEV_ID" | npx wrangler secret put EBAY_DEV_ID
printf '%s' "$EBAY_REDIRECT_URI" | npx wrangler secret put EBAY_REDIRECT_URICreate and bind KV for resale lead/inventory persistence:
npx wrangler kv namespace create RESALE_KVAdd the returned namespace ID to wrangler.jsonc:
{
"kv_namespaces": [
{
"binding": "RESALE_KV",
"id": "your-kv-namespace-id"
}
]
}Deploy:
npm run deployYour remote MCP endpoint will be:
https://your-worker.your-subdomain.workers.dev/mcpeBay Seller Automation
The seller-write tools let an agent help run an eBay sales workflow: connect a seller account, check seller readiness, create inventory, upload listing videos, create offers, publish listings, fetch orders, and add shipment tracking.
Seller-write tools require a seller user token. The app keyset belongs to the MCP operator, but listing/order calls act on the eBay account that authorized OAuth. For a multi-user setup, each seller must connect their own eBay account and the Worker stores that seller's refresh token in RESALE_KV.
Recommended connection flow:
Call
ebay_seller_connect_url.Open the returned
authorization_urland approve access as the eBay seller.Copy the returned authorization
code.Call
ebay_exchange_seller_codewith that code.Call
ebay_seller_connection_status.Call
ebay_get_seller_policiesto retrieve fulfillment/payment/return policies and inventory locations.If the account has no policies yet, call
ebay_create_default_seller_policies. The helper reuses existing policies when possible and handles eBay duplicate-policy responses as reuse.
Before publishing, the seller account must have:
Business policies enabled.
Payment, return, and fulfillment policies.
At least one inventory location.
Valid category ID, condition, required item specifics/aspects, price, quantity, and images.
Enough eBay seller limits for the listing.
Listing workflow:
Use
draft_ebay_listingto prepare title, description, photo checklist, disclosures, and pricing guidance.Use
ebay_upsert_inventory_itemto create/update the SKU.Use
ebay_create_offerto create the offer.Use
ebay_publish_offeronly after reviewing the final payload.
For a single combined flow, use ebay_create_listing_workflow. It defaults to review mode: it creates inventory and an offer but does not publish unless publish_immediately is explicitly set to true.
Listing video workflow:
Host the video at a temporary URL the Worker can fetch.
Call
ebay_create_video_upload.Poll
ebay_get_videountil eBay finishes processing.Add the returned
video_idtovideo_idsinebay_upsert_inventory_item.
Listing conversion workflow:
Call
ebay_get_listing_performance_dashboardto audit every active listing.Use
ebay_save_listing_performance_snapshotbefore making changes.Call
ebay_get_listing_asset_workbenchfor the target listings. This returns the actual eBay photo URLs, safe local download commands, and AI edit/video briefs that require those real photos as references.Download the actual product photos locally and inspect them.
Improve the actual listing media: add real item photos, make conservative reference-based AI edits, upload approved images with
ebay_create_image_from_url, upload videos withebay_create_video_upload, and stage live media updates withebay_revise_listing_media.Keep
apply_immediately=falseuntil a human has reviewed the staged photo/video payload.After the listings have had time to collect traffic, save another snapshot and call
ebay_compare_listing_performance_snapshots.
Actual-photo AI asset workflow:
Use
ebay_get_listing_asset_workbenchwith one or moreitem_ids.Run the returned
download_commands, or download from the returned manifest URLs, into the listed output folder.Use those downloaded files as required reference images in your image or video tool.
Keep edits as close to the real asset as possible: crop, straighten, exposure, white balance, background cleanup, sharper composition, and inspection-friendly detail crops.
Do not add missing accessories, remove real flaws, change condition, alter labels/model details, fake operation, or generate unreferenced angles/details.
Keep originals and edited outputs together so an agent can audit what changed.
Host finished assets at HTTPS URLs, upload them through
ebay_create_image_from_urlorebay_create_video_upload, then stage changes withebay_revise_listing_media.
The dashboard combines eBay listing state with asset quality signals: photo count, video count, title usage, description length, bids, watches, views, and eBay Analytics traffic metrics when the connected seller token has Analytics access. Traffic metrics can include impressions, total views, click-through rate, sales conversion rate, and transactions.
For used or pre-owned items, keep the primary image as a real photo of the actual item. AI-generated or edited assets should only improve presentation, such as background cleanup or a supplemental promo visual, and must not change condition, included contents, flaws, serial/model details, or anything a buyer relies on.
Listing photo workflow:
Host the finished image at an HTTPS URL.
Call
ebay_create_image_from_url.If needed, call
ebay_get_imagewith the returned image ID.Use the returned EPS
imageUrlinebay_revise_listing_mediaas part of the completepicture_urlsarray.
Direct Trading API media workflow for existing listings:
Call
ebay_get_listing_detailorebay_get_listing_performance_dashboardto capture the currentpicture_urlsandvideo_ids.Build the complete desired replacement array. eBay media revision replaces the listing's submitted photo/video fields; do not send only one new photo unless you intentionally want only that one photo.
Call
ebay_revise_listing_mediawithapply_immediately=false.After review, rerun with
apply_immediately=true.
Order fulfillment workflow:
Call
ebay_get_orders.Ship the item using your carrier workflow.
Call
ebay_add_order_trackingwith the eBay order ID, carrier code, tracking number, and line items.
The MCP is designed for legitimate seller optimization: better listings, better photos/videos, price discipline, fast fulfillment, and complete disclosures. It should not be used for counterfeit goods, spam listings, misleading descriptions, review manipulation, policy evasion, or any other activity that violates eBay policy.
Optional Tax Estimates
eBay Browse search results do not return the buyer's final checkout tax amount. This server supports estimated tax when you provide a tax rate.
Set defaults:
SHOPPING_ESTIMATED_TAX_RATE_PERCENT=8.875
SHOPPING_TAX_SHIPPING=trueOr pass per tool call:
{
"query": "DJI OSMO Pocket 4P",
"sources": ["ebay"],
"max_results": 5,
"max_results_per_source": 50,
"tax_rate_percent": 8.875,
"tax_on_shipping": true
}Returned listings can include:
priceshipping_costtotal_priceestimated_taxtotal_with_tax
Use find_cheapest_offers when the goal is the lowest estimated final cost.
Example Tool Calls
Find the cheapest exact-model offer by shipped total plus estimated tax:
{
"query": "DJI OSMO Pocket 4P",
"sources": ["ebay"],
"max_results": 10,
"max_results_per_source": 50,
"tax_rate_percent": 8.875,
"tax_on_shipping": true
}Find ranked deals across marketplaces:
{
"query": "sony wh-1000xm5 headphones",
"sources": ["ebay", "facebook_marketplace", "craigslist", "offerup", "amazon"],
"location": "40.7128,-74.0060",
"max_results": 10,
"max_results_per_source": 20,
"condition": "any"
}Find possible eBay flips:
{
"query": "Sony a6700 camera body",
"buy_sources": ["facebook_marketplace", "craigslist", "offerup", "ebay"],
"location": "40.7128,-74.0060",
"max_results": 10,
"max_results_per_source": 25,
"price_max": 700,
"min_profit": 75,
"min_roi_percent": 20,
"purchase_tax_rate_percent": 8.875,
"outbound_shipping": 18
}Calculate resale profit directly:
{
"purchase_price": 500,
"expected_sale_price": 775,
"inbound_shipping": 0,
"outbound_shipping": 18,
"purchase_tax_rate_percent": 8.875,
"platform_fee_percent": 13.25,
"packing_cost": 2
}Save a lead and track it through inventory:
{
"lead": {
"title": "Sony a6700 camera body",
"source": "facebook_marketplace",
"url": "https://www.facebook.com/marketplace/item/example",
"asking_price": 575,
"expected_sale_price": 775,
"status": "watching"
}
}Then use:
update_resale_lead_statuscreate_inventory_itemmark_inventory_listedmark_inventory_soldcalculate_business_metrics
Research a possible car flip:
{
"query": "2012 Honda Fit Miami",
"buy_sources": ["facebook_marketplace", "craigslist", "offerup"],
"location": "25.7907,-80.1300",
"max_results": 5,
"max_results_per_source": 20,
"price_max": 7000,
"min_profit": 2000,
"min_roi_percent": 20,
"repair_cost": 750,
"transport_cost": 500,
"inspection_cost": 150,
"detail_cost": 150,
"title_registration_cost": 450,
"sales_tax_rate_percent": 0,
"vehicles_sold_or_offered_12mo": 0,
"title_status": "unknown",
"has_title_in_hand": null
}Calculate vehicle profit directly:
{
"purchase_price": 7000,
"expected_sale_price": 10500,
"repair_cost": 500,
"transport_cost": 400,
"inspection_cost": 150,
"detail_cost": 150,
"title_registration_cost": 450
}Track vehicle compliance risk:
{
"vehicles_sold_or_offered_12mo": 2,
"planned_new_vehicle_offers": 1
}Reselling Notes
get_ebay_sold_comps is intentionally conservative: today it uses active eBay listing comps as a clearly labeled proxy because the current public eBay Browse API integration does not provide completed/sold listing data. Active comps are useful for initial triage, but confirmed sold comps are better for pricing and sell-through confidence. If you have access to a completed-listing data provider, add it as a dedicated source and keep the basis field explicit.
The arbitrage score is a triage signal. Before buying, verify exact model, condition, serial/authenticity, locks/accounts, missing accessories, seller reputation, local safety, shipping dimensions, return risk, and final marketplace fees.
Vehicle flips are scored with a separate model. eBay Motors vehicle listings use package fees instead of the normal item final-value fee model; this server defaults to $34 at $15,000 or less and $79 above $15,000, matching eBay's current public help page at the time of implementation. Florida has a low dealer-activity threshold: three or more vehicles bought, sold, dealt, offered, or displayed for sale in a 12-month period creates a prima facie presumption of motor vehicle dealer activity. This server surfaces that threshold, but it does not provide legal advice.
Before buying a vehicle, verify title in hand, VIN match, lien status, odometer, accident/flood history, seller identity, mechanical condition, storage, transport, insurance, tax/title fees, and your legal ability to resell.
Search Facebook Marketplace near New York City:
{
"query": "used bike",
"sources": ["facebook_marketplace"],
"location": "40.7128,-74.0060",
"max_results_per_source": 10
}Compare prices:
{
"query": "macbook air m2 16gb",
"sources": ["ebay", "craigslist", "offerup"],
"location": "newyork",
"max_results_per_source": 15
}Compare local areas:
{
"query": "Sony FE 35mm lens",
"sources": ["offerup"],
"areas": ["Miami Beach, FL", "Miami, FL", "New York, NY", "Los Angeles, CA"],
"max_results_per_area": 15,
"price_max": 800
}Configuration
Variable | Required | Description |
| optional | Existing eBay app/user access token for Browse API search. |
| recommended | eBay client ID for OAuth client credentials and seller OAuth. |
| recommended | eBay client secret for OAuth client credentials and seller OAuth. |
| optional | eBay dev ID, stored for account completeness. |
| optional | Defaults to |
| optional | Set |
| required for seller OAuth | eBay OAuth redirect URI/RuName configured in the eBay Developer app. |
| optional | Single-seller refresh-token shortcut. Prefer |
| optional | Temporary seller user access token for testing seller-write calls. |
| optional | Enables Google Shopping via SerpApi. |
| optional | Comma-separated Craigslist sites. |
| optional | Default Facebook Marketplace search latitude. |
| optional | Default Facebook Marketplace search longitude. |
| optional | Facebook Marketplace search radius. Defaults to |
| optional | Default OfferUp city. Defaults to |
| optional | Default OfferUp state. Defaults to |
| optional | Default OfferUp ZIP. Defaults to |
| optional | Default OfferUp latitude. Defaults to |
| optional | Default OfferUp longitude. Defaults to |
| optional | OfferUp search radius hint. Defaults to |
| optional | Enables Amazon public HTML parsing. |
| optional | Request timeout. Defaults to |
| optional | Default per-source search size. |
| optional | Default tax estimate rate. |
| optional | Whether shipping is included in estimated tax base. Defaults to |
| optional | Local JSON path for leads and inventory. Defaults to |
| optional | Cloudflare KV binding for hosted lead/inventory persistence. |
Development
Python checks:
source .venv/bin/activate
pytest
ruff check .Worker checks:
npm install
npm run typecheckLicense
MIT
Notes And Limitations
Deal scores are triage signals, not purchase guarantees.
Arbitrage scores are triage signals, not guarantees of sell-through, profit, authenticity, or buyer demand.
Vehicle opportunity scores are research signals, not legal, title, mechanical, tax, insurance, or dealer-licensing advice.
Always verify seller reputation, return policy, warranty, shipping, taxes, and authenticity before buying.
Amazon, Craigslist, Facebook Marketplace, and OfferUp public parsers may break if those sites change markup or block traffic.
Facebook Marketplace support is experimental. It uses Facebook's public Marketplace web feed with an anonymous page token and requires a local search center.
OfferUp location is set with OfferUp's public
ou.locationcookie. Some markets may still be influenced by OfferUp ranking and availability.Craigslist RSS returns HTTP 403 from Cloudflare Worker egress, so the Worker uses Craigslist static search HTML cards.
Tax is estimated from a supplied rate. Final checkout tax may differ.
eBay sold-comps support currently uses active listing comps as a labeled proxy until a true completed/sold-listing data provider is configured.
Vehicle comps currently use active eBay listing data as a market proxy. Confirm sold results, trim, mileage, title status, accident history, location, and vehicle history before buying.
Available Tools
6 toolscompare_pricesC
Group comparable listings and report low, high, and average observed prices.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sources | No | ||
| location | No | ||
| condition | No | any | |
| price_max | No | ||
| price_min | No | ||
| max_results_per_source | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the output but does not mention behavioral traits like read-only nature, authentication requirements, rate limits, or other side effects.
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 a single, well-structured sentence that front-loads the action. It is concise but could benefit from more detail without becoming verbose.
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 tool has 7 parameters (1 required) and no output schema or annotations, the description is insufficient. It does not explain how grouping works, what sources are, or how filtering by condition or price range operates.
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 description coverage is 0%, and the tool description does not explain any parameter meanings. For example, 'sources', 'location', 'condition', 'price_max', etc., are left entirely to the schema with no additional clarification.
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 groups comparable listings and reports low, high, and average prices. It uses a specific verb-resource combination and differentiates from siblings like find_best_deals which likely returns a single best option.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for price analysis but does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_dealsC
Search products and rank the strongest deals with reasons and warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sources | No | ||
| location | No | ||
| condition | No | any | |
| price_max | No | ||
| price_min | No | ||
| max_results | No | ||
| tax_on_shipping | No | ||
| tax_rate_percent | No | ||
| max_results_per_source | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description hints at ranking and warnings but lacks detail on what 'strongest' means, return format, authentication, or any side effects.
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?
One 12-word sentence is concise but lacks structure. It conveys purpose but no additional details for an agent to use effectively.
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?
With 10 parameters, no output schema, and complex behavior (ranking, warnings), the description is far too minimal. Agents would lack understanding of inputs and outputs.
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 0%; the description does not explain any of the 10 parameters (e.g., query, sources, price_max). No added meaning beyond the schema.
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 uses a specific verb ('Search...rank') and resource ('deals'), and distinguishes from siblings like 'find_cheapest_offers' by mentioning 'strongest deals with reasons and warnings.'
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?
No guidance on when to use this tool vs alternatives like 'find_cheapest_offers' or 'compare_prices.' The description implies ranking but doesn't specify context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_cheapest_offersC
Search products and return exact-model offers sorted by shipped total plus estimated tax.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sources | No | ||
| location | No | ||
| condition | No | any | |
| price_max | No | ||
| price_min | No | ||
| max_results | No | ||
| tax_on_shipping | No | ||
| tax_rate_percent | No | ||
| max_results_per_source | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It mentions sorting by shipped total plus estimated tax but does not explain how tax is estimated, what currency is used, or any side effects. The behavior is only partially disclosed.
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 a single concise sentence, but for a tool with 10 parameters, it is too brief and lacks structure. It could be more informative without being verbose.
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 high parameter count, lack of annotations, and no output schema, the description is severely incomplete. It fails to explain parameters, output, or usage context, making it insufficient for an AI agent.
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 description coverage is 0%, and the description adds no information about any of the 10 parameters. The agent must rely solely on parameter names and types, which is insufficient for correct invocation.
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 searches products and returns exact-model offers sorted by shipped total plus estimated tax. It uses specific verbs and resources, distinguishing it from generic search or compare siblings.
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 implies usage for finding cheap offers with tax included, but does not explicitly state when to use this tool versus alternatives like find_best_deals or compare_prices. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listing_detailsC
Fetch listing details for sources that support detail lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| listing_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the basic action and does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or behavior when a source does not support detail lookups.
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 a single sentence, which is concise, but it lacks key details that would make it informative. It does not front-load the most critical information for an agent.
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?
Without schema descriptions, output schema, or annotations, the description fails to provide necessary context. It does not explain what details are returned, error conditions, or how to handle sources that do not support detail lookups. The tool is underspecified for reliable agent use.
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 description coverage is 0% and the description adds no meaning to the parameters 'source' or 'listing_id'. There is no explanation of acceptable values, formats, or relationship to the source's capabilities.
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 fetches listing details, a verb+resource combination. It hints at a condition ('for sources that support detail lookups') which adds some context, but does not explicitly differentiate from sibling tools like search_products or compare_prices.
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?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusions. The description is generic and does not help an agent decide between this and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sourcesA
List shopping sources and show which credentials or flags are required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately states the tool lists sources and shows requirements, implying a read-only operation, but does not disclose potential auth needs or output format.
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?
Single sentence, 12 words, zero waste. Every word earns its place.
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?
For a simple list tool with no parameters and no output schema, the description covers the core function and output content. Could mention if results are ordered or if authentication is required, but overall complete.
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?
No parameters exist (schema coverage 100%), so baseline 4 applies. Description adds no param info, which 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 uses a specific verb ('List') and resource ('shopping sources') and adds unique value by stating it shows required credentials/flags, distinguishing it from price/comparison siblings.
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?
No guidance on when to use this tool versus alternatives like search_products or compare_prices. The agent is given no context about prerequisites or workflow ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsC
Search enabled shopping platforms and return normalized product listings.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| sources | No | ||
| location | No | ||
| condition | No | any | |
| price_max | No | ||
| price_min | No | ||
| max_results_per_source | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure. It only states the search action and normalized output but omits any side effects, permissions, rate limits, or whether results are paginated. For a search tool, read-only nature is implied but not explicit.
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 a single sentence with no wasted words, but it is too short for a tool with 7 parameters and no annotations. Conciseness is acceptable, but it sacrifices necessary detail.
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 7 parameters, 0% schema coverage, no output schema, and no annotations, the description is severely incomplete. It fails to explain return format, pagination, or any constraints, making it inadequate for an agent to use effectively.
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 description coverage is 0%, and the description provides no explanation of any parameter (query, sources, location, condition, price range, etc.). The agent receives no semantic guidance beyond the parameter names and types in the schema.
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 verb 'Search', the resource 'enabled shopping platforms', and the outcome 'normalized product listings'. This distinguishes it from sibling tools like compare_prices or find_best_deals. However, it doesn't specify what 'enabled' means, slightly reducing clarity.
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?
No guidance is provided on when to use this tool versus alternatives like find_best_deals or get_listing_details. There is no mention of prerequisites or context, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Tools have distinct purposes, but find_best_deals and find_cheapest_offers could be confused initially; descriptions help differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., compare_prices, list_sources.
6 tools is well-scoped for a shopping deals server, covering search, comparison, details, and sources without being excessive.
Covers key operations like search, price comparison, and best deals, but lacks filtering or wishlist features, which are minor gaps for this domain.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for IT hardware parts research: normalize PNs, search listings, get subs/comps.
Google Shopping products, prices, sellers, and deals as structured data via a hosted MCP server.
MCP server for real-time product search by barcode (EAN, UPC, GTIN) or keyword on ean-search.org
MCP server for ua_e_commerce_price_tracker_mcp
Related MCP Servers
AlicenseNot gradedqualityDmaintenanceMCP server for scraping product prices, offers, reviews, and details from Amazon, Google Shopping, Bol.com, and Coolblue via natural language commands, with spend-cap protections.321MIT- AlicenseNot gradedqualityBmaintenanceAn MCP server that lets an LLM search Geizhals, a leading German/DACH price-comparison site, for the cheapest offers on new products.MIT
- FlicenseAqualityBmaintenanceMCP server that acts as a shopping assistant, enabling product search, comparison, deal finding, and price history tracking via Hound web search.6
- FlicenseNot gradedqualityBmaintenanceMCP server that enables AI agents to search and compare products and generate Amazon affiliate purchase links.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jongan69/shopping-deals-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server