Skip to main content
Glama

run_olx_offers_search

Search live OLX ads by keyword and filter by category, price, condition, seller type, location, delivery, and sort. Find current marketplace offers across supported OLX domains.

Instructions

Search live OLX ads by keyword with category, price, condition, seller type, location, delivery and sort. 1 point per returned record.

Input Schema

NameRequiredDescriptionDefault
sortNoSort by. Options: relevance = Relevance, newest = Newest, oldest = Oldest, price_asc = Price: low to high, price_desc = Price: high to low
domainNoMarketplace. Options: olx.pl = olx.pl (Poland), olx.ua = olx.ua (Ukraine), olx.ro = olx.ro (Romania), olx.bg = olx.bg (Bulgaria), olx.pt = olx.pt (Portugal), olx.kz = olx.kz (Kazakhstan), olx.uz = olx.uz (Uzbekistan)
city_idNoCity ID
keywordNoSearch term. e.g. iphone
user_idNoSeller user ID
distanceNoDistance (km around the city)
conditionNoCondition. Options: new = New, almost-new = Almost new, used = Used, refurbished = Refurbished, outlet = Outlet, damaged = Damaged, others = Others
max_itemsNoMax items (up to 500)
max_priceNoMax price (marketplace currency)
min_priceNoMin price (marketplace currency)
region_idNoRegion ID
owner_typeNoSeller type. Options: private = Private sellers, business = Business sellers
start_pageNoStarting page (50 offers per page, up to 20)
category_idNoCategory ID
district_idNoDistrict ID
has_deliveryNoOLX delivery only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.1

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral fact the schema does not carry: billing at 1 point per returned record. However it says nothing about pagination limits behavior, auth/marketplace requirements, or what the response looks like.

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?

Two short clauses, front-loaded with the verb and resource, then the billing note. Nothing is redundant. It is not a 5 because the facet enumeration is somewhat boilerplate list-building rather than prioritizing what an agent most needs.

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

Completeness3/5

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

For a 16-parameter tool with no annotations and no output schema, the description is thin. It does not explain that all parameters are optional, how IDs like city_id/category_id are sourced (run_olx_categories, run_olx_regions), or pagination behavior, leaving real gaps for an agent to fill.

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 every parameter is already documented with enums and ranges, which sets the baseline at 3. The description's facet list (category, price, condition, seller type, location, delivery, sort) mirrors parameters without adding syntax, formats, or cross-parameter constraints.

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 gives a specific verb+resource ('Search live OLX ads') plus the facet dimensions it covers (category, price, condition, seller type, location, delivery, sort). This is more than a restatement of the name. It falls short of a 5 only because it doesn't differentiate from the closely named sibling run_olx_offers.

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 implied by 'Search ... by keyword' and the cost note ('1 point per returned record') hints at a metered operation, but there is no explicit when/when-not guidance and no routing to alternatives such as run_olx_offers, run_olx_users_offers, or the category/region lookup tools an agent would need to obtain IDs.

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