Loading ToolBench
eBay Browse API MCP server. Exposes two tools: search_ebay, get_item_details. Works with any MCP-compatible host (Claude Desktop, Cursor, VS Code Copilot, Cline, Continue, Zed, Windsurf, LM Studio, Goose, etc).
Two tools with complete input schemas and detailed descriptions. Both tools follow verb_noun naming (search_ebay, get_item_details) and include comprehensive parameter documentation with examples and constraints. Descriptions are 150-250 chars, within the 10-1024 baseline. However, output schemas are not formally documented in the tool definitions, the docstrings describe return fields informally rather than as structured JSON Schema. Parameter descriptions include examples (e.g., 'price:[100..500],priceCurrency:GBP') which could be replaced with formal constraints. No error handling guidance or recovery paths documented. No tool annotations (readOnlyHint, idempotentHint) despite both being read-only operations.
Retrieve full details of a specific eBay item. Use this when search_ebay has surfaced an item and you need richer information: full description, item specifics (aspects), shipping options, return policy, all images, seller details, etc. Args: item_id: REST item identifier from search_ebay's "item_id" field (format: "v1|<numeric>|0"). Legacy numeric IDs alone are not accepted by this endpoint. fieldgroups: Optional response shaping. - None (default): full item details - "COMPACT": small subset for change detection (price, availability, revision id, top-rated status) - "PRODUCT": default plus product catalogue info Returns: Simplified dict with the most useful fields: title, price, condition, description, item specifics, images, shipping options, return policy, seller, location, and url. The "raw" key holds the full Browse API response in case anything was filtered out.
Search eBay listings via the Browse API. Args: query: Search keywords. Examples: "macbook pro m3 64gb", "tesla model 3 floor mats", "vintage rolex". limit: Maximum results to return (1-200, default 10). filter_expr: Browse API filter syntax. Examples: - "price:[100..500],priceCurrency:GBP" (price range) - "conditions:{NEW}" (new items only) - "buyingOptions:{FIXED_PRICE}" (Buy It Now only) - "itemLocationCountry:GB" (UK sellers only) Combine with commas. sort: "price" (ascending), "-price" (descending), "newlyListed", "endingSoonest". Default is Best Match. Returns: Simplified dict with: environment, marketplace, query, total, returned, and items list. Each item includes "item_id" which can be passed to get_item_details for the full record.
Output schemas not formally documented. Docstrings describe return fields informally (e.g., 'Simplified dict with...') rather than as structured JSON Schema. LLMs cannot reliably parse unstructured output descriptions to plan downstream calls.
No error handling guidance. Tool descriptions do not explain what errors can occur, how to recover, or what the LLM should do if a call fails (e.g., invalid item_id format, API rate limit, network timeout).
Tool annotations missing. Both tools are read-only and idempotent, but lack readOnlyHint and idempotentHint annotations. This prevents MCP clients from optimizing caching and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Example values embedded in parameter descriptions (e.g., 'price:[100..500],priceCurrency:GBP', 'macbook pro m3 64gb'). LLMs tend to reuse examples literally rather than adapting to context. Replace with formal enum/pattern constraints.
No pagination support documented for search_ebay. If the API returns many results, the tool description does not explain how to limit or paginate. The 'limit' parameter exists but no mention of offset, cursor, or total count in the response.