network_directoryDirectory of active ADN rooftops: slug, name, dealer group, OEM programs, location metadata, and per-rooftop manifest URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the 'active' filter and enumerates fields like slug, name, dealer group, and manifest URL. However, it does not disclose pagination behavior or the response shape, which would be useful additional context.
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 concise sentence, front-loaded with the purpose and followed by a colon-separated list of content fields. There is no filler or 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?
With no output schema, the description should clearly convey return structure and pagination. It lists fields but does not explain how limit/offset affect results or what the response envelope looks like. Adequate for a basic listing but missing key usage 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 0% for both parameters (limit, offset). The description does not mention these parameters at all, leaving the agent to infer their meaning solely from parameter names. No added meaning beyond the schema constraints.
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 'List dealerships' provides a clear verb+resource, and the description specifies 'Directory of active ADN rooftops' with a detailed field list. This distinguishes it from siblings like network_search, which implies searching rather than a full listing.
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?
No explicit guidance is given for when to use this tool vs alternatives. There is no mention of 'use for complete directory' or 'use network_search for filtered queries'. The description only states what the tool is, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.