Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

wallapop_search

Search public Wallapop listings by keyword and caller-supplied coordinates, then filter by category, price, condition, distance, shipping, and date; use cursors to page through results.

Instructions

Search Wallapop public listings. Returns one page of public Wallapop listing cards with title, price, currency, images, coarse location, taxonomy, shipping state, and a public item URL. q is a free-text search. latitude and longitude are required caller-provided coordinates because Wallapop otherwise resolves location from the request egress. category_id accepts any ID returned by /wallapop/categories, including descendants. sort is one of closest, most_relevance, newest, price_low_to_high, or price_high_to_low. When category_id is supplied, discover condition values from /wallapop/filters; categories can add values beyond the base set. Use /wallapop/filter-options for remote filter values. Pass next_cursor back as cursor by itself to fetch the next page.

Input Schema

NameRequiredDescriptionDefault
qYesFree-text listing search, 2 to 200 characters
sortNoWallapop sort order
cursorNoOpaque next_cursor returned by a previous response. Use it alone, without initial search parameters.
filterNoRepeatable category-specific key:value pair discovered from /wallapop/filters, e.g. brand:BMW, color:Black, has_warranty:true, storage_capacity:128gb, item_language:english, or fashion_size:3,4. For remote values use IDs returned by /wallapop/filter-options.
latitudeYesCaller-provided search latitude, -90 through 90
conditionNoRepeatable or comma-separated condition values. With category_id, use the current values from /wallapop/filters; without category_id, base values are new, as_good_as_new, good, fair, and has_given_it_all.
longitudeYesCaller-provided search longitude, -180 through 180
max_priceNoMaximum sale price
min_priceNoMinimum sale price
category_idNoAny live search taxonomy ID from /wallapop/categories
time_filterNoListing date window
is_shippableNoPass true to limit to shipping-capable listings; omit to include all. false is rejected because Wallapop ignores it.
distance_in_kmNoMaximum distance from the supplied coordinates, 0 through 1000 km

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.5/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 does substantial work: it discloses the return shape (one page of listing cards), the pagination mechanism, and the non-obvious behavioral quirk that coordinates are required because location would otherwise resolve from request egress. It omits rate limits, auth requirements, and page-size limits, so a small gap remains for a 13-parameter search endpoint.

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

Conciseness5/5

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

Purpose and return shape are front-loaded in the first two sentences, followed by parameter-specific notes in a logical order (q, coordinates, category, sort, filters, cursor). Every sentence carries information; the only mild redundancy is restating the sort enum and cursor rule already present in the schema, but these read as reinforcement rather than padding.

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

Completeness5/5

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

For a 13-parameter search tool with no output schema and no annotations, the description supplies what structured fields cannot: the returned fields, the pagination loop, and the dependency chain to wallapop_categories/filters/filter-options. An agent has everything needed to call it correctly and page through results.

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, and the description earns an upgrade by adding rationale the schema cannot: why latitude/longitude are mandatory (egress-based location fallback), that category_id accepts descendants of any /wallapop/categories ID, and that condition values are category-dependent via /wallapop/filters. The sort enumeration and cursor instruction duplicate the schema, which keeps it from a 5.

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

Purpose5/5

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

Opens with a specific verb+resource ('Search Wallapop public listings') and immediately enumerates the returned card fields (title, price, currency, images, location, taxonomy, shipping state, URL), which pins down exactly what this tool produces. Sibling tools like wallapop_item_detail, wallapop_categories, wallapop_filters, and wallapop_filter_options are implicitly distinguished because the description routes to them for detail and filter discovery.

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?

Gives clear operating context: lat/long must be caller-provided because Wallapop otherwise derives location from request egress, and it names the sibling tools to consult for category IDs, condition values, and remote filter values. It also explains the pagination protocol (pass next_cursor back as cursor alone). It does not explicitly state when to prefer wallapop_item_detail over this tool, so it stops short of full when/when-not coverage.

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