Skip to main content
Glama
maxaiassistant77

Facebook Marketplace MCP

by maxaiassistant77
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript

Facebook Marketplace MCP

A focused Model Context Protocol server for searching Facebook Marketplace from AI agents.

This repo is a hardened, Facebook-only variant inspired by jlsookiki/secondhand-mcp. It keeps the useful Facebook Marketplace search and details flow, removes the eBay/Depop/Poshmark paths, and avoids browser automation entirely.

What It Does

  • Search Facebook Marketplace listings by query, city, and price range

  • Get full listing details from a returned listing ID

  • Return listing title, price, location, seller name when available, URL, description, delivery type, and photo URLs

  • Prefer exact US city matches when Facebook returns ambiguous locations

Related MCP server: Meta Ads MCP

Safety Defaults

  • No Facebook login

  • No Facebook cookies

  • No Chrome or headless browser automation

  • No browser profile access

  • No eBay API keys

  • No paid APIs

The server only calls Facebook public/internal Marketplace GraphQL endpoints. These endpoints can change, so the tool may need maintenance if Facebook updates its frontend operation IDs.

Install

Requires Node.js 20.18.1+.

npm install
npm run build

MCP Config

Claude Desktop

Add this to your Claude Desktop MCP config:

{
  "mcpServers": {
    "facebook-marketplace": {
      "command": "node",
      "args": ["/absolute/path/to/facebook-marketplace-mcp/dist/index.js"]
    }
  }
}

OpenClaw

openclaw mcp add facebook-marketplace \
  --command node \
  --arg dist/index.js \
  --cwd /absolute/path/to/facebook-marketplace-mcp \
  --include search_marketplace,get_listing_details,list_marketplaces

Tools

search_marketplace

Search Facebook Marketplace.

Parameters:

  • query required: search terms, for example go kart

  • location optional: city or area, default phoenix

  • maxPrice optional: maximum price

  • minPrice optional: minimum price

  • limit optional: maximum results, default 20, Facebook caps one request at 24

  • showSold optional: include sold/pending/unavailable listings

  • includeImages optional: include image URLs in search results

Example:

{
  "query": "go kart",
  "location": "phoenix",
  "maxPrice": 1500,
  "limit": 5
}

get_listing_details

Get full details for one listing.

Parameters:

  • listingId required: ID from search_marketplace

Example:

{
  "listingId": "999433246010406"
}

list_marketplaces

Returns the enabled adapter and auth status.

Development

npm install
npm run build
npm audit --omit=dev

Quick smoke test:

node dist/index.js

Use an MCP client to call search_marketplace with a small limit before increasing scan volume.

Limitations

  • Facebook can change its internal GraphQL doc_id values without notice.

  • Location matching depends on Facebook's location search results.

  • Search radius is currently fixed to the same local radius used by the upstream implementation.

  • Respect Facebook's terms and rate limits. Do not hammer the endpoint.

Attribution

Derived from the Facebook Marketplace implementation in:

https://github.com/jlsookiki/secondhand-mcp

Original project copyright belongs to its author. This repo keeps the MIT license.

License

MIT

Available Tools

3 tools
get_listing_detailsA

Get full Facebook Marketplace listing details using a listing ID returned from search_marketplace.

ParametersJSON Schema
NameRequiredDescriptionDefault
listingIdYesFacebook Marketplace listing ID.

TDQS

A4.2/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 implies the tool is read-only by stating 'Get...details', but does not explicitly disclose behavior such as side effects, required permissions, or data freshness. For a simple retrieval tool, this is adequate but not thorough.

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?

The description is a single, well-structured sentence that front-loads the purpose and context. No unnecessary words; every part contributes meaning.

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?

Given the low complexity (1 param, no output schema), the description is nearly complete. It states the input source and output scope ('full details'). A minor gap is lack of explicit return format, but it's acceptable for a simple tool.

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% with a clear parameter description. The description adds value by tying the listingId to search_marketplace output, providing context beyond the schema. This helps the agent understand the parameter's origin.

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 clearly states the verb 'Get', the resource 'full Facebook Marketplace listing details', and specifies the source of the listing ID ('returned from search_marketplace'). It effectively distinguishes the tool from siblings search_marketplace (search) and list_marketplaces (list).

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?

The description provides clear guidance that the tool should be used after a search via search_marketplace, indicating a workflow dependency. It does not explicitly mention when not to use or alternative tools, but the context is sufficient for simple usage.

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

list_marketplacesA

List the enabled marketplace adapter and auth status.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. It only states what the tool lists, but does not disclose any behavioral traits such as whether it requires authentication, whether results are paginated, or if there are any side effects.

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?

A single sentence that is front-loaded with the verb 'List'. No unnecessary words, achieving high conciseness.

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?

The description is simple and adequate for a zero-parameter tool, but could be improved by clarifying what a 'marketplace adapter' is or what 'auth status' includes. Given no output schema or annotations, some additional context would enhance completeness.

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?

With zero parameters and 100% schema coverage, the description adds value by explaining the tool's purpose. No parameter details needed; baseline 4 is appropriate.

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 clearly states the verb 'List' and the resource 'enabled marketplace adapter and auth status', which distinguishes it from sibling tools like 'search_marketplace' and 'get_listing_details'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention any context or exclusions, leaving the agent to infer usage.

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

search_marketplaceA

Search Facebook Marketplace by query, location, and price. No Facebook login, browser automation, cookies, or profile access required. Use get_listing_details with a returned listing ID for description, seller, delivery type, and photos.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return. Facebook currently caps a single request at 24.
queryYesSearch query, for example "go kart", "dirt bike", or "toolbox".
locationNoCity or area to search, for example "phoenix", "scottsdale", "los angeles", or "austin". US city matches are preferred when Facebook returns ambiguous cities.phoenix
maxPriceNoMaximum price filter.
minPriceNoMinimum price filter.
showSoldNoInclude sold, pending, hidden, or unavailable listings.
includeImagesNoInclude image URLs in search results. Details always include all photo URLs.

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided, so description bears full burden. It discloses no auth needed and a Facebook cap of 24 results, but lacks info on rate limits, response format, or potential scraping behavior.

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?

Three sentences covering purpose, no-auth detail, and follow-up action. No filler, each sentence serves a purpose.

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?

Given 7 parameters and no output schema, the description implies search returns listing IDs (via get_listing_details reference) and basic info. It covers essentials but lacks sorting or explicit field list.

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 baseline is 3. The description adds value by noting the Facebook cap on limit and US city preference for location, exceeding the schema's descriptions.

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 uses a specific verb 'Search' and resource 'Facebook Marketplace' with key filters (query, location, price). It distinguishes from sibling tools by explicitly mentioning get_listing_details for detailed info.

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 states no login, automation, or cookies required, indicating safe usage. It also suggests using get_listing_details for more details, but does not explicitly state when not to use this tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedget_listing_details
    • First observedlist_marketplaces
    • First observedsearch_marketplace
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a unique purpose: search finds listings, get_listing_details retrieves full details, and list_marketplaces shows adapter status. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun convention in snake_case (search_marketplace, get_listing_details, list_marketplaces), making them predictable.

Tool Count4/5

Three tools is minimal but appropriate for a focused server covering search and retrieval. Could potentially include pagination or filtering, but the count is reasonable for the stated purpose.

Completeness4/5

The tool surface covers the core workflow of searching and retrieving listing details. Minor gaps like pagination or sorting exist, but the essential search-to-details path is complete.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Meta Ads MCP

    JavierDaimiel
    A
    license
    Not graded
    quality
    B
    maintenance
    A Model Context Protocol server that lets AI assistants run your Meta Ads end to end — launch campaigns, upload creatives, update budgets, and dig into performance through natural conversation. Works across Facebook, Instagram, and other Meta surfaces.
    Business Source 1.1

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maxaiassistant77/facebook-marketplace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server