Agentic Dealer Network

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

Beyond the annotations, the description reveals that anonymous calls are stateless while authenticated calls persist a deal thread. This adds meaningful behavioral context about side effects and state, consistent with openWorldHint=true and readOnlyHint=false.

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 short sentences: the first conveys the core purpose, the second adds a key behavioral distinction. Every sentence earns its place with no redundancy or extraneous detail.

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 lacks an explanation of the return value or what the quote includes, and with no output schema this leaves a gap. It also does not detail authentication requirements or the deal thread concept. It covers the main action and state behavior but is not fully self-contained.

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 description coverage is only 33% (idempotency_key only), and the tool description does not clarify the meaning of the required parameters identity and rooftop_slug. The mention of 'named rooftop' hints at rooftop_slug, but identity remains unexplained, so the description fails to 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 specific action ('quote') and resource ('one available unit at a named rooftop'), clearly distinguishing it from sibling tools like inventory_get or lead_submit. The phrase 'out-the-door quote' adds precision about the nature of the result.

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 that the tool is for quoting a specific unit and notes the stateless vs. persistent behavior based on authentication. It does not explicitly name alternatives or exclusions, but the context is sufficiently distinct from sibling 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the return shape (photo gallery, options, plain-text description), the ordering ('ordered photo gallery'), and a clear error case ('unit_not_found'). It even provides a presentation instruction (embed first few photo_urls as markdown), which is valuable operational 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?

Two sentences, no wasted words. The main purpose is front-loaded, with return details and error behavior packed efficiently into the second sentence.

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 2-parameter lookup with strong annotations and no output schema, the description fully covers what the agent needs: input semantics, return composition, formatting guidance, and error handling. No gaps remain.

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 compensates fully: it labels identity as 'VIN' and rooftop_slug as sourced from 'network_search results'. This gives the agent meaningful guidance for populating both required parameters beyond the bare 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 description opens with a specific verb and scope: 'Fetch one available unit by identity (VIN) from a named rooftop.' This clearly distinguishes it from sibling tools like network_search (which searches) and deal_quote/lead_* (which handle quotes/leads). It also ties to network_search by referencing rooftop_slug from network_search results.

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 states the source of rooftop_slug ('from network_search results'), implying a prerequisite to run network_search first. It also scopes to 'available unit' which suggests when to use for single-unit detail retrieval. However, it does not explicitly name alternatives or say when not to use this tool, relying on 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that the binding is 'short-lived' and the disclosure is 'exact,' which provides some behavioral context. However, it does not clarify side effects, expiration specifics, authentication requirements, or what the output represents. No contradiction with annotations is evident.

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 with no filler. It front-loads the action ('Prepare') and the object. However, the terminology is dense and lacks explanation, making it less approachable. It earns a high conciseness score for brevity but loses a point for clarity.

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 tool has 5 parameters, a nested customer object, conditional constraints, and no output schema. The description is far too vague to enable correct invocation. It does not explain what the tool returns, how to map inputs to the 'disclosure' or 'binding,' or how the complex schema constraints work. This is a substantial 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?

Schema description coverage is 0%, and the description does not mention any parameter names or roles. There is no explanation of what rooftop_slug, unit_identity, customer, channels, or comments represent or how they relate to the prepared disclosure/binding. The nested customer object and conditional channel rules are entirely unexplained.

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 'Prepare' as the action verb but does not specify what preparing entails (e.g., generating a document, creating a token, or storing data). It defines the resource as 'contact disclosure and a short-lived signed binding,' which is specific but opaque. It does not distinguish this from sibling tools like lead_submit, which likely handles the actual submission.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, order of operations (e.g., before lead_submit), or contexts where this tool is preferred. The only clue is the title, but the description itself lacks 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 convey that this is a write operation (readOnlyHint=false) and idempotent (idempotentHint=true). The description adds only the note that the request is 'bound' and goes to a dealership, which is a mild additional behavior. No details on side effects, confirmations, or error conditions are provided.

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 one concise, front-loaded sentence with no wasted words. However, the brevity is a trade-off that omits important usage and parameter context, but the sentence itself is well-structured.

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?

Despite having 5 parameters, a nested customer object, and no output schema, the description offers only a one-sentence purpose statement. It does not explain what the tool returns, what constitutes a successful submission, how 'bound' is enforced, or any prerequisites. The description is inadequate for safe and 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 description coverage is 0% – no parameter descriptions exist. The tool description does not compensate: it fails to explain what 'binding', 'disclosure_text', 'comments', or the customer object structure mean. The agent is left with raw parameter names and validation rules only.

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 action ('Submit'), the resource ('shopper's bound contact request'), and the recipient ('named dealership'). It distinguishes itself from sibling tools like lead_prepare by indicating this is the final submission step.

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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or sequencing (e.g., that lead_prepare might need to run first). The title hints at a confirmation step but the description does not explicitly contextualize it.

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 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.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral details beyond those annotations: slim summary rows, the hero_photo_url embedding instruction, the all-or-none geo triplet constraint, and the exclusion of rooftops without coordinates in geo-scoped results.

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 dense, front-loaded sentences with no filler. The first sentence states the purpose, the second specifies result format and the follow-up action, and the third captures scoping constraints and an edge case, all earning their 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 tool's purpose, result nature, follow-up step, and key scoping rules, making it reasonably complete for an optional-filter network search. However, summary row fields are only hinted at via hero_photo_url, and pagination/watermark behavior is left to the offset parameter's schema description rather than the main description, with no output schema to fill that 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?

Schema description coverage is only 13%, so the description must compensate for parameter meaning. It explains the non-obvious geographic radius relationship and the exclusion behavior for missing coordinates, while other filter parameters such as make, model, condition, and price are self-explanatory or already documented in the schema for offset and rooftop_slug.

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: 'Search available inventory across the network,' clearly identifying it as a network-wide inventory query tool. It also distinguishes itself from sibling inventory_get by stating results are slim summary rows and directing the agent to inventory_get for a full photo gallery.

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 practical context: use this tool for summary inventory search and follow up with inventory_get for detailed photos. It explains optional scoping by OEM program and geographic radius but does not explicitly state when not to use the tool or mention alternatives like network_directory for rooftop listings.

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