DealerMax

Get vehicle technical specs

get_vehicle_specs

Read-onlyIdempotent

Scheda tecnica di QUALSIASI modello del mercato italiano dal catalogo Motornet, anche se NON in vendita o a noleggio sul network DealerMAX. È il tool "enciclopedico": caratteristiche di un'auto a prescindere dalla disponibilità reale.

QUANDO usarlo: domande tecniche slegate dall'inventario (dimensioni, consumi, potenza,
autonomia BEV, 0-100, posti, neopatentati) e confronto allestimenti dello stesso modello.
QUANDO NON usarlo: per auto USATE realmente in vendita/noleggio → search_vehicles o
search_nlt_offers; per il dettaglio di UN annuncio (prezzo live, foto, dealer) →
get_vehicle_details o get_nlt_offer_details; per le FAQ del mercato →
get_market_intel. NON conosce prezzi, disponibilità né dealer: solo catalogo tecnico.

Ritorna {query, filters, total, items[], rate_limit}. Ogni voce di items[] è UN
allestimento (una query può restituirne più dello stesso modello): brand, model, trim,
body, fuel_type, engine, performance, dimensions_mm, weight_kg, boot_capacity, tyres,
transmission, drivetrain, emissions_co2_g_km, consumption_l_100km, country_of_production,
novice_drivers_allowed, ev (autonomia + ricarica per BEV), pneumatic_suspensions,
short_description.

Read-only, keyless. Rate limit 60 richieste/min per IP.

Input Schema

TableJSON Schema

Name	Required	Description
`brand`	No	Filter by brand, case-insensitive (e.g. 'BMW', 'Toyota').
`limit`	No	Maximum results to return (1-30, default 5).
`model`	No	Filter by model, case-insensitive (e.g. 'X1', 'Yaris Cross').
`query`	No	Free-text search (e.g. 'Mazda 3 2024', 'Peugeot 2008 ibrido'). Searches brand, model, trim and engine descriptions.
`fuel_type`	No	Fuel type: benzina, diesel, ibrida, elettrica, gpl, metano.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description complements them with concrete behavioral details: it does not know prices, availability, or dealers, it only returns catalog data, it is keyless, and it has a rate limit of 60 requests/min per IP. It also discloses the return envelope and item structure, adding real value 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.

Conciseness5/5

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

The description is structured in clear, purposeful sections: a one-sentence core definition, explicit usage guidance, explicit non-usage guidance, and a compact return-shape summary. Every section earns its place and the most important scoping information is front-loaded.

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

Completeness5/5

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

For a read-only catalog lookup with rich annotations and a full input schema, the description is complete: it defines scope, exclusions, alternatives, return fields, rate limits, and authentication requirements. An agent has everything needed to decide when to call it and what to expect from the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents brand, model, query, fuel_type, and limit with examples. The description adds light context about matching trims and free-text search, but it does not need to compensate for missing schema documentation, so a baseline score of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb and resource: it retrieves technical specifications for any model in the Italian market from the Motornet catalog, independent of real availability. It also explicitly distinguishes itself from sibling inventory tools by calling itself the 'encyclopedic' tool, so an agent can immediately tell what it is and what it is not.

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

Usage Guidelines5/5

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

The description provides explicit 'QUANDO usarlo' and 'QUANDO NON usarlo' sections, naming alternatives such as search_vehicles, search_nlt_offers, get_vehicle_details, get_nlt_offer_details, and get_market_intel. This gives the agent clear routing rules for when to choose this tool versus its siblings.

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

All DealerMax tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool maps to a distinct resource and intent: dealer directory, used-car search and detail, NLT search and detail, catalog specs, and market FAQ. The descriptions explicitly cross-reference the other tools and state when not to use them, so misselection is unlikely.

Naming Consistency5/5

All tool names use lowercase snake_case with a clear verb_noun structure: find_* for dealers, search_* for the two inventory searches, and get_* for details and specs. The pattern is predictable and uniform.

Tool Count5/5

Seven tools is well-scoped for a read-only automotive marketplace server: two search/detail pairs for the two offer types, plus dealer lookup, model specs, and market FAQ. No tool feels redundant.

Completeness5/5

The server covers the full discovery lifecycle for its domain: search and drill-down for both used vehicles and NLT offers, dealer lookup, catalog specs independent of inventory, and explanatory FAQ content. Every search entry point has a corresponding detail tool, so there are no dead ends.

Resources

Need Help?