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

While annotations already declare readOnlyHint and openWorldHint, the description adds substantial behavioral context beyond them: 'Los ingresos no se guardan' (privacy), 'Límite del sitio: ~10 consultas por minuto; la primera puede tardar hasta un minuto' (rate limit and latency), and explains the scoring logic. This gives the agent tangible expectations about performance and data handling.

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?

Five dense sentences, front-loaded with the core purpose ('El buscador PERSONALIZADO') followed by inputs, outputs, and operational limits. Every sentence carries essential information without redundancy; the description is efficient despite 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?

With 19 parameters and no output schema, the description covers the critical return payload (score, monthly total, % income, remaining, distances, pros/warnings), operational constraints (rate limit, latency), and minimal user inputs. Geographic scope is implied via pesos, Montevideo default, and sibling tools like geocode_uy_address. The description is comprehensive given the tool's complexity.

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 74%, so the schema already documents most parameters. The description adds valuable meaning by explaining how key parameters interact: 'Combina presupuesto (alquiler + gastos comunes vs. ingreso y otros gastos) y distancias a los destinos según la prioridad' and enumerates person-level inputs (income, home office days, up to 4 destinations). It does not detail every parameter, but the schema covers those, so the description supplements rather than duplicates.

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 explicitly states the tool's function with a specific verb and resource: 'puntúa todas las viviendas vigentes (apartamentos y casas) para un hogar concreto.' It differentiates itself from sibling tools like search_rentals by emphasizing 'PERSONALIZADO' and household-specific scoring, leaving no ambiguity about its role.

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 offers practical guidance on what to ask the user ('Pedile a la persona lo mínimo: presupuesto, dónde trabaja/estudia cada uno, dormitorios, mascotas') but does not explicitly contrast with alternatives (e.g., search_rentals or compare_neighborhoods) or state when not to use this tool. The usage context is implied through 'personalizado' but not clearly delineated.

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