mueblito

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

Even with readOnlyHint=true, the description adds substantial behavioral context beyond the annotations: it clarifies the operation is a field-level merge ('diff a aplicar'), that it re-validates and fails with a reason if invalid, and that it returns multiple artifacts (new params, SVG, quote summary, despiece, feasibility). The readOnly annotation is not contradicted because the operation transforms and returns data without describing any external persistence.

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 dense and front-loaded with the core behavior, and includes useful examples and chaining instructions. It earns its length for a tool with two complex parameters and multiple return artifacts, though the trailing English parenthetical '(iterate furniture design, edit parameters, refine, text-to-CAD loop)' is redundant with the Spanish text and adds noise.

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 schema richness and presence of an output schema, the description covers what matters: how to invoke it, what inputs are expected, what results are returned, failure behavior on invalid changes, and how to chain calls. The nested-object complexity is handled by the schema, while the description supplies the call pattern and iteration loop an agent needs.

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%, but the description adds crucial semantic meaning: baseParams must already be valid and can come from a prior quote, while cambios is a merge-by-field diff containing only the fields to change. The concrete example '{width: 2400, shelves: 5, material: 'mdf-18mm-blanco'}' clarifies how to express a partial update, which the raw schema alone does not convey.

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 is explicit: 'Itera sobre un diseño' with a specific verb and resource, and details exactly what it does: apply a DIFF, re-validate, and return new params, SVG, quote summary, parts breakdown, and feasibility review. It distinguishes itself from a full rebuild by calling itself the 'loop de refinamiento' and saying 'sin rearmar todo', which separates it from siblings like cotizar_mueble or crear_diseno.

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 gives clear when-to-use guidance: it is the refinement loop for proposing small changes ('más ancho', 'un estante más') and seeing the effect immediately. It also states the prerequisite contract explicitly — pass baseParams as valid current params (e.g. from cotización) and cambios as only the fields to modify — and instructs chaining the output params into the next call.

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

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.

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.

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.

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.

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.

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.

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

Beyond the readOnlyHint=true annotation, the description discloses useful behavioral context: prices are indicative ARS values from MercadoLibre, exclude labor and installation, and can vary over time. This helps the agent set expectations about estimate accuracy and 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?

The description is front-loaded with purpose, then organized into usage, prerequisite, adjustment note, and limitation. The final English parenthetical is redundant, but the overall length is justified by the tool's complexity.

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 complex tool with nested schemas and an output schema, the description covers purpose, when to use it, prerequisite setup, preset adjustments, and pricing limitations. It does not explain the full custom 'params' path, but the schema already documents that exhaustively.

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?

The description adds practical parameter knowledge beyond the 100% schema coverage: example preset ids, the ability to adjust presets via 'ajustes', and the fact that partial overrides are allowed. It does not re-document the schema, but reinforces the preset-based workflow.

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 action ('Calcula el presupuesto de materiales...') and resource ('mueble a medida') with clear scope (ARS, materials, cut service). It also ties the tool to the user's intent ('saber cuánto sale hacer un mueble'), which distinguishes it from siblings like ver_mueble, crear_diseno, or despiece.

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?

Provides an explicit when-to-use signal ('Usala cuando el usuario quiere saber cuánto sale hacer un mueble en Argentina') and a concrete prerequisite: call listar_presets first if the preset id is unknown. It does not enumerate when-not-to-use or name alternatives, but the context is clear and actionable.

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

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

Beyond the readOnlyHint=true annotation, the description discloses the key behavioral traits: the link is static and not saved on the server, no account is required, furniture auto-distributes in a row when position is omitted, and the link opens an editor with view/move/adjust/budget capabilities. The explicit 'no se guarda en servidor' statement is consistent with readOnlyHint=true rather than contradicting it — the tool generates a link with no persistent side effects.

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?

Purpose is front-loaded in the first clause, and every subsequent sentence carries distinct information (use case, prerequisite, parameter model, static-link limitation, no-account requirement). It is a somewhat dense single paragraph with a keyword tail, so it is not maximally scannable, but there is no redundancy.

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 tool with deeply nested furniture params (15+ kinds, nested column/zone objects) and an output schema present, the description covers everything needed to call it correctly: return artifact format, usage trigger, prerequisite call, parameter alternatives, optionality semantics, and the static-link/no-account limitation. The existing output schema relieves it of needing to document return values.

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 baseline is 3, but the description adds orchestration semantics the schema cannot convey: the preset-or-params mutual exclusion per furniture, that posición and rotación are optional with an automatic row-layout fallback, and the dependency on listar_presets for preset IDs. That pushes it clearly above baseline.

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 names a specific verb+resource ('Crea una escena 3D con uno o varios muebles'), the precise output artifact (an editable /d/<code> link that opens the Mueblito editor), and the multi-furniture scope. This inherently distinguishes it from siblings like ver_mueble (single piece) and cotizar_mueble (budget), even though only listar_presets is named explicitly.

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?

It gives an explicit trigger ('Usala cuando el usuario quiere visualizar cómo quedarían los muebles en un espacio o compartir un diseño con un carpintero o cliente') and a prerequisite that routes the agent to listar_presets when preset IDs are unknown. It stops short of a 5 because it never states when NOT to use it, and it mentions the editor can generate a presupuesto without clarifying that cotizar_mueble may be the right tool for budget-only requests.

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

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

Annotations already mark the tool as readOnly, and the description adds substantive context: it discloses the output format (ASCII table), that measurements are net cut sizes in mm, and the kerf limitation of 3-4 mm when computing board consumption. This is valuable behavioral information beyond the readOnlyHint.

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 longer than average but each sentence carries distinct value: output, use case, argument structure, and a technical limitation. The trailing English keywords are redundant but do not undermine clarity; a shorter version could merge the argument sentence.

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 complex nested schema and the output schema, the description covers the essential operational context: what the tool returns, in what units, with which limitation, and how to obtain a preset id. It doesn't enumerate furniture kinds, but that is already encoded in the params oneOf schema.

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% and the schema already explains preset, params, and ajustes, including how they relate. The description adds cross-tool context ('Acepta los mismos args que cotizar_mueble') and repeats the listar_presets guidance, but does not add meaning beyond what the schema provides.

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 opens with a specific verb and resource: 'Genera la lista completa de piezas de corte y herrajes para fabricar un mueble', and enumerates output fields (largo, ancho, espesor en mm, material, tapacanto frontal, tabla ASCII). It also distinguishes itself from cotizar_mueble by noting it accepts the same args but produces a cut list, so an agent can tell them apart.

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?

It gives an explicit when-to-use condition: 'Usala cuando el usuario necesita la planilla de cortes... o quiere verificar qué componentes tiene el mueble', and points to listar_presets as a prerequisite when the preset id is unknown. It does not explicitly state when not to use it (e.g., for pricing), so it falls short of a 5.

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

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

Las anotaciones ya declaran readOnlyHint=true, por lo que el riesgo de mutación está cubierto. La descripción agrega contexto valioso: que los presets son muebles fabricables (melamina/MDF) y no del catálogo, y que no tiene parámetros ni prerrequisitos. Esto va más allá de las anotaciones al especificar la naturaleza del recurso y el flujo de trabajo esperado.

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?

Tres oraciones que van al grano: la primera define el propósito y campos, la segunda da la guía de uso con la referencia a otras tools, y la tercera aclara la distinción con buscar_catalogo. No hay relleno. Cada frase aporta información esencial y está bien organizada.

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?

Existe un output schema, así que no es necesario describir la estructura de retorno. La descripción cubre el propósito, la guía de uso, la naturaleza de los datos y la ausencia de requisitos. Es suficiente para que un agente sepa exactamente cuándo y cómo invocarla.

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 hay parámetros, y la descripción confirma 'No tiene parámetros ni prerrequisitos'. El esquema vacío ya lo indica, pero la descripción refuerza que no hay entradas que preparar, lo cual es suficiente dado que no hay parámetros que documentar. El baseline de 4 es apropiado.

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?

El verbo 'lista' y el recurso 'presets de muebles paramétricos' son explícitos y específicos. Diferencia claramente de 'buscar_catalogo' al aclarar que los presets son muebles fabricables, no terminados del catálogo. Incluye los campos que retorna (id, nombre, tipo, medidas, descripción) lo que permite al agente entender exactamente el alcance.

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?

Indica 'Llamá esta tool primero si no sabés el id del preset que necesitás' y menciona que el id se pasa a cotizar_mueble, despiece y crear_diseno, estableciendo un patrón de uso. También excluye explícitamente el caso de muebles del catálogo con 'para eso usá buscar_catalogo'. Esto es guía directa sobre cuándo y cuándo no usarla.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful behavioral context by explaining what the tool evaluates, that it returns 'factible' plus a warning list, and that it acts as a structural compile-check. No contradiction with annotations.

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 information-dense and well-structured, with the main behavior first, then outputs, then usage context. The 'compile-check' analogy adds clarity. It is slightly long with parenthetical repetitions, but every sentence contributes meaningful guidance.

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 complex multi-variant schema and the presence of an output schema, the description provides enough context for an agent to select and invoke the tool: what it checks, what it returns, and when to call it. It does not enumerate non-goals or exclusions, but the schema and annotations cover the remaining invocation details.

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 JSON Schema already documents that the single param contains the full furniture parameters. The description does not explain individual parameters, but that responsibility is adequately handled by the schema. Baseline 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?

The description clearly states the tool's purpose: reviewing whether a furniture piece can be safely assembled based on its geometry, and enumerates specific structural issues it detects (loose parts, cantilevers, rocking frames, tip-over risk, sag deflection). It does not explicitly differentiate from sibling tools by name, but the 'before quoting or manufacturing' positioning and the validation focus make its role distinct enough.

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 gives explicit usage context: use it before quoting or manufacturing to catch structural problems. It implies the tool is a pre-production validation step rather than a quoting or design tool, though it does not state when not to use it or name alternative tools.

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

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

Annotations already mark readOnlyHint=true, and the description reinforces this by presenting the tool as a non-mutating 'VISTA'. It adds valuable behavioral context beyond the annotation: output is an SVG, views are same-scale, and the view is derived from the real despiece ('lo que ves es lo que se corta'), which sets fidelity expectations.

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 main content is front-loaded with the view type, format, and purpose, followed by usage guidance. The trailing parenthetical English keywords (e.g., 'preview furniture, orthographic views') partially duplicate the Spanish text and add minor clutter, so it is not perfectly concise.

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 complex tool with a large nested schema and an output schema present, the description covers purpose, exact output format, fidelity to the cut plan, parameter relationship to cotizar_mueble, and clear usage scenarios. Nothing essential for correct invocation or selection is missing.

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% and the schema already documents params, preset, and ajustes with Spanish descriptions. The description adds the useful semantic anchor that the tool accepts the same args as cotizar_mueble, plus optional measurement adjustments, which helps an agent reuse knowledge from the sibling tool.

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 and resource: 'Devuelve una VISTA del mueble (frente + lateral + planta, a la misma escala) como imagen SVG'. Clearly separates preview from quoting by saying it is for seeing the design before cotizar, and names the related sibling cotizar_mueble.

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?

Explicit when-to-use is given: use it when you have a furniture piece in mind to confirm shape/proportions, or after ajustar_mueble to review a change. It also positions the tool as complementary to cotizar_mueble by accepting the same arguments, making the alternative relationship clear.

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