Provides tools for accessing Facebook Marketplace, enabling AI agents to search listings by query, location, and filters (price range, category, radius), retrieve full details for specific listings, and save/manage/check monitors that track new listings matching a search over time. Read-only access with no messaging or listing creation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Facebook Marketplace MCP Server search Marketplace for a used Herman Miller Aeron chair under $400"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that provides access to Facebook Marketplace via direct GraphQL API calls. No browser automation at runtime — speaks Facebook's internal protocol directly.
Facebook's web client makes all Marketplace requests as POST /api/graphql/ with a doc_id (query hash) and variables. This server replays those requests using your existing Facebook session cookies from Chrome.
Think of it like pypush for iMessage — direct protocol, no browser.
Related MCP server: Marketplace Finder MCP Server
macOS (cookie extraction uses Keychain)
Google Chrome with an active Facebook login
Node.js 20+
git clone <this-repo>
cd facebook-marketplace-mcp
npm install
npm run buildclaude mcp add facebook-marketplace -- node /path/to/facebook-marketplace-mcp/dist/index.jsOr add to your Claude Code config manually:
{
"mcpServers": {
"facebook-marketplace": {
"command": "node",
"args": ["/path/to/facebook-marketplace-mcp/dist/index.js"],
"env": {
"CHROME_PROFILE": "Default"
}
}
}
}search_listingsSearch Marketplace by query, location, and filters.
Parameter | Type | Required | Description |
| string | yes | Search term |
| number | yes | Latitude of search center |
| number | yes | Longitude of search center |
| number | no | Search radius (default: 50) |
| number | no | Min price in dollars |
| number | no | Max price in dollars |
| string | no | Category ID |
| number | no | Max results (default: 20) |
get_listingGet full details for a specific listing.
Parameter | Type | Required | Description |
| string | yes | Marketplace listing ID |
monitor_searchSave a search as a monitor to track new listings over time.
Parameter | Type | Required | Description |
| string | yes | Monitor name |
| string | yes | Search term |
| number | yes | Search center lat |
| number | yes | Search center lng |
| number | no | Radius (default: 50) |
| number | no | Min price |
| number | no | Max price |
check_monitorsCheck monitors for new listings since last check.
Parameter | Type | Required | Description |
| string | no | Check specific monitor, or omit for all |
list_monitorsList all saved monitors.
delete_monitorDelete a saved monitor.
Env Variable | Default | Description |
|
| Chrome profile directory name |
Facebook rotates their doc_id values on deploys. If searches stop working:
npm install -D playwright
npx playwright install chromium
npm run capture-queriesThis opens a browser, navigates Marketplace, and captures current query IDs. Update src/facebook/queries.ts with the new values.
The server self-rate-limits to 3 requests/minute with random jitter to avoid detection. This means searches take a few seconds.
macOS only for automatic cookie extraction
Requires Chrome with active Facebook session
Facebook ToS — automating Facebook violates their Terms of Service
Fragile — doc_id values change on Facebook deploys
Rate limited — aggressive use may trigger CAPTCHAs or account flags
No write operations — search/read only, no messaging or listing creation
Check saved monitors for new listings since last check
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_name | No | Check a specific monitor by name, or omit to check all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-like operation but does not disclose if the tool modifies state (e.g., updating last-checked timestamp) or any side effects, which are critical for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no excess words, perfectly concise for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional param, no output schema), but the description lacks details on return value, behavior of 'since last check,' and side effects. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter 'monitor_name' described clearly. The description adds no further meaning beyond the schema, but it is not needed given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'saved monitors' for new listings since last check, distinguishing it from siblings like 'list_monitors' (simple listing) and 'search_listings' (direct search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (e.g., list_monitors, search_listings) or when not to use it. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a saved search monitor
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the monitor to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only says 'Delete' without disclosing whether deletion is permanent, reversible, or requires special permissions. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extra words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one required parameter and no output schema, the description is adequate but could benefit from stating permanence or error conditions. Lacks some completeness expected for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'name' described as 'Name of the monitor to delete'. Description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Delete' and resource 'saved search monitor', distinguishing it from sibling tools like list_monitors or check_monitors. However, it could be more specific about what exactly a monitor is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 other monitor-related tools. No context about prerequisites or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific Facebook Marketplace listing
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | Facebook Marketplace listing ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so full burden falls on description. It states 'get full details' implying a read operation, but lacks disclosure on authentication requirements, error behavior (e.g., nonexistent ID), rate limits, or whether it modifies state. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action. No wasted words. Efficiently conveys purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without output schema, the description is minimally adequate. However, it lacks explanation of what 'full details' includes in the response, and does not cover error handling or prerequisites. Could be more complete without being verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'listing_id' described as 'Facebook Marketplace listing ID'. Description adds no further meaning; baseline 3 is appropriate as schema already explains the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifically states 'Get full details for a specific Facebook Marketplace listing', clearly identifying the verb, resource, and scope. It differentiates from sibling tools like search_listings which return multiple results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. Does not mention alternatives like search_listings for finding listings by criteria or list_monitors for monitors. The description only implies it is for a specific listing ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved search monitors
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only implies a read operation but lacks details on authentication, rate limits, pagination, or what 'all' entails in terms of scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters, the tool has no output schema and no annotations, so the description should explain what is returned (e.g., list of monitor IDs, names, statuses). It fails to do so, leaving the agent without context on the output format or field meanings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is trivially 100%. The description does not need to add parameter meaning, and baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'saved search monitors', making purpose obvious. However, it does not explicitly differentiate from sibling tools like 'check_monitors' or 'monitor_search', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like check_monitors or monitor_search. The description provides no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a search query as a monitor to track new listings over time
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for this saved search monitor | |
| query | Yes | Search query | |
| category | No | Category ID | |
| latitude | Yes | Latitude of search center | |
| longitude | Yes | Longitude of search center | |
| max_price | No | Max price filter in dollars | |
| min_price | No | Min price filter in dollars | |
| radius_km | No | Search radius in km |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Save', which implies creation, but lacks details on limits, conflict behavior, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, but it is underspecified given the tool's complexity (8 parameters). It earns its place but could benefit from more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 8 parameters, the description is too minimal. It does not explain what a monitor does, how frequently it checks, or how results are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no additional meaning beyond the schema, achieving baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save a search query as a monitor to track new listings over time' clearly states the action (save a search query) and the resource (monitor). It distinguishes from sibling tools like 'search_listings' (one-time search) and 'list_monitors' (list existing monitors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool to track new listings over time versus a one-time search, but it does not explicitly state when to use vs alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Facebook Marketplace listings by query, location, and filters
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of results (default: 20) | |
| query | Yes | Search query (e.g. 'macbook pro', 'couch') | |
| category | No | Category ID to filter by | |
| latitude | Yes | Latitude of search center | |
| longitude | Yes | Longitude of search center | |
| max_price | No | Maximum price filter in dollars | |
| min_price | No | Minimum price filter in dollars | |
| radius_km | No | Search radius in kilometers (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and discloses nothing behavioral: no mention of result freshness, pagination via limit, whether results reflect live Marketplace data, or any rate/auth constraints. For a live external-scrape search tool this leaves meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource and search axes front-loaded and zero filler. It is efficiently sized, though its brevity is part of why other dimensions are weak.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-required-parameter search with full schema coverage the parameters are covered, but with no output schema the description could have described what a result contains and how to page through it. Minimum viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. The description restates the query/location/filters concept but adds no syntax, default, or format detail beyond what the schema already documents for all 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) plus the exact resource (Facebook Marketplace listings) and the three axes of search: query, location, filters. An agent can distinguish it from get_listing (single listing) purely from the name, though the description itself never names the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no alternatives referenced, despite clear siblings such as get_listing for a single item and monitor_search/monitor_search for recurring alerts. The agent must infer which sibling to pick from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a city/town name to get coordinates for use with search_listings
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Location search query (e.g. 'Dedham MA', 'Boston', 'Brooklyn NY') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes the read-only lookup behavior and implies output of coordinates. No contradictions or missing critical traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It front-loads the action and purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers the essential use case. It could mention coordinate format, but completeness is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described query parameter. The description 'for use with search_listings' adds slight context beyond the schema, but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Look up', the resource 'city/town name', and the outcome 'get coordinates for use with search_listings'. It distinguishes from sibling tools like search_listings by specifying it's a geocoding step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly ties the tool's use to preparing coordinates for search_listings, providing clear context. It doesn't list alternatives or when not to use, but the purpose is sufficiently narrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_monitorsdelete_monitorget_listinglist_monitorsmonitor_searchsearch_listingssearch_locationScored across 7 tools
Each tool maps to a distinct resource/action: search_listings finds listings, get_listing fetches one, search_location resolves coordinates, and the monitor tools form a clean lifecycle. list_monitors vs check_monitors and monitor_search vs search_listings are clearly differentiated by their descriptions.
Most names follow a clean verb_noun pattern (list_monitors, search_listings, get_listing, check_monitors, delete_monitor). The one deviation is monitor_search, which inverts the pattern (should be something like create_monitor), but the meaning is still readable.
Seven tools is well-scoped for a Marketplace search-and-monitor server, with each tool earning its place across search, retrieval, location lookup, and monitor management.
The surface covers the full monitor lifecycle (create/list/check/delete) plus listing search and retrieval, which is comprehensive. The only minor gap is no way to update/edit an existing monitor's query or filters, requiring delete-and-recreate workarounds.
Search and browse global classifieds across 80 markets. No auth required for read-only access.
Shopify and eBay product scraper & extractor for fast market research. Pulls Shopify products.
AI marketplace: search, buy, sell across Amazon, eBay, AliExpress. 13 tools.
Stealth scraping & search. Bypasses Cloudflare, DataDome & LinkedIn via Cyborg HITL approach.
