Skip to main content
Glama
mcp-supermercados-cl

mcp-supermercados-cl

by NLACE-COM

Buscar productos

search_products

Search products in Chilean supermarket catalogs to compare current and unit prices, stock, and promotions, with filters for store, branch, price range, and sorting.

Instructions

Busca productos en el catálogo de un supermercado chileno y devuelve resultados enriquecidos: name, brand, description, imageUrl, url. Precios en CLP: price es el precio vigente (con oferta si la hay), listPrice el normal cuando hay descuento, unitPrice/unit el precio por unidad base (kg/lt/un) para comparar formatos. Filtros opcionales: maxPrice/minPrice (CLP), inStockOnly; orden con sortBy (price = más barato primero, unitPrice = mejor precio por kg/lt). Con branchId (sucursal) los precios/stock son de esa tienda. Para el precio socio de un producto puntual, usar get_product.

Input Schema

NameRequiredDescriptionDefault
pageNoPágina de resultados.
limitNoMáximo de resultados (1-50).
queryYesTexto de búsqueda, ej. "leche descremada" o "arroz grado 1".
storeNoCadena donde buscar: jumbo, santaisabel, unimarc, tottus o lider. tottus/lider bloquean el fetch directo por huella del cliente: si bloquean, la respuesta trae openUrl/browserSnippet/retryWith para leerlas desde un navegador real.jumbo
sortByNoOrden: relevance (default), price (más barato primero) o unitPrice (mejor precio por kg/lt).relevance
branchIdNoCódigo de sucursal para precios/stock locales, ej. "jumboclj512". Omitir para catálogo nacional.
maxPriceNoFiltra productos con precio vigente <= a este valor (CLP).
minPriceNoFiltra productos con precio vigente >= a este valor (CLP).
browserHtmlNoLíder y Tottus: HTML de la página de búsqueda (o el JSON de __NEXT_DATA__) obtenido en un navegador real que ya pasó el antibot. Si se entrega, se parsea eso en vez de hacer el fetch (que la cadena bloquea por fingerprint del cliente). Flujo: llamar sin browserHtml → se devuelve openUrl+browserSnippet → ejecutarlo en el navegador → reintentar con browserHtml.
inStockOnlyNotrue = solo productos con stock real.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.9
    • changedInput schema / properties / store / description
      Previous value: -"Cadena donde buscar: jumbo, santaisabel, unimarc, tottus o lider. unimarc/tottus/lider requieren IP residencial (la máquina del usuario)."New value: +"Cadena donde buscar: jumbo, santaisabel, unimarc, tottus o lider. tottus/lider bloquean el fetch directo por huella del cliente: si bloquean, la respuesta trae openUrl/browserSnippet/retryWith para leerlas desde un navegador real."
  2. Changed1 schema field changedv1.4.3
    • addedInput schema / properties / browserHtml
      Added value: +{
      +  "description": "Líder y Tottus: HTML de la página de búsqueda (o el JSON de __NEXT_DATA__) obtenido en un navegador real que ya pasó el antibot. Si se entrega, se parsea eso en vez de hacer el fetch (que la cadena bloquea por fingerprint del cliente). Flujo: llamar sin browserHtml → se devuelve openUrl+browserSnippet → ejecutarlo en el navegador → reintentar con browserHtml.",
      +  "type": "string"
      +}
  3. First observedv1.0.0

TDQS

A4.1/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 it delivers: it explains currency (CLP), the price/listPrice/unitPrice/unit distinction, and the concrete antibot failure mode for tottus/lider including the openUrl/browserSnippet/retryWith recovery path. Gaps remain around authentication needs, pagination behavior, and error shapes beyond the block case.

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

Conciseness4/5

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

Front-loaded with purpose and return shape, then filters and ordering, then the sibling pointer. It is dense and information-bearing, though the price-field enumeration slightly duplicates both the schema and the return discussion.

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?

For a 10-parameter search tool with no output schema, the description compensates well by enumerating the returned fields and their price semantics, plus the blocked-store recovery flow. It is nearly complete; only auth/permission expectations and pagination guidance are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines every parameter, including the browserHtml retry flow and the store enum with its blocking caveat. The description largely restates sortBy, maxPrice/minPrice, inStockOnly, and branchId rather than adding syntax or constraints the schema lacks, so the baseline 3 applies.

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?

States a specific verb+resource ('Busca productos en el catálogo de un supermercado chileno') and immediately characterizes the return payload (name, brand, description, imageUrl, url). It also routes the agent away from itself for the single-product member-price case by naming get_product, which differentiates it from at least one sibling.

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: branchId switches to store-local prices/stock, and 'Para el precio socio de un producto puntual, usar get_product' names an explicit alternative with its selecting condition. It does not, however, address when to pick this over compare_stores, get_offers, or build_cheapest_basket, so it falls 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.