Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

ebay_search

Search eBay listings by keyword and filter by active, sold, completed, or sold_completed status. Returns item IDs, titles, links, images, prices, bids, seller, shipping, and sold/watcher counts.

Instructions

Search eBay listings. Searches eBay listings by keyword from a JSON body, with page, page size (60, 120 or 240) and a listing-status filter (active, sold, completed or sold_completed). Each result has the item id, title, link, image, price or price range, bid count, seller and rating, location, shipping information, and sold and watcher counts.

Input Schema

NameRequiredDescriptionDefault
optionYeseBay search payload

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / option / properties
      Added value: +{
      +  "keyword": {
      +    "description": "keyword to search on Ebay",
      +    "type": "string"
      +  },
      +  "limit": {
      +    "description": "Number of items per page",
      +    "enum": [
      +      60,
      +      120,
      +      240
      +    ],
      +    "type": "integer"
      +  },
      +  "listing_type": {
      +    "description": "Listing type to search",
      +    "enum": [
      +      "active",
      +      "sold",
      +      "completed",
      +      "sold_completed"
      +    ],
      +    "type": "string"
      +  },
      +  "page": {
      +    "description": "Page number",
      +    "type": "integer"
      +  }
      +}
    • addedInput schema / properties / option / required
      Added value: +[
      +  "keyword"
      +]
  2. First observedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: input comes from a JSON body, page-size choices, and a listing-status filter, plus an enumeration of every returned field. It omits auth requirements, rate limits, and result-size/pagination behavior, but for a read-only search it is above average.

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

Conciseness4/5

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

Front-loaded with purpose in the first clause, then input options, then return fields. The final result-field enumeration is long but earns its place by substituting for the absent output schema; no filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations exist, so the description must cover both, and it does describe the returned fields and the input contract including the nested object. It lacks sorting, filtering beyond status, and operational caveats, but is otherwise complete for a search tool.

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 schema already documents keyword, page, limit, and listing_type. The description restates the enum values and notes the payload is a JSON body, but adds no syntax or format detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Search eBay listings") and adds scope detail: keyword-driven, JSON body, pagination, and listing-status filter. It is easy to separate from ebay_item and ebay_seller_* siblings, but it never explicitly names or contrasts with them, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is only implied by "Searches eBay listings by keyword." There is no explicit when-to-use framing, no statement about when to prefer ebay_item or the seller tools, and no prerequisites or exclusions. Adequate but with clear gaps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools