mueblito

buscar_catalogo

Read-only

Busca por NOMBRE entre los presets de muebles paramétricos armables de Mueblito (los mismos que devuelve listar_presets), usando búsqueda con stemming en español. Es un filtro de listar_presets por texto: NO es un catálogo de muebles terminados para comprar — todo lo que devuelve es un mueble fabricable a medida (melamina/MDF). Usala cuando el usuario describe lo que busca ('cama', 'silla comedor', 'lámpara') y querés encontrar el/los preset(s) que corresponden para después cotizar_mueble, despiece o crear_diseno. No tiene prerrequisitos; acepta texto libre. Devuelve id, nombre, categoría y medidas en mm de cada preset que coincide (el id sirve para las demás tools). Para el precio de fabricación en pesos usá cotizar_mueble con el id que devuelve esta tool. (search parametric furniture presets by name, find buildable furniture Argentina, cut list)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`consulta`	Yes	Texto libre en español para buscar en el catálogo. Ejemplos: 'cama', 'silla comedor', 'banqueta de barra'. Soporta variantes morfológicas (plural/singular, acentos). Máximo 200 caracteres.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`total`	Yes
`resultados`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark it read-only, and the description adds meaningful behavioral context: Spanish stemming, filtering semantics over listar_presets, buildable parametric furniture only, no prerequisites, and the returned id's role in downstream tools. This goes well beyond the structured annotations.

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?

The description is longer than strictly necessary and ends with a duplicated English parenthetical, but it is well front-loaded with the core action and differentiation. Most sentences earn their place by adding usage, return, or integration context.

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?

For a single-parameter read-only search tool with an output schema, the description covers everything an agent needs: what is searched, what is returned, how results connect to other tools, and what the tool is not. Nothing critical 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 the baseline is 3, but the description adds useful behavior around the parameter: it accepts free Spanish text, supports morphological variants, and gives concrete examples like 'cama' and 'silla comedor'. It does not introduce any ambiguity or contradictory parameter guidance.

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 states a specific verb and resource: it searches by NOMBRE among parametric furniture presets returned by listar_presets. It also distinguishes itself from a finished-goods catalog and from listar_presets, making sibling differentiation clear.

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?

It explicitly says when to use it: when the user describes what they are looking for and you need matching presets to continue to cotizar_mueble, despiece, or crear_diseno. It also states exclusions: it is not a catalog of finished furniture for purchase, and it has no prerequisites.

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

All mueblito tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct deliverable: search, list, quote, cut list, preview, validate, refine, and compose a 3D design. Even though several share the same preset/params inputs, their purposes and outputs do not overlap in a confusing way.

Naming Consistency4/5

Most tools follow a consistent Spanish verb_noun pattern: ajustar_mueble, buscar_catalogo, cotizar_mueble, crear_diseno, listar_presets, validar_factibilidad, ver_mueble. Despiece breaks the pattern as a noun-only name, which is a minor deviation.

Tool Count5/5

Eight tools is well-scoped for a parametric furniture server. Each tool covers a distinct part of the workflow—discovery, quotation, cut lists, preview, feasibility, iteration, and 3D scene creation—without unnecessary redundancy.

Completeness5/5

The tool set covers the full parametric furniture lifecycle: find/list presets, preview, validate, quote, generate cut lists, refine designs, and create shareable 3D layouts. There are no obvious dead ends or missing operations for the stated purpose.

Resources

Need Help?