Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

goldin_search

Search and browse Goldin's auction and fixed-price lots by keyword, category, certification, item type, auction ID, filters, and sort order.

Instructions

Search Goldin's lot auction inventory. Browse or search Goldin's current lot inventory by free-text keyword, category, sub_category, certification, item_type, and auction_id, in a caller-selected sort order. Every filter is optional and combines with AND semantics. All enum values come from goldin-categories -- pass the matching auction_type to both. The Auction pool (default) and the Fixed Price "Private Sales" marketplace are disjoint item pools with different certification/item_type values and different sort enums.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number, defaults to 1
sortNoOne value from goldin-categories' own sort field for the same auction_type. Auction pool: Featured (default), Ending_Soonest, Highest_Bids, Lowest_Bids, Most_Bids, Least_Bids, Most_Recent_Bids, Highest_Lot_Number, Recently_Started. Fixed Price pool: Recently_Created (default), Highest_Bids, Lowest_Bids
keywordNoFree-text search across lot titles/descriptions
categoryNoOne value from goldin-categories' category field
item_typeNoOne value from goldin-categories' item_type field
page_sizeNoPage size, defaults to 24, capped at 96
auction_idNoOne auction id from goldin-categories' auctions field -- only meaningful for auction_type Auction
auction_typeNoAuction (default) or Fixed_Price -- selects which lot pool to search
sub_categoryNoOne value from goldin-categories' sub_category field
certificationNoOne value from goldin-categories' certification field

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4/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 behavioral burden, and it discloses meaningful traps: the Auction pool and Fixed Price 'Private Sales' marketplace are disjoint, their certification/item_type values differ, their sort enums differ, and enum values must come from goldin-categories with a matching auction_type. It does not cover return format, pagination behavior, or auth, but the key behavioral caveats are explicit.

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?

Four sentences, dense and mostly non-redundant. The first sentence ('Search Goldin's lot auction inventory') mildly overlaps with the second, but there is no fluff and the critical caveats are front-loaded before the long parameter list.

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?

For a 10-parameter, 0-required search tool with no output schema, the description covers the main failure modes: optional filters, AND semantics, enum provenance, pool disjointness, and pool-specific sort behavior (defaults are left to the schema). Missing only return-value expectations and pagination shape, which is partly mitigated by the schema documenting page/page_size defaults.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: all filters combine with AND, enum values must be sourced from goldin-categories using the same auction_type, and sort/certification/item_type enums differ between the two pools. This cross-parameter guidance is not present in the individual parameter descriptions.

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?

The description states a specific verb and resource ('Search Goldin's lot auction inventory') and enumerates the filter dimensions (keyword, category, sub_category, certification, item_type, auction_id) plus caller-selected sort order. The phrase 'lot inventory' distinguishes it from sibling tools like goldin_auctions or goldin_listing, though it never names an alternative explicitly.

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

Usage Guidelines4/5

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

It gives clear context: browse or search current inventory, every filter is optional, and filters combine with AND semantics. It also directs the agent to goldin-categories for enum values and requires matching auction_type, and it warns that the Auction and Fixed Price pools are disjoint. However, it does not state when to prefer a sibling such as goldin_listing for a specific lot, so there are no explicit exclusions.

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