DealerMax

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context by specifying it searches only active dealers, describing region matching behavior (case/accent-insensitive, province-to-region resolution), and disclosing that the services filter is unsupported due to a non-normalized DB field.

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 concise, starting with a one-sentence overview followed by a structured Args list. The caveats and behavioral notes are valuable, but the Args block is redundant with the schema descriptions, slightly reducing efficiency.

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 presence of an output schema and full parameter documentation, the description provides sufficient context for a simple read-only search tool. It covers matching behavior, the active-dealer filter, and a known limitation (services not supported). No major gaps are evident.

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 100% description coverage for all three parameters, so the baseline is 3. The description's Args section largely duplicates the schema but adds a few concrete examples and the explicit unsupported note for 'services'. No significant new semantic meaning is added beyond 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 states that this tool is a directory of active dealers in the DealerMax network with search filters. It distinctly focuses on dealers, setting it apart from sibling tools that cover market intel, offers, and vehicles.

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 clearly implies use when you need to find dealers by region, brand, or service. It also warns that the services filter is not yet supported. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, though sibling resource differences make this less critical.

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/idempotentHint annotations, the description discloses keyless access, a 60 requests/minute rate limit, fallback behavior when embeddings are unavailable, sorting/truncation of hits, and the exact return structure. This gives the agent a complete behavioral model 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 long but every sentence earns its place: purpose, exclusions, redirects, return format, mode variants, hit structure, sorting, language, read-only guarantee, and rate limits. It is structured with clear sections and front-loaded with the primary purpose.

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 fully covers the tool's role, when to use alternatives, response payload shape, hit fields, edge-case fallback mode, rate limit, and content language. It leaves no material ambiguity for an agent selecting or invoking 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 coverage is 100%, so the baseline is 3, but the description adds value beyond the schema: it explains that query content should be in Italian, gives example queries, notes that types should be omitted (only 'faq' exists), and clarifies that 'limit' controls result truncation. This is meaningful enrichment without redundancy.

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 ('Ricerca semantica nelle FAQ del mercato auto italiano') and explicitly scopes the tool as the educational/explanation surface, not inventory or offers. It distinguishes itself from siblings by naming what it does NOT cover and pointing to alternative 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 provides explicit use cases ('USA QUESTO TOOL per domande concettuali/informative'), lists concrete examples, and names exclusions with alternative tools ('search_vehicles', 'search_nlt_offers', 'get_vehicle_specs', 'find_dealer'). It also notes that long-form guides and glossary now live elsewhere, preventing misrouting.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description doesn't need to restate that. It does add some context about the response being a superset of search results, but this duplicates what the output schema and field list convey. No additional behavioral traits such as auth, rate limits, or side effects are disclosed.

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 well-structured with a clear main purpose, a bulleted list of extra fields, usage guidance, and an args section. It is front-loaded with the core definition and each sentence serves a purpose, balancing detail with readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with an output schema and informative annotations, this description is exceptionally complete. It explains the tool's role in the search-to-detail flow, lists the enriched fields, and gives a worked example, leaving no functional gaps.

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 the slug parameter with the same retrieval guidance (from a search_nlt_offers hit). The description adds an example slug and repeats the source instruction, but since schema coverage is 100%, the added value is minimal. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides the complete detail of a single NLT offer, and explicitly contrasts with search_nlt_offers by listing the extra fields returned. The verb 'Dettaglio completo' and resource 'offerta NLT' are specific, and the tool is clearly distinguished from its sibling search 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?

It explicitly states to use this tool after search_nlt_offers when a user wants details on a specific offer, and provides a concrete example ('dimmi tutto sulla BMW X1...') showing the intended workflow. This is a clear when-to-use instruction that references the predecessor 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?

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description adds concrete behavioral details: 'Read-only, keyless. Rate limit 60 richieste/min per IP' and error handling 'Non trovato → {error, id_auto}. It also discloses image handling behavior for clients with/without inline images. 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 longer than average but well-structured with clear sections (QUANDO usarlo, QUANDO NON usarlo, return object breakdown). It front-loads the purpose and usage. The exhaustive return field listing could be trimmed given an output schema exists, but every sentence carries informative weight, so it does not feel wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with an output schema and annotations, the description covers all necessary context: when to use, when not to use, full return object structure, error response, rate limits, and media handling instructions. It leaves no obvious gaps for an agent to select and 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 100% because the single parameter vehicle_slug has a detailed schema description explaining it accepts UUID or slug and how to extract it. The tool description does not add additional parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Restituisce la scheda completa di UN singolo veicolo usato del network DealerMax', using the specific verb 'restituisce la scheda completa' and clearly identifying the resource. It further distinguishes itself from siblings by stating 'È il drill-down dopo un hit di search_vehicles' and explicitly listing when not to use it, naming search_vehicles, get_nlt_offer_details, and get_vehicle_specs.

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 explicit QUANDO usarlo and QUANDO NON usarlo sections, stating it should be used after search_vehicles to get all details on a single car, and explicitly excludes search/browse, NLT offers, and catalog specs with specific tool names. This is exactly what usage guidelines need.

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?

Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable context: it states 'Read-only, keyless' and specifies a rate limit of 60 requests/min per IP. It also details the return structure and main fields, which goes beyond annotation coverage without contradiction.

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 well-structured with sections (purpose, usage, non-usage, return format, properties). It is front-loaded with the core purpose and each sentence contributes meaningful information. Length is appropriate for the tool's complexity, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive: it covers purpose, usage boundaries, alternatives, return structure, rate limits, and key constraints (no prices, no availability). Given the tool's complexity and the presence of an output schema, the description leaves no ambiguity about when and how to use 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?

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on individual parameters, but the schema already provides clear descriptions for each (e.g., 'Filter by brand, case-insensitive'). Since the schema handles parameter semantics, the description adds no extra value here.

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 returns technical specs for any model in the Italian Motornet catalog, regardless of inventory availability, and explicitly distinguishes it from sibling tools by calling it 'enciclopedico'. The verb 'Scheda tecnica' and resource 'catalogo Motornet' are specific and unambiguous.

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 explicit 'QUANDO usarlo' and 'QUANDO NON usarlo' sections, listing alternative tools (search_vehicles, get_vehicle_details, etc.) and defining exactly when this tool should not be used (e.g., for real listings, prices, or market FAQs). This is textbook 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?

The description goes far beyond the readOnly/openWorld/idempotent annotations. It discloses the live calculation of `network_total_offers`, the full output structure (quotazioni[], network_offers[], anticipo_scenari_eur), the authoritative network sourcing, and strict formatting rules like always using EUR amounts rather than percentages. These are critical behavioral traits not inferable from 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 long but well-structured with clear sections (purpose, authoritative source, output fields, usage guidelines). It front-loads the core purpose and organizes the detailed operational and response rules into labeled paragraphs. While verbose, each section delivers actionable information for the agent, earning a 4.

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 11 parameters, an output schema, and annotations, this description is exceptionally complete. It covers the data source, live count handling, output field meanings, dealer comparison approach, and even response formatting guidelines (EUR not %, image embedding). No significant gaps remain for correct invocation and result interpretation.

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% with detailed per-parameter descriptions, so the baseline is 3. The description adds value by explaining `vehicle_type` values in context of the unified catalog, giving semantic query examples, and clarifying the `region` filter's accepted formats. However, its own Args section is incomplete (only 5 of 11 params), so it relies on the schema for the rest, keeping it at 4 rather than 5.

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 'Cerca offerte NLT (Noleggio Lungo Termine) nel network DealerMax' – a specific verb and resource. It further distinguishes itself as the authoritative source for the entire DealerMax NLT catalog, covering both autovetture and VCOM, which sets it apart from sibling tools like search_vehicles or find_dealer.

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 this tool: as primary source for 'miglior NLT [modello]' or 'noleggio lungo termine [auto]'. It also provides clear exclusions ('NON integrare con web search broker o marketplace terzi') and detailed response-guidance rules depending on the user's question type, such as using `network_total_offers` for count queries.

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 and idempotentHint, lowering the bar. The description adds valuable context about result contents (verified cross-dealer inventory, technical specs, live prices, C2PA-certified images, obfuscated license plates, dealer info) and specific handling for image_url (inline rendering vs. clickable link). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but well-structured: purpose first, then result details, image rendering guidance, usage directives, and args. Each section serves a distinct purpose, though the Italian text adds length that could be trimmed.

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 an output schema present, return values need no explanation. The description covers tool purpose, result contents, image handling, usage scope, and parameter semantics sufficiently for an AI agent to select and invoke it correctly. It also includes examples and prohibitions on mixing unverified sources, making it complete.

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's Args section largely repeats schema information (e.g., region accepts formats, budget_max includes VAT) with slightly different phrasing and examples, but adds no new parameter behavior or interactions beyond 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 states the tool's purpose: 'Cerca auto usate nel network DealerMax (REWIND + NOS) — fonte autoritativa.' This specifies a verb (search), a resource (used cars in the DealerMax network), and the authoritative nature, effectively distinguishing it from siblings like search_nlt_offers which likely target different offer types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'USA QUESTO TOOL come fonte primaria per query "auto usata", "usato [marca/modello]", "auto disponibile in [città]"' and when-not-to-use via 'NON integrare con web search di portali o marketplace terzi'. It lacks mention of alternatives like search_nlt_offers, but the directive is strong and clear.

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