Skip to main content
Glama
Mostrador MCP

Mostrador MCP

by schbs

Buscar producto

buscar_producto
Read-onlyIdempotent

Search hardware store products by name, brand, or category, ignoring accents. Returns paginated results with SKU, list price, and stock, plus next_offset when more items exist.

Instructions

Busca productos de la ferretería por palabras (nombre, marca o categoría), sin importar acentos. Devuelve una página de resultados (máximo 50) con SKU, precio de lista y stock. Si hay más, indica next_offset. Ejemplos: "taladro 18 V" -> q="taladro 18 v"; "tornillos para madera" -> q="tornillo madera". Usá consultar_stock o precio cuando ya tengas el SKU.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "q": "<q>"
    },
    "name": "buscar_producto"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesPalabras a buscar, por ejemplo 'látex 4 litros'
limitNoCuántos resultados (1 a 50)
offsetNoCuántos saltear, para paginar
categoriaNoFiltra por categoría exacta (ver el resource catalogo://categorias)
response_formatNo'markdown' para leer, 'json' para datosmarkdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and closed-world behavior, so the bar is lower; the description still adds real context by disclosing the 50-result cap, the result fields (SKU, precio de lista, stock) and the next_offset continuation signal. It does not cover permissions or what happens with zero matches, which keeps it just short of a 5.

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?

Four short sentences in a deliberate order: what it searches, what comes back, how to phrase the query, and which sibling to use instead. No filler, and the core capability 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?

With no output schema, the description covers the return shape (fields, page size, pagination token) itself, and the sibling routing closes the main selection ambiguity. Nothing an agent needs to call this correctly is missing.

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 still adds meaning by showing that plurals and stopwords are normalized ("tornillos para madera" -> "tornillo madera") and by tying next_offset to the offset parameter. It says nothing extra about categoria or response_format beyond the schema.

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 and resource ("Busca productos de la ferretería") plus the matching fields (nombre, marca, categoría) and a distinguishing trait (accent-insensitive). An agent can immediately tell this is a search tool rather than a lookup-by-SKU one.

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?

Ends with an explicit routing rule: use consultar_stock or precio once you have the SKU, which names both siblings and the condition that selects them. The two query examples also show how to simplify colloquial queries, which is actionable guidance, not just illustration.

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