This server lets you search, monitor, and retrieve Facebook Marketplace listings programmatically via Claude, using your existing Chrome Facebook session (macOS only). It is read-only — no posting, messaging, or account modification.
Search Listings — Search by keyword and location (latitude/longitude/radius), with optional filters:
Price range (min_price, max_price)
Item condition (new, used_like_new, used_good, used_fair)
Days since listed
Sort order (best_match, price_asc, price_desc, date_desc)
Category and pagination
Get Listing Details — Retrieve details for a specific listing by its ID (full descriptions may be limited by the API).
Location Lookup — Convert a city or place name to latitude/longitude coordinates for use in searches.
Monitor Searches — Save a named search query with filters to track new listings over time.
Check Monitors — Check one or all saved monitors for new listings since the last check.
List Monitors — View all currently saved search monitors.
Delete Monitors — Remove a saved search monitor by name.
Additional notes: Automatic session refresh on expiry; configurable rate limit via environment variable; requires Chrome with an active Facebook login on macOS.
Allows searching and reading Facebook Marketplace listings using your existing Facebook session.
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 search for a used bicycle in Austin under $200"
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.
Busca en Facebook Marketplace directamente desde Claude (Claude Code o Claude Desktop). Sin navegador: reutiliza tu sesión de Facebook ya iniciada en Chrome.
Este proyecto es de código abierto y queremos ser 100% transparentes sobre lo que hace:
🍪 Lee las cookies de tu sesión de Facebook desde Chrome. Para hacerse pasar por ti ante Facebook, el servidor copia la base de datos de cookies de Chrome y la descifra usando la clave guardada en el Llavero (Keychain) de macOS. La primera vez, macOS te pedirá tu contraseña para autorizar ese acceso. Las cookies se usan solo en tu equipo, para hablar con facebook.com; no se envían a ningún tercero.
📜 Automatizar Facebook viola sus Términos de Servicio. Facebook puede pedir CAPTCHAs, limitar o bloquear la cuenta que uses.
🧑🔧 Recomendación fuerte: usa una cuenta secundaria de Facebook, NO tu cuenta principal. Crea una cuenta aparte (idealmente en un perfil de Chrome distinto) e inicia sesión ahí solo para esto. Así, si Facebook marca o bloquea la cuenta, no pierdes tu cuenta personal. Configura ese perfil con la variable CHROME_PROFILE (ver más abajo).
🐢 Uso responsable. El servidor se auto-limita a pocas solicitudes por minuto para no llamar la atención. No subas ese límite de forma agresiva.
🔍 Solo lectura. Busca y lee publicaciones; no publica, no envía mensajes, no modifica nada en tu cuenta.
Al usar este software aceptas estos riesgos bajo tu propia responsabilidad.
Related MCP server: Marketplace Finder MCP Server
Toma tu sesión: copia las cookies de Facebook desde Chrome y las descifra con la clave del Llavero de macOS.
Consigue los tokens: abre facebook.com/marketplace/ (como una página normal) y extrae los tokens de seguridad (fb_dtsg, lsd, etc.) que Facebook exige.
Habla el protocolo de Facebook: hace las mismas llamadas POST /api/graphql/ que hace el sitio web de Facebook, usando identificadores de consulta (doc_id) y tu sesión.
Te devuelve resultados limpios: título, precio, ubicación, vendedor, fecha, foto y enlace de cada publicación.
Es la misma idea que pypush para iMessage: protocolo directo, sin navegador en tiempo de ejecución.
macOS (la extracción de cookies usa el Llavero de Apple).
Google Chrome con una sesión de Facebook iniciada (idealmente una cuenta secundaria).
Para el método manual: Node.js 20 o superior (node --version). Instálalo desde nodejs.org o con brew install node. (La extensión .mcpb de Claude Desktop no necesita que instales Node.)
⬇ Descarga la extensión .mcpb (botón de arriba).
Doble clic en el archivo descargado (o arrástralo a Claude Desktop → menú ☰ → Settings → Extensions).
Revisa los detalles y pulsa Install. Ajusta si quieres el perfil de Chrome y el límite de solicitudes.
¡Listo! Pídele a Claude que busque algo en Marketplace.
La extensión precompilada es para macOS con chip Apple Silicon (M1/M2/M3…). Si tienes un Mac Intel, usa el método manual (
npm run buildrecompila el binario para tu equipo).
git clone https://github.com/fjvalencian/marketplace-mcp.git && cd marketplace-mcp && npm install && npm run build
claude mcp add facebook-marketplace --scope user -- node "$(pwd)/dist/index.js"Detalle paso a paso más abajo. 👇
Sigue esto tal cual, línea por línea. No necesitas saber programar.
En Spotlight (⌘ + Espacio) escribe "Terminal" y ábrela.
Copia y pega estos comandos, uno a uno, y presiona Enter después de cada uno:
git clone https://github.com/fjvalencian/marketplace-mcp.git
cd marketplace-mcp
npm install
npm run buildSi todo salió bien, se creó una carpeta dist/ con el servidor compilado.
Ejecuta pwd y copia lo que aparece (por ejemplo /Users/tunombre/marketplace-mcp). La ruta al servidor será eso + /dist/index.js.
Abre Google Chrome e inicia sesión en la cuenta de Facebook que vas a usar. Déjala con sesión abierta.
Sigue Instalar en Claude Code o Instalar en Claude Desktop. Reinicia la app después.
Escríbele a Claude: "Busca un BMW E30 en Santiago de Chile, entre 2 y 8 millones, ordenado por precio."
La primera vez, macOS mostrará una ventana pidiendo tu contraseña para acceder al Llavero ("Chrome Safe Storage"). Escríbela y dale Permitir siempre. ¡Listo!
Ejecuta esto reemplazando la ruta por la tuya (paso 3):
claude mcp add facebook-marketplace --scope user -- node /RUTA/COMPLETA/marketplace-mcp/dist/index.jsVerifica que quedó conectado:
claude mcp listDebe aparecer facebook-marketplace ... ✔ Connected. Reinicia Claude Code para que las herramientas estén disponibles.
.mcpb (recomendada, un clic)Ver Instalación rápida arriba.
Abre (o crea) el archivo de configuración de Claude Desktop en macOS:
open -e ~/Library/Application\ Support/Claude/claude_desktop_config.jsonAgrega el bloque "facebook-marketplace" (reemplaza la ruta por la tuya del paso 3):
{
"mcpServers": {
"facebook-marketplace": {
"command": "node",
"args": ["/RUTA/COMPLETA/marketplace-mcp/dist/index.js"],
"env": { "CHROME_PROFILE": "Default" }
}
}
}Guarda y cierra y vuelve a abrir Claude Desktop por completo.
¿Quieres un "botón" que abra Claude Desktop y lance una búsqueda al instante? Usa los enlaces claude://. Al hacer clic, se abre Claude Desktop con el mensaje ya escrito (necesitas la extensión instalada).
📌 Reemplaza el prompt por lo que busques. Ejemplos listos (haz clic):
Para crear tu propio botón, arma un enlace así (codifica el texto para URL):
claude://claude.ai/new?q=TU_BUSQUEDA_AQUINo existe un enlace que cree la rutina automáticamente, pero configurarla toma 30 segundos:
En Claude Desktop abre la barra lateral → Routines → New routine.
Pega un prompt como: "Revisa facebook-marketplace por BMW E30 nuevos en Santiago bajo 8 millones y resúmelos."
Elige la frecuencia (diaria, semanal…) y guarda.
💡 Alternativa dentro del propio MCP: usa
monitor_searchpara guardar una búsqueda ycheck_monitorspara ver solo lo nuevo desde la última vez. Perfecto para combinar con una rutina.
search_listingsBusca publicaciones por texto, ubicación y filtros.
Parámetro | Tipo | Requerido | Descripción |
| string | sí | Texto a buscar (ej: |
| number | sí | Latitud del centro de búsqueda |
| number | sí | Longitud del centro de búsqueda |
| number | no | Radio en km (por defecto: 50) |
| number | no | Precio mínimo, en pesos/dólares (la unidad de la moneda) |
| number | no | Precio máximo, en pesos/dólares |
| string[] | no | Estado: |
| number | no | Solo publicaciones de los últimos N días |
| string | no |
|
| string | no | ID de categoría |
| string | no | Cursor para traer la página siguiente (paginación) |
| number | no | Máximo de resultados (por defecto: 20) |
💰 Sobre los precios: escribe
min_price/max_priceen la unidad normal de la moneda (ej.2000000para 2 millones de pesos). El servidor hace la conversión que Facebook espera internamente. Muchos vendedores ponen precios falsos ($0, $123, $12.345.678); esos aparecen marcados con ⚠️ precio dudoso.
get_listingDevuelve datos de una publicación por su listing_id. Nota: Facebook no expone la descripción completa de un aviso vía API sin navegador, así que esta herramienta puede devolver solo el enlace directo para abrirlo. La búsqueda ya entrega título, precio, ubicación, vendedor y foto.
search_locationConvierte el nombre de una ciudad/comuna en coordenadas para usar en search_listings. Parámetro: query (ej: "Santiago, Chile", "Providencia").
monitor_search — guarda una búsqueda como monitor.
check_monitors — revisa si hay publicaciones nuevas desde la última vez.
list_monitors — lista los monitores guardados.
delete_monitor — elimina un monitor.
"Busca un BMW E30 en Santiago de Chile, entre 2 y 8 millones, ordenado por precio."
"Muéstrame Golf GTI en Providencia publicados en los últimos 7 días."
"Crea un monitor llamado 'e30' para BMW E30 en Santiago y avísame de lo nuevo."
"Dame el detalle de la publicación con id 1726115965212924."
Variable | Por defecto | Descripción |
|
| Nombre de la carpeta del perfil de Chrome del que se leen las cookies |
|
| Máximo de solicitudes por minuto (sube con cuidado; más = más riesgo) |
Si tu cuenta secundaria está en otro perfil de Chrome, indica su carpeta en CHROME_PROFILE. Los perfiles se guardan en ~/Library/Application Support/Google/Chrome/. El primero es Default; los siguientes son Profile 1, Profile 2, etc.
.mcpbSi modificas el código o usas un Mac Intel, regenera el bundle:
npm install
npm run build
npm prune --omit=dev # deja solo dependencias de producción (bundle liviano)
npx @anthropic-ai/mcpb pack # genera facebook-marketplace-mcp.mcpb
npm install # restaura dependencias para futuros buildsLuego instala el .mcpb en Claude Desktop con doble clic.
doc_idFacebook rota sus identificadores de consulta (doc_id) en cada despliegue. Si las búsquedas dejan de funcionar de golpe, recaptúralos:
npm install -D playwright
npx playwright install chromium
npm run capture-queriesEsto abre un navegador, navega por Marketplace y captura los IDs actuales. Actualiza los valores en src/facebook/queries.ts y vuelve a compilar con npm run build.
Solo macOS (por el descifrado con el Llavero).
Requiere Chrome con sesión de Facebook activa.
Frágil: los doc_id cambian cuando Facebook actualiza su sitio.
Con límite de tasa: un uso agresivo puede gatillar CAPTCHAs o bloqueos.
Solo lectura: no mensajea ni publica.
Funcionalidades del servidor, todas verificadas con búsquedas reales:
🔄 Reintento de sesión automático. Si la sesión expira (401/403 o token rotado), el servidor reinicializa y reintenta la búsqueda de forma transparente.
💰 Filtro de precio configurable. El factor de conversión de precios es explícito y está verificado para pesos chilenos (price_scale, por defecto 100).
📄 Paginación. search_listings acepta un cursor y devuelve el cursor de la página siguiente.
🔎 Filtros y orden. condition, days_since_listed y sort_by (por precio o fecha).
🧾 Resultados ricos. Incluye fecha de publicación, foto, id para usar en get_listing, y marca los precios claramente falsos con ⚠️.
🚦 Rate limit configurable por FB_MAX_RPM.
🛡️ Manejo de errores claro. Distingue "sesión expirada" de otros errores en lugar de fallar en silencio.
Uso educativo y personal. Respeta los Términos de Servicio de Facebook y las leyes aplicables. Los autores y contribuyentes no se hacen responsables del uso indebido ni de bloqueos de cuenta.
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. 'bmw e30', 'macbook pro') | |
| cursor | No | Pagination cursor from a previous search's 'next cursor' to fetch the following page | |
| sort_by | No | Order the returned results: best_match (default), price_asc, price_desc, date_desc (newest first) | |
| category | No | Category ID to filter by | |
| latitude | Yes | Latitude of search center | |
| condition | No | Filter by item condition (server-side) | |
| longitude | Yes | Longitude of search center | |
| max_price | No | Maximum price filter, in the listing's currency units (e.g. CLP pesos, USD dollars) | |
| min_price | No | Minimum price filter, in the listing's currency units (e.g. CLP pesos, USD dollars) | |
| radius_km | No | Search radius in kilometers (default: 50) | |
| price_scale | No | Advanced: multiplier applied to min_price/max_price before sending to Facebook. Facebook uses a 2-decimal minor unit for ALL currencies (including CLP/JPY), so the default 100 is almost always correct. Only override if price filtering behaves oddly in a specific market. Default: 100 | |
| days_since_listed | No | Only show items listed within the last N days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits, but it only mentions search parameters. It omits important behaviors like pagination (though cursor is in schema), rate limits, authentication, or what the response contains. The description adds minimal behavioral context beyond the schema.
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, which is concise but lacks structure. It does not front-load critical information like result format or use cases, and the brevity sacrifices completeness for terseness.
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?
Given the complexity (13 parameters, no output schema, no annotations), the description is inadequate. It fails to explain return values, error handling, or how filters interact, leaving significant gaps for an agent to use the tool correctly.
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 all 13 parameters documented, so the description need not add much parameter detail. It does not provide any additional semantic meaning beyond what the schema already offers, resulting in a baseline score of 3.
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 action ('Search Facebook Marketplace listings') and the inputs ('by query, location, and filters'), making the tool's purpose immediately identifiable and distinguishing it from siblings like 'get_listing' or 'monitor_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?
No guidance is provided on when to use this tool versus alternatives such as 'get_listing' for single listings or 'monitor_search' for monitoring. The description lacks any context about prerequisites, when not to use, or which sibling tools to consider instead.
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 serves a distinct purpose: monitors (create, list, check, delete), listings (search, get details), and a location helper. No overlap in functionality.
All tool names use snake_case and generally follow a verb_noun pattern (e.g., check_monitors, delete_monitor). 'monitor_search' is a slight deviation as it could be interpreted as noun_verb, but overall consistent.
7 tools cover the essential operations for a Facebook Marketplace tracking service without unnecessary clutter or obvious missing pieces.
The tool set provides full CRUD for monitors and listing retrieval, but lacks actions for creating or modifying listings, which may be intentional given API constraints. Minor gap in not supporting category browsing.
Search and browse global classifieds across 80 markets. No auth required for read-only access.
Amazon brand, seller, niche & buy-box intelligence inside your own Claude or ChatGPT.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Search Rakuten Ichiba products and compare prices via Claude. Zero setup, no API key needed.
