Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

facebook_marketplace_search

Search Facebook Marketplace listings by location and query or category to get titles, prices, cities, and thumbnails from the first page of results.

Instructions

Search Facebook Marketplace. Fetches Facebook Marketplace search or browse results for a location: listing id, title, price, city/state, and a thumbnail image per result. Only the first page Facebook's own server-rendered results page returns is available — Facebook's own further pagination requires a logged-in session and is out of scope. Omit both query and category to get the location's browse feed instead of running a search. minPrice, maxPrice, sortBy, daysSinceListed, and condition only take effect alongside a query or category (Facebook itself ignores them on the plain browse feed), except for the property_rentals category, which has its own always-filtered listing page. This endpoint can take noticeably longer than other search endpoints (up to roughly a minute in the slowest case) as it retries to get past an intermittent upstream condition; priced accordingly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoFree-text search terms; omit (with category) for the location's browse feed
sort_byNoResult order; requires query or category
categoryNoMarketplace category
locationYesFacebook Marketplace location vanity slug
conditionNoComma-separated listing conditions; requires query or category
max_priceNoMaximum price in whole currency units; requires query or category
min_priceNoMinimum price in whole currency units; requires query or category
days_since_listedNoRestrict to listings posted within this many days; requires query or category

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.17.5
    • addedInput schema / properties / category / enum
      Added value: +[
+  "vehicles",
+  "property_rentals",
+  "classifieds",
+  "apparel",
+  "electronics",
+  "entertainment",
+  "family",
+  "free",
+  "garden_outdoors",
+  "hobbies",
+  "home_goods",
+  "home_improvement",
+  "musical_instruments",
+  "office_supplies",
+  "pet_supplies",
+  "property_sale",
+  "sporting_goods",
+  "toys_games"
+]
    • addedInput schema / properties / condition / enum
      Added value: +[
+  "new",
+  "used_like_new",
+  "used_good",
+  "used_fair"
+]
    • addedInput schema / properties / days_since_listed / enum
      Added value: +[
+  1,
+  7,
+  30
+]
    • addedInput schema / properties / sort_by / enum
      Added value: +[
+  "best_match",
+  "distance_ascend",
+  "creation_time_descend",
+  "price_ascend",
+  "price_descend"
+]
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations at all, the description carries the full disclosure burden and does so richly: it explains that only the first server-rendered page is available, why (logged-in pagination out of scope), that the endpoint may take up to roughly a minute, that it retries against an intermittent upstream condition, and that Facebook itself ignores certain filters on the plain browse feed. This goes well beyond any structural metadata.

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?

Every sentence earns its place: core purpose and output fields first, then behavioral constraints, then filter interaction, then performance/latency. There is no fluff, and the most decision-relevant information (search vs. browse, pagination limits) is front-loaded.

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 tool with 8 parameters, no annotations, and no output schema, the description is remarkably complete: it defines the return fields, explains the two modes, documents pagination limits, filter conditions, and the property_rentals special case, and sets performance expectations. An agent has everything needed to call this endpoint correctly and anticipate costs.

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. The description adds real value by clarifying the interaction between query/category and the filter parameters, including the property_rentals exception that the schema does not mention. It does not, however, add syntax or format details for individual parameters beyond what the schema already documents.

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?

The description opens with a specific verb and resource ('Search Facebook Marketplace') and immediately expands into what is fetched: listing id, title, price, city/state, and a thumbnail per result. It also distinguishes the search mode from the browse-feed mode, so an agent can tell exactly what this tool does versus other endpoints.

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

Usage Guidelines5/5

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

Provides explicit, actionable guidance: omit both query and category to get the browse feed, and notes that filters only take effect alongside query or category, with the property_rentals exception. It also gives an exclusion (pagination is out of scope without a logged-in session) and a latency warning, which are exactly the kind of when/when-not details an agent needs.

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