Cambio Uruguay

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

With no annotations, the description carries the full behavioral burden, and it delivers non-obvious disclosure: the meaning of 'best' flips with side — lowest sell price when buying, highest buy price when selling. This prevents an agent from incorrectly assuming 'best' always means the lowest price. It also scopes the result temporally ('right now'), though it doesn't explicitly confirm read-only behavior or describe the result shape.

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?

Two sentences with zero redundancy. The purpose is front-loaded in the first sentence, and the clarifying side semantics follow immediately in the second. Every clause earns its place, and the key disambiguation is packed into minimal space.

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 2-parameter lookup tool with fully documented schema parameters, the description covers the essential decision rule and temporal scope. The main gap is the absence of an output schema and no hint about what the result contains (house name, rate, timestamp). Given the tool's simplicity, this is close to complete but not fully so.

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 both parameters are already documented, earning the baseline 3. The description adds genuine value beyond the schema by coupling each side value to its ranking rule (buy → lowest sell price; sell → highest buy price), which is the tool's core logic. Currency adds nothing beyond the schema's ISO note, but the side explanation justifies a 4.

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 purpose: return the single best exchange house for buying or selling a currency, with 'right now' scoping it to current market conditions. 'The single best' implicitly separates it from siblings like list_houses and get_rates, though it doesn't name them explicitly. It stops short of a 5 because differentiation from siblings is implied rather than stated.

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 usage context is implied: use this when you want the one best casa de cambio for a given currency and side, rather than all houses or plain rates. The description gives no explicit when-to-use vs. when-not-to-use guidance and names no alternatives such as list_houses or get_rates. This meets the 'implied usage' level but nothing more.

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 this read-only and open-world, so the description does not need to repeat safety. It adds meaningful behavior detail: results are based on seller-declared risks, include the verbatim phrase and severity, and compute a price discount against a clean cohort, plus a category-level summary.

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?

A single, dense sentence front-loads the core result and ends with a practical use case; there is no filler. The long list of risk categories makes it slightly heavy, but each element contributes.

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 14-parameter, no-output-schema tool, the description names the key output components but leaves out response shape, pagination/ordering behavior, and how filters combine. Optional parameters and helpful annotations reduce the risk, but an agent still lacks some operational detail.

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?

Only 36% of the 14 parameters are documented in the schema and the description does not mention any parameter, so it fails to compensate for the low coverage. Some parameter meaning is implicit through enums and names, but fields like brand, kmMax, transmission, and yearMin remain semantically thin.

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 defines the tool's output: listings whose seller declares a risk, with the textual phrase, severity, and price discount compared with non-declared peers, plus a category summary. It is unambiguous, though it never names or contrasts a sibling tool such as search_used_cars, so it stops short of full differentiation.

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?

Ends with explicit use cases: understanding the discount on a car with debt or discarding risky listings. This gives clear context for when to call it, but it does not state when not to use it or name alternatives.

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 the safety profile is covered. The description adds meaningful behavioral context beyond the schema by explaining that the data is published supply, not actual sales, and by detailing what each section computes, such as depreciation per year and km/automatic-transmission effects on valuation. It does not explain how sections are selected or returned, but the added context is substantial.

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 compact and front-loaded with the core purpose, then enumerates all seven sections in a single informative sentence. There is little redundancy, though the long list of sections could be more readable with line breaks or bullet-like structure.

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 no output schema, the description is the only source for return semantics, and it covers most sections well. However, it leaves 'rotation' unexplained and never clarifies whether the section parameter is required, whether it filters the report or selects one section, or how parameters apply to other sections. An agent can handle common cases but will have to guess about 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 only 33%, so the description must compensate. It maps budgetUsd to the budgets section and model to the depreciation section, and it lists all section enum values with brief meanings. This adds value beyond the schema, though budgetUsd's usage is only lightly described and the interaction between section and the other parameters is not made explicit.

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 identifies the tool as a Uruguayan used-car market report and distinguishes its data scope with 'oferta publicada, no ventas'. It lists seven specific sections, giving an agent a concrete idea of what the tool produces. It does not explicitly name sibling tools, so differentiation relies on the section list rather than direct comparison.

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 provides clear context: this is a market report of published used-car supply, not sales. It also gives usage hints for two parameters: 'pasá budgetUsd' for budgets and 'pasá model' for depreciation. However, it does not mention alternatives like car_model_prices or search_used_cars, nor does it state when not to use this tool.

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?

The annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by naming Mercado Libre as the price-guide source and describing the aggregated output (median, range, opportunities, cheapest). It does not disclose limitations like data freshness, currency, or how 'opportunities' are defined, so it is adequate but not richly transparent.

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 two purposeful sentences with the core question front-loaded and no filler. The first sentence packs the output dimensions into a dense but meaningful list, and the second anchors usage with concrete examples. It earns a 4 rather than 5 because the long list of outputs makes it slightly heavier than necessary.

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?

There is no output schema, so the description carries the burden of explaining what comes back. It does name the main output components and the price-guide source, which is enough to understand the tool's purpose. Yet it omits practical details such as currency, data freshness, what happens when no year is provided, and what a result looks like, leaving moderate ambiguity.

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?

With 0% schema description coverage, the description must compensate. It partially does: it explains that year is optional ('de un año si se indica') and that 'version' refers to engine and gearbox groupings, and the Onix 2019 example illustrates model plus year. However, it does not explicitly define the brand parameter or give format/constraint guidance beyond what the schema already supplies.

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 that the tool provides asking-price statistics for a car model: median, range by year and version, a Mercado Libre price guide, model opportunities, and cheapest listings. The example queries ('¿cuánto vale un Onix 2019?', '¿a cuánto vendo mi auto?') make the purpose concrete. However, it does not explicitly distinguish this tool from siblings such as car_market_report or find_car_opportunities, so differentiation is implicit rather than stated.

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 provides clear trigger examples for valuation questions: how much a specific model is worth, and how much to sell a car for. This gives an agent usable guidance on when to invoke the tool. It stops short of a 5 because it never states when not to use it or which sibling tool to prefer instead.

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 establish readOnlyHint and openWorldHint, and the description adds meaningful behavioral context beyond those: it never gives a trust verdict, presents dated signals, and lets the user decide. This directly shapes agent behavior and prevents overclaiming.

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 two sentences with no filler. The first sentence front-loads the full list of signals, and the second adds a critical behavioral constraint. Every sentence earns its place.

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 simple one-parameter read-only tool, the description covers what the tool returns and how it should behave. It lacks explicit output formatting details, but the description's instruction to 'present the signals and let the person decide' is sufficient given the tool's simplicity.

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 only parameter, name, is already documented as 'Nombre, dominio o URL de la tienda.' The description does not add parameter-level details, but the schema carries the full burden adequately, so the baseline score applies.

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 identifies the resource (an online store selling in Uruguay or for purchases abroad) and the output (dated trust signals such as domain age, ratings, HTTPS, contact info, return policy, and payment methods). It is not a tautology and is unambiguous, but it does not explicitly differentiate itself from sibling tools.

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 intended use is implied: the tool should be used when someone wants dated signals about an online store's trustworthiness. However, it does not mention when to use alternatives or explicitly exclude other tools, leaving the routing decision to inference.

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 only declare readOnlyHint and openWorldHint, so the description carries the burden of explaining behavior. It adds useful context by naming public data sources (Ministerio del Interior, OSE, IM) and explaining ranking semantics for rent, monthly, safety, and services. 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?

Two sentences with the purpose front-loaded and no filler. The second sentence is dense, but the packed list of compared data points is relevant and earns its place.

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?

There is no output schema and six optional parameters, so the description must carry a lot of weight. It covers the returned data well, but it does not describe the output shape, default behavior when neither neighborhoods nor rankBy is provided, or how department interacts with the Montevideo-specific ranking.

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 only 33%, and the description partially compensates by explaining the rankBy enum values and how neighborhoods is used. However, it leaves limit, bedrooms, type defaults, and the relationship between department and the Montevideo-specific ranking under-explained despite the low schema coverage.

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 'Compara barrios lado a lado', a specific verb-resource pair, and enumerates the exact data dimensions compared (rent, crime, water cuts, services, ranking). It is clearly distinguishable from sibling rental/property tools, though it does not name any sibling 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 explicitly gives two invocation modes: pass neighborhoods to compare them or pass rankBy to list the best, and it defines each rankBy value. It does not mention when to choose this tool over siblings or give exclusions, but the within-tool usage guidance 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?

With no annotations, the description carries the behavioral burden and does disclose the non-obvious UYU routing and 'best available market rates'. However, it does not mention the return shape, whether the conversion is indicative or executable, or any error/edge-case behavior.

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 brief, front-loaded with the core purpose, and every sentence adds useful information. There is no redundant or filler content.

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 simple three-parameter conversion tool, the core invocation details are covered by the schema and description. The main gap is the absence of an output schema or stated return format, but the tool's purpose and routing behavior are sufficiently clear for an agent to call it correctly.

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 input schema already describes all three parameters, so the baseline is 3. The description adds value by listing example accepted currency codes (USD, EUR, ARS, BRL, UYU), helping the agent construct valid from/to arguments.

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 clear action and resource: 'Convert an amount between currencies' using Uruguayan market rates. It also gives a distinguishing behavioral detail (foreign↔foreign routes through UYU), though it does not explicitly contrast any sibling tool.

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 implies when to use the tool (currency conversion with Uruguayan rates) but does not explicitly state when to prefer it over siblings like get_rates, nor any exclusions or prerequisites. Usage context is present but not fully articulated.

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?

With no annotations, the description carries the full disclosure burden. It states the output is 'AI-generated analysis,' implying synthesized narrative rather than raw data, and it exposes language options. It does not mention read-only semantics, data freshness, output format, or behavior when a requested currency has no data, so some behavioral gaps remain.

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 two concise sentences with the core scope front-loaded. The conditional usage is compressed into one clear clause, and the language note is minimal. There is no filler or redundant phrasing.

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 two optional parameters and no output schema, the description captures the essential invocation modes and market scope. It does not specify the return format beyond 'analysis,' and 'daily' is implied by the name rather than described, so it is not fully exhaustive. Still, an agent can call it correctly without requiring additional information.

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. The description adds the conditional semantics of the currency parameter ('without... with...') and restates the lang values, but the schema already conveys the optional per-currency behavior and language choices. The added value beyond the schema is minimal.

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 'AI-generated analysis of the Uruguayan exchange market,' clearly identifying the deliverable and market scope. It further differentiates the tool through its conditional behavior: whole-market without currency, per-currency with one. The verb is implicit rather than explicit, but the purpose is not likely to be confused with sibling rate or news tools.

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 explicitly explains how to switch between whole-market and per-currency modes: omit currency for a market summary, provide one for per-currency analysis. It also enumerates the allowed language values. However, it does not contrast this tool with siblings such as get_rates or get_evolution, leaving when to prefer raw rates or historical data to inference.

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 provide readOnlyHint=true and openWorldHint=true)Skip. The description adds meaningful behavioral detail beyond those hints: it uncovers that the estimate is based on comparable ads from distinct advertiserschers, that askingPrice triggers a percentile and over/under median calculation, and that 'Casas: superficie construida' clarifies the area basis for houses. This adds context without contradicting the 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?

Three concise sentences: what it does, when to use it, and one critical areaBasis caveat. The main action is front-loadedabb, no redundant phrasing, and every sentence adds distinct value.

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 no output schema and 10 parameters, the description gives enough orientation at a high level: inputs, methodology, optional askingPrice output, and use case. It does not provide output structure or examples, but the core information an agent needs to decide and call the tool is present.

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 only 40%, so the description carries part of the burden. It clarifies askingPrice semantics (optional price to be located in the distribution) and the 'Casas: superficie construida' rule, which supplements areaBasis. However, it does not explain several parameters such as parkingSpaces, currency defaults, or neighborhood syntax, so the compensation is partial.

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: 'Estima el alquiler justo de una vivienda concreta', listing the key property inputs. It goes beyond a generic label by specifying methodology (comparable listings from different advertisers) and the optional askingPrice percentile analysis, which collectively distinguish it from sibling tools like search_rentals or rental_market_stats.

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 explicitly states when to use it: 'Sirve para "¿me están cobrando caro?" o para negociar.' This gives clear intended user scenarios. It does not explicitly mention when not to use it or name alternative tools, so it falls short of a full routing guide, but the context is clear enough.

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 cover readOnlyHint and openWorldHint, and the description builds on that by disclosing the internal data-quality pass (each opportunity checked for active card, same price, and absence of crash/recovery/debt/foreign plate), the output contents (gap %, conservative gap, sample stats, comparables with links) and the tier distinction. None of these behaviors are visible from annotations alone.

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 yet efficient, front-loading the core premise (below-cohort price), then the verification pass, then the output payload and tier semantics. Every sentence carries distinct information with no filler, though the density of technical jargon (cohort, brecha conservadora, p25/mediana/p75) may slow comprehension slightly.

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 high complexity (14 optional filters, no required params, no output schema), the description does a good job of explaining the returned data and the strict/exploratory dichotomy. However, it omits practical aspects such as pagination behavior (page/limit interplay), how filters interact with the fixed-cohort matching, and the scale/ordering implied by 'sort', leaving gaps for a multi-parameter open-world query tool.

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 only 29% across 14 parameters, so the description bears the burden of explaining filters, but it only clarifies the 'tier' parameter and the 'brecha' concept. The other 13 parameters (body, fuel, sort, seller, kmMax, yearMin, department, etc.) go unexplained, leaving a large gap where the description should compensate for the sparse schema.

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 precise verb+resource: finding cars priced below their fixed cohort (same model, year, version, engine, transmission within a km band). This clearly differentiates it from siblings like car_market_report, car_model_prices, search_used_cars and get_car by describing its specific matching logic rather than generic search or reporting.

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 explains the tier semantics (strict = solid evidence, exploratory = to explore) and the qualifying criteria, giving clear context for when the tool applies. However, it does not explicitly name sibling alternatives (e.g., search_used_cars for general browsing) or state when NOT to use this tool, leaving routing to inference.

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 provide readOnlyHint and openWorldHint. The description adds meaningful methodology context: rental comparisons include common expenses, the gap is conservative, and results are supported by comparables/advertisers with caveats. 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 dense but efficient: every sentence contributes methodology, scope, or a caveat. The first sentence is long and packed with details, but no filler is present and the core concept is front-loaded.

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 12 optional parameters and no output schema, the description covers the main return fields (gap %, conservative gap, comparable counts, evidence level, cautions) and the rental/sale convention. It does not explain how pagination, sorting, evidence, or confidence filters alter results, leaving an agent to infer some behavior from enum names alone.

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 only 33%, so the description should compensate for the 8 undocumented parameters such as sort, signal, evidence, confidence, and neighborhood. It does not; the only parameter-related clarification (rent + common expenses) repeats what maxPrice already documents.

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 defines the resource: homes listed below comparable asking prices, with gap metrics and evidence levels. It lacks an explicit action verb like 'find' or 'list' and does not name sibling tools, but the intent is unmistakable and the 'no es una tasación' line adds useful scope.

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 implies use when searching for underpriced listings and explicitly excludes use as an appraisal ('no una tasación'). However, it does not state when to prefer this over related siblings like estimate_fair_rent or rental_market_stats, nor does it give concrete alternatives.

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 and openWorldHint=true, so the safety profile is covered. The description adds that it uses Google Maps and accepts place names, which is useful context. However, it doesn't disclose behavior like ambiguity handling (e.g., multiple matches), coordinate format, or whether the department parameter is required for disambiguation. With annotations covering the read-only nature, a 3 is appropriate.

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?

Two sentences with zero waste. The core purpose is front-loaded, examples are compact, and the alternative-routing note is placed at the end. Every sentence earns its place.

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 simple read-only geocoding tool with 100% schema coverage and no output schema, the description is nearly complete. It covers what inputs are accepted, the provider (Google Maps), and when not to call it. The only minor gap is not describing the output format (coordinates), but since there's no output schema, a brief note on return shape would have been nice. Still, the tool is simple enough that an agent can infer the output from 'coordenadas'.

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 both parameters (address and department) are already documented in the schema. The description adds examples of place names and the fact that department is optional, but it doesn't add meaning beyond the schema's own descriptions. Baseline 3 is correct when the schema does the heavy lifting.

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 ('Convierte') and resource ('una dirección, esquina, barrio o nombre de lugar de Uruguay') into coordinates with Google Maps. It clearly distinguishes itself from siblings by noting that search_rentals and rank_rentals_for_household already geocode internally, so this tool is only needed for standalone geocoding.

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 explicitly says when NOT to use this tool: if you're calling search_rentals or rank_rentals_for_household with an address, they geocode themselves, so no need to call this first. This is a clear exclusion and alternative routing, which is exactly what an agent needs.

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 read-only, so no safety disclaimer is needed. The description adds substantive behavioral context by disclosing what the tool computes and returns: cohort median/range, price position, ML guide reference, seller risks with their exact phrase, and similar cars. It does not cover error handling, but the read-only annotation lowers that burden.

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 two sentences with no filler: the first front-loads the resource and lists specific data fields, the second clarifies the accepted input form. The enumeration is dense but each item adds concrete information about what the tool returns.

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 one required parameter, read-only and open-world annotations, and no output schema, the description covers the essentials: how to pass the input (key or URL) and exactly what the response will contain (listing facts, cohort comparison, ML reference, seller risks, similar cars). No critical calling information 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?

The schema provides only a string constraint for 'key' with 0% description coverage, so the description must compensate. It does so by stating that the parameter accepts either a bare key or the full URL, and it shows the URL pattern with the <key> placeholder. This meaningfully resolves the ambiguity, though it does not fully define the key's format on its own.

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 title 'Ver un auto en detalle' plus the description 'Ficha de un aviso de auto usado' clearly identifies a detail-view operation for a single used-car listing. The enumerated contents (version, engine, km, cohort stats, price position, ML guide reference, seller-declared risks, similar cars) make it easy to distinguish from siblings like search_used_cars or car_model_prices.

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?

Usage is implied rather than explicit: the tool is clearly meant for when you already have a specific listing key or URL and want its full detail sheet. However, it never explicitly says when to choose this over siblings like search_used_cars or car_declared_risks, nor does it state exclusions.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose what the tool returns (series plus min/max/avg/current/change) and the time-window scope. It does not mention response ordering, error behavior, or whether any side effects exist, though the tool appears to be a read-only query.

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 exactly two sentences with no filler. The main function is front-loaded, and the list_houses pointer is a useful, concise addition. Every sentence earns its place.

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?

The description covers the core purpose, the key inputs, and the content of the returned result well enough for a simple history query. With no output schema, it would benefit from specifying the exact response structure or result ordering, but the omission of the period default is acceptable because the schema already documents it.

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 input schema already provides 100% coverage with descriptions for all three parameters. The description adds value by clarifying that origin refers to an exchange house and by pointing to list_houses for valid origin IDs. It also reinforces that period maps to 'last N months', supplementing rather than repeating the schema.

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 identifies the tool's purpose: returning historical rate series and statistics for a given exchange house and currency over a time period. The phrase 'historical rate series and statistics (min/max/avg/current/change)' distinguishes it from a simple current-rate lookup, though it does not explicitly name sibling alternatives like get_rates.

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 provides clear context for when to use the tool: when historical rate data and summary statistics for a specific origin and currency are needed. It also gives a practical prerequisite by recommending list_houses for valid origin IDs. It does not, however, explicitly state when not to use this tool or compare it with siblings.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple verb+object by revealing two useful behaviors: results are de-duplicated and sorted newest-first, and the source is Google News. It does not mention pagination, rate limits, or output format, but for a simple read-only news tool this is reasonably transparent.

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 a single, compact sentence that immediately communicates the source, scope, and ordering behavior. Every phrase carries meaning and there is no redundant or filler content.

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 tool's simplicity—one optional parameter, no nested objects, no output schema—the description gives an agent enough context to call it correctly. It names the resource, the source, and the processing guarantees, which is complete for this use case.

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 input schema has 100% description coverage for the only parameter, 'limit', including its default and maximum. The description adds no parameter-specific details, but none are needed because the schema already fully explains the parameter.

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 resource ('Uruguayan dollar/economy headlines'), a clear source ('Google News'), and key processing behavior ('de-duplicated and newest first'). This clearly distinguishes it from the sibling tools like get_rates or list_houses, which address different domains.

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 phrase 'Latest ... headlines' implies the tool should be used when current market news is needed, and the scope is clearly Uruguayan. However, there is no explicit guidance about when not to use it or which sibling tool to choose instead, leaving the agent to infer selection from context.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by stating exactly what the tool returns and explicitly what it excludes (BCU and interbank quotes), giving a clear model of the tool's behavior. It does not mention error handling, side effects, or data freshness, but the query-like nature and detailed output list provide solid transparency.

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 compact and front-loaded, opening with the core deliverable and then adding currency format and exclusions in the second sentence. Every clause adds value, with no redundancy or filler.

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 one-parameter tool with no output schema and no annotations, the description is quite complete: it enumerates the included data items (average, best house, spread, full list) and states exclusions. Minor gaps like output format or behavior on unsupported currencies are acceptable given the low complexity and the level of detail already present.

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%: the schema already documents the currency parameter as an ISO code with examples. The description repeats the same examples (USD, EUR, ARS, BRL) and adds no parameter-level meaning beyond what the schema provides, which meets the high-coverage baseline of 3.

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 identifies the operation: retrieving current buy/sell rates for a currency across Uruguayan exchange houses, and enumerates the specific outputs (market average, best buy/sell house, lowest spread, full per-house list). It also distinguishes itself by explicitly excluding BCU and interbank quotes, making it easy to differentiate from sibling tools like best_house or convert.

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 implies when to use the tool by stating it provides current rates for a currency and lists what data is returned, but it does not explicitly mention sibling alternatives or provide when-to-use versus when-not-to-use guidance. The exclusion of BCU and interbank quotes gives some scope context, but not enough to route an agent away from potentially overlapping tools like best_house or daily_summary.

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 and openWorldHint=true, so no contradiction exists. The description adds useful behavioral context beyond the annotations by spelling out the exact contents of the response: per-portal prices, neighborhood comparisons, similar homes, and neighborhood profile data. It does not discuss errors, rate limits, or data freshness, but the annotation coverage lowers the burden.

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 densely packed but every clause adds useful information about the tool's scope, and the input instruction is front-loaded at the end. The first sentence is long and enumerative, but it is not padded or repetitive.

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 there is no output schema, the description compensates well by enumerating the major response components. It also covers the single required parameter's accepted forms. Minor gaps such as error behavior and exact return structure are acceptable for a simple read-only detail fetch.

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 says the key can be a key or URL. The description adds value by specifying the exact URL template, https://cambio-uruguay.com/alquileres/<key>, and clarifying that the key comes from other tools, which helps the agent construct or pass the parameter correctly.

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 ('Ficha completa de una vivienda en alquiler') and enumerates the detailed sections returned, making it unmistakably a detail-view tool. This clearly distinguishes it from siblings like search_rentals or list_houses, which are listing-oriented.

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 usage context by stating that the tool accepts the key returned by 'las otras tools' or a direct URL, implying it is meant to be used after a search or with an existing listing. It does not explicitly describe when not to use it or name alternatives, so it stops just short of full guidance.

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 and openWorldHint=true, so the agent knows this is a safe, open-world read operation. The description adds that the result includes item counts, dates, and links, which is useful context. It doesn't disclose pagination, freshness, or whether the list is exhaustive, but the openWorldHint covers some of that.

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 a single, information-dense sentence that front-loads the main purpose and then lists the output fields. It is concise and every part adds value, though the long parenthetical list of directory examples is somewhat bulky.

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 zero-parameter, read-only listing tool with no output schema, the description adequately tells the agent what it will get: directory names, item counts, dates, and links. It doesn't specify the output format, but the absence of parameters and the simple listing nature make this a minor gap.

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 tool has zero parameters, so the description doesn't need to explain parameter meaning. The baseline for 0 params is 4, and the description appropriately focuses on what the output contains rather than input semantics.

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 lists the site's directories, their item counts, dates, and links, with a specific verb ('list') and resource ('directories'). It doesn't explicitly differentiate from siblings, but the resource and detail level are distinct enough among the sibling names.

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 implies usage: call it to see which directories exist and their sizes/dates/links. It doesn't explicitly state when to use it versus alternatives, but given zero parameters and a listing purpose, the context is reasonably clear. No exclusions or alternative routing are provided.

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?

With no annotations, the description carries the behavioral burden. It clearly signals a read-only listing operation and discloses the scope ('all ... tracked') and included fields. It does not mention ordering, pagination, or output format, but for a simple zero-parameter list this is acceptable.

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 entire description is one efficient, front-loaded sentence. It packs the geographic scope, the Spanish-language alias, and the returned fields into minimal space with no filler.

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 zero-parameter listing tool with no annotations or output schema, this description is nearly complete: it names the resource, scope, and return attributes. A minor gap is that 'departments served' is slightly ambiguous without clarifying that these are Uruguayan departments.

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 tool has zero parameters, so the description does not need to explain parameter meaning. The baseline for zero parameters is 4, and the description adds useful context about what the returned data contains.

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 uses a specific verb ('list') and a precise resource ('all Uruguayan exchange houses'), and enumerates the returned attributes: display name, website, and departments served. This makes the tool's role clear and distinguishes it from sibling tools focused on rates, conversion, evolution, news, and summaries.

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 intended use is implied: call this to get a directory of exchange houses and their basic contact/coverage information. However, there is no explicit guidance about when not to use it or how it relates to siblings such as get_rates or best_house.

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 readOnly and openWorld annotations, the description reveals concrete behavior: it generates a line-by-line budget with prices, recommends used or new items, subtracts items the user already has, and explicitly states that if some prices are missing the total is partial and the tool says so. This is substantive behavioral disclosure.

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 only two sentences with no filler. The first sentence front-loads purpose, scenario, and key output features; the second handles the important edge case of missing prices. Every word earns its place.

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 no output schema, the description carries the burden of explaining the result format, and it does: line-by-line pricing, used/new recommendation, subtraction of existing items, and partial-total transparency. Given the simple three-parameter input with 100% schema coverage, this is complete enough for correct invocation.

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 meaning: 'canasta mínima, decente o completa' maps to level, 'conviene usado o nuevo' clarifies condition options, and 'restando lo que la persona ya tiene' explains the have parameter's effect. It enriches the schema rather than merely repeating it.

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: 'Presupuesto para equipar una vivienda vacía', clearly defining the tool as a home-furnishing budget generator. It further distinguishes itself from sibling tools focused on rent, neighborhoods, or car pricing by naming the exact scenario 'después de alquilar sin amueblar' and the output structure.

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 provides clear usage context by identifying the ideal situation: furnishing an empty home after renting unfurnished. It does not explicitly name alternatives or state when not to use the tool, but the context is specific enough to guide selection.

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?

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.

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

Annotations already provide readOnlyHint and openWorldHint, and the description adds valuable behavioral context: the chunking mechanism (8,000 characters, offset), and the snapshot nature of the data ('Las cifras son del día en que se leyó la página'), which is beyond annotations. 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 three compact sentences, each earning its place: first states what it does and chunking, second states the intended use, third notes data freshness. No redundancy or filler, and the key info is front-loaded.

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 2-parameter read-only tool with no output schema, this description covers the essential aspects: purpose, usage context, pagination, and data freshness. An agent has enough information to call it correctly, and the annotations handle safety. 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 description coverage is 100%, so baseline is 3. The description adds extra meaning by explaining offset usage ('usá offset para seguir') and the specific chunk size (8,000 characters), which is not in the schema. This clarifies the pagination semantics beyond the schema's basic parameter descriptions.

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 it retrieves the text of a page from cambio-uruguay.com, including its sections, in 8,000-character chunks with offset for continuation. It explicitly connects to search_site, differentiating its role as the tool for precise quoting after search, so an agent can distinguish it from siblings.

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 says 'Para citar con precisión lo que search_site encontró' (to quote precisely what search_site found), giving a clear context for when to use this tool. It implicitly suggests alternatives via the reference to search_site but does not list other exclusions or when-not-to-use scenarios, so a 4 is appropriate.

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 and openWorldHint annotations, the description adds a meaningful behavioral caveat: the prices are asking prices, not signed prices. It also clarifies that the tool returns statistical aggregations rather than individual listings. It does not describe response formatting or edge cases, but the annotations reduce the burden.

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 compact and well-structured: core output, grouping dimensions, concrete use cases, and a caveat in three short sentences. Every sentence earns its place and the most important information is front-loaded.

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 no output schema, the description usefully enumerates the returned metrics and available grouping dimensions, plus an important data-quality caveat. It does not state the default behavior when no filters are passed, but for a tool with all optional parameters this is a minor gap.

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 schema already documents currency, department, and neighborhood. The description adds natural-language mapping through examples like '2 dormitorios' and 'Pocitos' and mentions grouping by type and bedrooms. However, it does not materially explain the values or constraints for the undocumented 'type' and 'bedrooms' parameters, so it only partially compensates for the 60% schema description coverage.

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 identifies the tool as providing rental market statistics: median and typical p25–p75 range, common expenses, monthly total, and price per m², segmented by department, neighborhood, property type, and bedrooms. It does not explicitly distinguish itself from analytical siblings like estimate_fair_rent or compare_neighborhoods, but the aggregate-statistics framing is strong and actionable.

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 explicitly says 'Usalo para' and gives two concrete example queries: '¿cuánto sale alquilar 2 dormitorios en Pocitos?' and '¿dónde me alcanza con $30.000?'. This gives clear context for when to invoke the 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 declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context: daily data refresh, sorting from cheapest to most expensive, and return of lowest price plus typical price band (p25–median–p75), which goes 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 dense but organized, front-loading what the tool does before giving category and output detail. Every clause adds useful information, though the long list of examples makes it slightly heavier than strictly necessary.

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 search tool with six optional parameters and no output schema, the description covers the search scope, sort order, and return content well. It does not document pagination or the brand/limit behavior, but these are minor given the simple parameter semantics and annotations.

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 67%, so the description carries extra weight. It enriches the meaning of the text/vertical parameters by enumerating categories and retrieval details, and clarifies price-related output semantics. Brand and limit remain lightly described, but those are easily inferable from their names.

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+resource: a unified search across Uruguayan product directories, with concrete verticals (phones, chairs, home, e-mobility) and output fields. This clearly distinguishes it from sibling search tools like search_used_cars and search_rentals.

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 context is clear: use for product price searches across listed directories. However, it never explicitly tells the agent when not to use it or names an alternative tool, so selection guidance relies on inference from the tool's domain rather than explicit routing.

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 declare readOnlyHint=true and openWorldHint=true. The description adds significant behavioral context: it uses a union of five portals, covers ~57,000 properties with listings seen in the last 10 days, and explains that only ~70% of listings publish common expenses, so the total is only shown when the same listing publishes both. It also outlines the return fields (link, median, neighborhoods, save/alert link) and the conditionality of expenses. This is rich disclosure beyond the 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 a long, dense run-on of multiple clauses, listing many filter categories that are simply repetitions of the schema's parameter descriptions. While the purpose is front-loaded and the structure flows from purpose to filters to output to alternative, it is far from concise. It could be condensed by referring to the schema for filter details and focusing on unique behavioral and usage aspects.

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 tool has 28 parameters and no output schema, the description is quite complete. It explains the aggregated sources, the recency (last 10 days), the coverage (~57k listings), the handling of missing expenses, the return data (rent, expenses, total when available, link, median, top neighborhoods, save/alert link), and explicitly names the alternative tool. An agent can understand what to expect and when to use this tool.

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 93%, so most parameters already have detailed descriptions. The description summarizes filter categories (neighborhood, type, bedrooms, price, etc.) but does not add much per-parameter meaning beyond what the schema provides. For instance, it mentions 'TOTAL MENSUAL con gastos comunes' which maps to monthlyMaxUyu/expensesMaxUyu, but the schema already describes those. It adds minimal new semantic value.

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 searches rental homes across Uruguay, aggregating multiple sources (Mercado Libre, InfoCasas, etc.), and lists a comprehensive set of filter criteria. It also explicitly distinguishes itself from the sibling tool rank_rentals_for_household by pointing to that tool for household-based ranking, so an agent can tell them apart without inspecting schemas.

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 to use rank_rentals_for_household for ranking based on income and household moves, providing a clear alternative. It doesn't mention other search-related siblings (e.g., list_houses, get_rental) but the purpose is distinct enough. The description implies usage: whenever a user needs to find rental listings with multi-source filtering and aggregated results. Good but not exhaustive.

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?

The description discloses that this is a read-only site-wide search and what it returns, including page metadata, answer passages, and the date each page was read. Annotations already provide readOnlyHint=true and openWorldHint=true, and the description adds search-scope and result details without contradicting them.

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?

Three sentences, front-loaded with the action and scope, followed by result details and an explicit use case. No filler or repetition of schema fields.

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 two-parameter site search with read-only annotations, the description covers scope, return format, and when to use it. It lacks output schema but voluntarily describes the result shape, so an agent has enough to call and interpret the tool.

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?

Both query and limit are fully documented in the schema, including min/max and example query strings. The description doesn't need to repeat parameter semantics; it stays at the schema 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 the action (search the whole site), enumerates the content areas, and states the return shape (page title/section/URL plus matching text passages and read date). It also contrasts with classifieds searches, which separates it from sibling tools like search_rentals and search_used_cars.

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 use rule: use it for any question that is not about classifieds and to decide where to direct the user. It doesn't list sibling names, but the 'avisos' exclusion plus the overall 'whole site' scope provides practical guidance.

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 and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context: deduplication across sources, approximate count of listings, automatic resolution of common brand/model names, and the fact that each result includes version, engine, consumption, opportunity status, ML guide price, and declared risks with the seller's phrase. This goes beyond what annotations provide.

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 a single dense paragraph that front-loads the core purpose and then lists filters and result contents. It's long but every clause adds information about a distinct filter or output field. It could be slightly more structured (e.g., separating filters from output fields), but it's efficient for a tool with 24 parameters.

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 read-only search tool with 24 optional parameters and no output schema, the description covers the main search dimensions, the deduplication behavior, and the result fields. It doesn't explain pagination (page parameter) or default limit, but the schema covers limit and page. The openWorldHint annotation covers the incompleteness caveat. The description is complete enough for an agent to invoke the tool correctly.

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 58%, so the description carries meaningful weight. It explains the semantics of many filters in natural language (e.g., 'bajó de precio', 'sólo oportunidades', 'sin deuda ni choque declarados', 'publicados en los últimos N días') and adds the deduplication and automatic name resolution behavior. Some parameters like page and sort are not described in the description, but the schema covers those adequately. The description compensates well for the 42% gap.

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 ('Busca') and a precise resource ('autos usados en todo Uruguay'), then enumerates the aggregated sources and the deduplication behavior. It clearly distinguishes this tool from siblings like find_car_opportunities (which focuses on opportunities) and get_car (which likely retrieves a single car).

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 implies usage by listing all filter dimensions and noting that model requires brand ('requiere brand' in schema). It doesn't explicitly name sibling alternatives or state when not to use it, but the exhaustive filter list and the 'un mismo auto en varias fuentes aparece una vez' note give strong context. The openWorldHint annotation also signals that results may be incomplete, which is useful usage guidance.

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 and openWorldHint=true, indicating safe, read-only access. The description adds that the tool returns sections and pages with URLs, which is a concrete behavioral expectation. It does not contradict annotations and provides clear content expectations, though it does not specify output format (e.g., list vs. tree). Given zero parameters and annotations covering the safety profile, this is adequate.

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 a single, well-structured sentence that front-loads the tool's core content ('El menú de cambio-uruguay.com') and immediately states what it provides. No filler words, every phrase contributes to understanding.

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 zero-parameter tool with no output schema, the description sufficiently explains what the tool returns (sections and pages with URLs) and its purpose (orientation). It lacks explicit details on the response format or structure, but given the simplicity and annotations, it is nearly complete. A slightly more explicit statement about the returned data structure (e.g., 'returns a list of sections and pages') would push it to 5.

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 tool has zero parameters, so the description needs to explain none. The baseline for 0 params is 4, and the description adds no parameter-related information, which is appropriate. There is nothing to compensate for.

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 that the tool returns the site's main sections and pages with URLs, acting as a menu for cambio-uruguay.com. It uses a specific verb ('menú' implies providing a list) and a resource, distinguishing it from search-oriented siblings like search_site or read_page.

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 mentions the purpose is 'to orient the person about what is on the site and where,' which implies use for navigation or overview. However, it does not explicitly mention when to use this tool over alternatives like search_site or list_directories, nor does it give exclusion criteria. The guidance is implicit rather than explicit.

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 and openWorldHint=true, covering the safety profile. The description adds a valuable behavioral constraint: 'nunca por total bruto' (never by gross total), which clarifies a specific output rule. This goes beyond the annotations and helps the agent understand a key limitation without contradicting the structured metadata.

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 a single, dense sentence that is front-loaded with the primary function (official SIPC prices). It is concise and contains no filler, though the phrasing is somewhat packed. It earns a high score for efficiency but loses a point for being slightly dense and requiring careful parsing.

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 3 parameters, no output schema, and no required fields, the description should provide a clear picture of expected outputs and parameter usage. It gives a high-level overview of outputs (price categories and cheapest supermarkets) but lacks details on how 'limit' influences results and does not describe the response structure. This leaves an agent guessing about the exact call format, making the tool incomplete for reliable invocation.

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 only 33% (only 'text' has a description). The tool description gives context for 'text' (article) and 'department' (department) via phrases like 'por artículo' and 'de un departamento', but the 'limit' parameter is not explained at all. The description fails to compensate for the low coverage, leaving the meaning of 'limit' ambiguous.

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 provides official SIPC prices per article (with categories and store counts) and cheapest supermarkets per department via a matched basket. It is specific and distinct from all sibling tools, which cover cars, houses, and rentals, so an agent can identify its purpose without confusion. However, it lacks an explicit verb like 'get' or 'return', slightly reducing clarity.

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 mentions a use case ('útil para estimar el costo de vida al mudarse') which implies when to use it, but it does not provide explicit conditions or exclusions relative to other tools. Since no sibling tool covers supermarket pricing, there are no direct alternatives to contrast, but the guidance is still minimal and relies on inference.

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