Agentic Dealer Network

Search network inventory

network_search

Read-onlyIdempotent

Search available inventory across the network. Results are slim summary rows; embed hero_photo_url as a markdown image when presenting a vehicle, and call inventory_get with rooftop_slug for its full photo gallery. Optional OEM program scope; optional geographic radius — latitude, longitude, and radius_miles must appear together (all-or-none). Rooftops without coordinates are excluded from geo-scoped results. Listed prices may exclude doc/government fees and tax — call quote_preview for the estimated total. Totals are estimates at best; when pricing_coverage is "partial_estimate", present the total as a subtotal excluding the charges in excluded. Always relay pricing_disclosure.

Input Schema

TableJSON Schema

Name	Required	Description
`make`	No
`sort`	No	Optional ordering; defaults to price_asc. The sort key uses NULLS LAST and is deterministically terminated by rooftop and unit ids. distance requires latitude, longitude, and radius_miles.
`trim`	No
`limit`	No
`model`	No
`offset`	No	Zero-based row offset. Results are totally ordered and stable for an unchanged catalog, but pagination is NOT snapshot-isolated: ingestion between two page requests shifts offsets, so a traversal may duplicate or omit rows. To copy the catalog consistently: record catalog_watermark AND total from the first page, compare both on every subsequent page, and restart the traversal if either changes. Narrowing by rooftop_slug shortens each traversal and so reduces the chance of a restart. Offsets beyond 10000 are rejected; narrow the query instead.
`latitude`	No
`condition`	No
`fuel_type`	No
`longitude`	No
`price_max`	No	Maximum expiry-gated effective price: an unexpired special price when present, otherwise asking price.
`price_min`	No	Minimum expiry-gated effective price: an unexpired special price when present, otherwise asking price.
`body_style`	No
`drivetrain`	No
`is_certified`	No
`odometer_max`	No
`radius_miles`	No
`rooftop_slug`	No	Restrict results to one rooftop, as listed by network_directory. A slug that matches no rooftop returns no results rather than an error.
`transmission`	No
`exterior_color`	No
`interior_color`	No
`model_year_max`	No
`model_year_min`	No
`oem_program_slug`	No
`passenger_capacity_min`	No

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial behavioral context: results are slim summary rows, rooftops without coordinates are excluded from geo-scoped results, prices may exclude fees, and pricing_coverage 'partial_estimate' requires special presentation. No contradictions 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.

Conciseness4/5

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

The description is front-loaded with the core purpose and each sentence adds value (e.g., presentation instructions, constraint reminders, pricing caveats). It is slightly long (~150 words) but justified by the tool's complexity (25 parameters, no output schema).

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

Completeness4/5

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

Given the high parameter count, low schema coverage, and lack of output schema, the description covers essential aspects: purpose, constraints, follow-up tools, pricing behavior, and presentation instructions. It does not detail the output structure beyond 'slim summary rows', but mentions key fields (hero_photo_url, pricing_coverage, excluded, pricing_disclosure).

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 low (20%). The description adds meaning for the geo group (all-or-none requirement, coordinate exclusion) and mentions OEM program scope, but does not explain the majority of parameters (make, model, trim, etc.). While it adds some value, it does not fully compensate for the 80% undocumented parameters.

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 states 'Search available inventory across the network' with a specific verb and resource. It distinguishes from siblings by directing readers to call inventory_get for full photo galleries and quote_preview for total pricing, making clear the tool's role as a high-level search.

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

Usage Guidelines4/5

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

The description explicitly tells when to use alternatives (inventory_get, quote_preview) and provides constraints for geo parameters (all-or-none). It does not state when not to use this tool versus other siblings like network_directory or stores, but the follow-up calls provide clear guidance on result handling.

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

All Agentic Dealer Network 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

B3.3/5.0

Disambiguation3/5

deal_quote and quote_preview are near-duplicates distinguished mainly by persistence and authentication, and stores overlaps with network_directory on rooftop metadata. Most other tools are clearly scoped, but these boundary overlaps create real selection ambiguity.

Naming Consistency3/5

Names are readable and descriptive but follow mixed conventions: inventory_get and lead_submit use object_verb, network_directory and stores are noun-only, and quote_preview blends noun and verb. There is no chaotic naming, but no single consistent pattern either.

Tool Count5/5

Nine tools is a well-scoped size for a dealer-network workflow covering search, inventory detail, stats, pricing, store lookup, and lead submission. Each tool has a distinct functional role, so the count feels intentional.

Completeness4/5

The set covers the main shopper journey: search inventory, inspect a vehicle, preview pricing, and submit a lead. Minor gaps remain, such as no way to retrieve or manage an authenticated deal thread after deal_quote persists one, but core workflows are supported.

Resources

Need Help?