Loading ToolBench
Real Amazon (US/UK/DE/CA/AU/FR/IT/ES/JP/MX/BR) & Walmart shopping data for Claude, ChatGPT, and any MCP client. Hosted at https://api.logimu.com/mcp (free, no signup: 30 queries/day).
Four tools with comprehensive descriptions (194-500+ chars each) following a deliberate format: <purpose> / USE WHEN / DON'T USE / RETURNS / MARKETPLACES / COST. All tools have detailed input schemas with parameter descriptions. Tool names are action-oriented (product, shopping, search, serp). However, there are gaps: no output schemas are documented, error handling is not formalized in tool definitions, and no tool annotations (readOnlyHint, etc.) are present. The descriptions are exceptionally long and detailed (approaching verbosity) but functional for LLM selection. Parameter validation rules and constraints are embedded in descriptions rather than JSON Schema enforcements.
Full dossier for ONE known product: its current snapshot plus its observed history. USE WHEN the user has a specific ASIN, Walmart item ID, product link, or a product_id returned by shopping or search, and asks about price history, historical prices, price changes, 30-day history, stock history, seller history, buy-box history, historical analysis, 'analyse this product', 'is this a good buy', 'has the price moved/dropped', 'who is selling this', 'is it in stock'. This is the ONLY tool that returns history: shopping and search return current values, so any historical question about a product they listed comes here. DON'T USE to discover products from a keyword (use shopping) or to pull a filtered list (use search). RETURNS current price, BSR, rating, review count, stock, buy-box seller and seller count, plus an observed_at freshness stamp, full price_history and stock_history back to first observation (keyed; the free lane carries the 30-day views), change events tagged with the buy-box seller at each change, the current all-seller offer table with 30-day buy-box days (each seller row carries fulfillment AMZ/FBA/FBM and delivery days), a fulfillment block (buy-box AMZ/FBA/FBM, offer counts, whether Amazon sells and holds the buy box, buy-box delivery days and dispatch latency), the bought-past-month badge (measured aggregate buyer behavior, not an estimate), and brand stats. Amazon answers also carry the observed product-page content block: description (with description_source), feature_bullets, images, breadcrumbs, variations with variation_count and parent_asin, stamped content_observed_at — content_observed_at:null with empty arrays means the content crawl has not captured this ASIN yet, never 'this product has no description/gallery'. For the ~17% of the catalog with no overall rank (media, books, niche items), bsr_leaf and bsr_leaf_category carry the best category rank instead. Every response carries a data_source field naming the marketplace the numbers were observed on (e.g. 'amazon US marketplace — observed listings') — attribute prices to that source when presenting them; they are marketplace listings, not manufacturer or site-wide prices. MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br, walmart. Walmart takes a numeric item ID (or gtin= with the item's UPC) and returns the intelligence blocks plus its listing content: image_url, description, breadcrumbs, highlights (spec name/value pairs), warnings, upc, rating/review_count, was_price, in_stock, and shipping_cost per seller (no live scrape on Walmart). COST free lane 1 of 30 daily queries, cache only, and returns the snapshot + 30-day views (the full history streams, bsr_history, offer_history and live scrapes need an API key (plans from $19/mo) — the response's locked block lists exactly what a key unlocks). Keyed: 0.5 credits from cache, 1 for a live scrape, +0.5 for the intelligence blocks, +0.5 each for bsr_history and offer_history. Misses and partial scrapes are never billed; a miss may return a hint (found on another marketplace, or retry with mode=live). SELLER FEEDBACK (2026-09-18): every response carries seller_ratings - one entry per seller the answer names (current offers, cheapest new/used, buy-box holder and, with offer_history, every historical seller) with seller_positive_pct, seller_feedback_count, seller_rating and observed_at from a nightly seller-feedback table; offer_history.sellers[] rows carry the same fields directly. Amazon's own offers have no feedback. Not billed.
No documented output schemas for any tool. LLMs cannot plan multi-step calls or know what fields will be returned. Tool descriptions mention what will be returned (e.g., 'RETURNS current price, BSR, rating, review count...') but no formal JSON Schema defines the response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in tool definitions. All four tools are read-only (no side effects), but this is not formally declared in the schema. Without annotations, agents cannot reason about safety or idempotency.
Error handling and recovery guidance not formalized in tool definitions. Descriptions mention billing, API key requirements, and rate limits (e.g., 'API key required (no free-lane live fetches)'), but no error codes, error messages, or recovery actions are defined. LLMs will not know what to do on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | 2026-07-28+ | v2 |
Filtered view of marketplace products: the SHOPPING tool applies the marketplace's search ranking; SEARCH applies a client-side filter (minimum price, maximum price, minimum rating, in_stock, seller_count, bsr_range, brand, category, condition — brand and category are Amazon-only). USE WHEN the user narrows down by price ('under $100'), rating ('4+ stars'), stock ('in stock'), seller count ('sold by Amazon'), or brand/category (Amazon only). shopping works better for discovery; search works better for filtering a result set. DON'T USE to discover new products from scratch — use shopping for that, then refine. Either shopping or search can start a query; if the query asks for filters, prefer search; if it's just a keyword, prefer shopping, then optionally refine via search's filter API. RETURNS filtered product rows per shopping, each row carrying product_id, title, current price, rating, review_count, stock, seller_count and bsr. MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br, walmart. COST ceil(total_matched / 25) credits on every request (i.e., a 40-product match = 2 credits, 100 products = 4), 0 when empty. Free lane is cache-only and clamped to 25 results.
Real Google Shopping results for a query. Live scrape only; use mode=live or mode=auto (never cache). USE WHEN the user asks 'where can I buy [product]', 'find [product] prices online', 'compare prices for [product]', 'find the cheapest [product]', or 'show me [product] across retailers'. Google Shopping captures a real-time view of thousands of retailers (Amazon, Walmart, Newegg, Best Buy, Target, etc.); Amazon and Walmart results are scraped from their native APIs (product tool), Google Shopping augments with other retailers. DON'T USE to track a product's history (use product), to discover products by keyword on a single marketplace (use shopping), or to filter a marketplace's catalog (use search). RETURNS top N shopping result rows per the Google Shopping query, each carrying retailer name, product price, availability, URL (to the retailer's product page), and a data_source field. Google Shopping results are real-time and volatile — do not compare semantically with product / shopping / search results (different sources, ranking, freshness). MARKETPLACES web (all retailers Google indexes — Amazon, Walmart, Best Buy, Target, Newegg, etc.; not a single marketplace). COST 1 credit per page actually fetched (Google Shopping returns results in pages; if you ask for 10 results from page 1, it's 1 credit; if you ask for 100 results spanning pages 1–4, it's 4 credits). Blocked requests (402, 502, etc.) and empty pages are not billed. API key required (no free-lane live fetches). Real-time anti-bot headers apply; requests are rate-limited.
Current marketplace snapshot for PRODUCTS MATCHING a query (keyword, brand, ASIN, etc.) — NOT filtered. USE WHEN the user asks for products matching a query (e.g. 'show me headphones under $100', 'list laptop cooling pads', 'find USB-C cables', 'show products like [ASIN]'), or wants to browse a category or brand's catalog. shopping answers the question 'what products exist that match this criterion' using the marketplace's own search engine, returning the top N product rows with current price, BSR, rating, stock status, and seller count. Search queries are naturally imprecise — a 'laptop cooling pad' search will include some cooling products that aren't pads, and some pads that aren't for laptops. DON'T USE to fetch a KNOWN product's history or details (use product instead). RETURNS top N product rows per the query, each carrying product_id, title, current price, buy-box seller name, rating, review count, stock status (in_stock true/false), estimated days in stock (in_stock_days), seller_count (how many sellers are listing the product), bsr, and a data_source field (Amazon or Walmart). MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br, walmart. COST free lane max 25 rows; if total >= 1, charged ceil(total / 25) credits (i.e., a 40-row answer costs 2 credits, 100 rows = 4 credits), else 0 when empty. Keyed clients: ceil(rows / 25) on every request. Cache-mode answers (no API key, default) are never billed; live scrapes cost 2 credits. Detail (current_sellers, stock_history, bought_past_month) costs 5 credits total for a keyed client, 3 extra for cache. Every result row carries a product_id that maps to the product tool.
Parameter constraints (e.g., max_rows clamped to 25 for free tier, 1000 for keyed clients; country enum values) are embedded in descriptions as prose, not enforced in JSON Schema. Constraints like 'min_price', 'max_price', 'min_rating' lack numeric bounds in the schema (no 'minimum', 'maximum', or 'enum' keywords visible in the provided excerpt).
Descriptions are verbose (450-500+ chars for 'product' and 'shopping'), approaching the 1024-char upper bound. While detailed, they risk token waste and context dilution. Could be condensed: move cost/billing details and marketplace lists to separate configuration or reference docs.
No pagination or result-limiting guidance in schema definitions. 'shopping' and 'search' mention max_rows parameters, but the default (25) and keyed max (1000) are documented only in prose descriptions, not enforced in the schema. No 'offset', 'cursor', or 'next_cursor' fields mentioned in output.