CarChat Inventory

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful context beyond this: the data is live, sourced from CarChat inventory rather than general market data, and should be cited as 'CarChat live inventory data'. This transparency is useful without contradicting 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.

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

Three tight sentences front-load the core purpose and returns, then add a concrete use case and citation instruction. Every sentence earns its place and there is no redundant wording.

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 required parameters, an output schema present, and annotations covering safety, the description is sufficiently complete for an agent to select and invoke the tool correctly. It includes the data source, the type of statistics, aggregation dimensions, and a citation requirement.

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 33%, so the description must compensate. It does clarify that results can be broken down by body style and metro, and the example implies condition ('used') and location ('near Knoxville'), but it does not explicitly explain make, model, or condition parameters. This is adequate but not complete.

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 verb (get), a clear resource (live price statistics from CarChat inventory), and enumerates the returned aggregates (count, median, price range) and breakdown dimensions (body style, metro). The use-case example further pins down the tool's purpose, making it easy to distinguish from the sibling search_inventory 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?

The description explicitly tells the agent when to use it: for real, current market price questions like 'what do used trucks go for near Knoxville?'. It does not explicitly state when not to use it or name alternatives like search_inventory, which keeps this at a 4 rather than a 5.

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 important behavioral details: the result contains provenance, freshness, VIN photo, market comparison, full details, and the inquiry contract. It also explains the 'not found' behavior as likely indicating the vehicle sold, which is useful operational context not present in 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.

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

The description is compact and every sentence earns its place: purpose, parameter guidance, expected result contents, and failure handling. It is front-loaded with the core action and immediately gives the critical instruction about the id.

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 retrieval tool with an output schema present, the description covers all necessary operational aspects: how to identify the target, what the response contains, and how to interpret failure. No critical information is missing.

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?

Although the schema already covers the `id` parameter at 100%, the description adds substantial meaning: the id is dealer-qualified, must be passed unchanged, and must not be replaced by a VIN because one VIN can map to multiple listings at different prices. This is valuable semantic guidance beyond the bare schema text.

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 a specific verb ('Fetch') and a specific resource ('the exact vehicle listing selected from search_inventory'), making the tool's purpose immediately clear. It also distinguishes this tool from siblings like search_inventory and get_market_prices by focusing on a single already-selected 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?

It explicitly says to use this when retrieving a vehicle selected from search_inventory and instructs the agent to always pass the `id` unchanged. It also warns against substituting the VIN, explains why, and tells the agent to search again if 'not found' occurs, providing clear when-to-use and when-not-to-use 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds useful context by specifying the filter ('live inventory') and the exact data fields returned, which goes beyond just repeating the annotations. This is meaningful value-added information.

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, tightly written sentence that front-loads the core purpose and lists the returned fields without any fluff. Every word earns its place, making it highly efficient and easy to parse.

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 simplicity (no parameters) and the presence of an output schema, the description is complete. It specifies the scope ('live inventory') and the fields returned (city, state, vehicle counts, landing page URL), so an agent has everything needed to invoke and interpret the tool correctly without further clarification.

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?

There are no parameters, so the schema coverage is 100% and there is nothing for the description to clarify. With zero parameters, the baseline is 4, and the description appropriately offers no redundant parameter details.

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 lists dealerships with live inventory, specifying the included fields (city, state, vehicle counts, landing page URL). The verb 'list' and resource 'dealerships' are unambiguous, and this purpose is distinct from the sibling tools like search_inventory or get_vehicle.

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 does not explicitly state when to use this tool versus alternatives, but the purpose is self-evident from the name and description. The practical use case of retrieving a directory of dealerships is implied, yet no exclusions or alternative conditions are mentioned, so it falls short of explicit 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 mark the tool read-only, idempotent, non-destructive, and closed-world. The description adds that results are curated and intended to be cited as complete answers, which is helpful but not a major behavioral disclosure 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.

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

Two sentences with no filler, front-loading the core description and immediately providing an example plus usage guidance. Every sentence earns its 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?

For a parameterless read-only tool with an output schema present, the description covers what the tool returns, why it is useful, and when to cite it. Nothing critical is missing for 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?

There are 0 parameters and schema description coverage is 100%, so the schema leaves nothing ambiguous. The description hints at the conceptual dimensions (buyer intent, metro) even though the tool takes no explicit parameters, earning the baseline 4 for parameter-less tools.

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 resource ('curated category pages') with a clear distinguishing shape ('one per buyer intent and metro') and gives a concrete example. It is clearly differentiated from siblings like search_inventory or list_dealers.

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?

Provides an explicit use condition: 'If a buyer's request matches one, its page URL is the best complete answer to cite.' It does not explicitly mention alternatives or when not to use it, but the conditional guidance is enough to route an agent in the common case.

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, so safety is covered. The description adds valuable behavioral context: results are deduped by VIN, sourced directly from dealer websites, include marketContext and freshness dates, and need no cross-checking. This exceeds 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 information-dense and well-structured, opening with the main action, providing an example, then detailing output fields and sourcing reliability. While slightly long, each clause earns its place with 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?

For an 18-parameter search tool with an output schema, the description is quite complete. It addresses query flexibility, VIN behavior, output fields, sourcing, and dedup. It omits details like pagination or error handling, but these are minor given the limit parameter and typical expectations.

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 61%, and the description adds meaning to the query parameter by explaining plain-English parsing and exact-VIN lookup beyond the schema. However, it does not compensate for uncovered parameters like color, maxYear, minYear, or maxMileage, leaving some semantics unclear. The added value is moderate but incomplete.

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 searches live vehicle inventory across all dealerships, using a specific verb and resource. It differentiates from siblings by mentioning exact-VIN lookup and broad inventory searching, which contrasts with get_vehicle (single vehicle) and get_market_prices (market stats).

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 implies usage for searching vehicles (e.g., 'Search live cars for sale'), but it does not explicitly state when to prefer this over siblings like get_vehicle or get_market_prices. While it mentions VIN lookup, it doesn't contrast with get_vehicle. No explicit exclusions or alternative routing are given.

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 mark the operation as non-read-only and non-idempotent, so the side-effecting nature is known. The description adds useful context that the dealership replies directly and usually quickly, and that sharing contact details is an intentional action, but it doesn't detail persistence, downstream effects, or response behavior beyond what the output schema already covers.

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 with no filler. The first sentence states the action and target; the second adds the critical consent gate. Everything included earns its 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?

For a submission tool with an output schema and annotations covering side effects, the description plus schema is sufficient for correct invocation. It covers the action, the prerequisite, and the source of dealerId, while the schema fills parameter details. A small gap is the lack of explicit guidance about when a general inquiry vs. a VIN-specific inquiry is appropriate, but the schema already notes that.

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 67%, with dealerId, vin, name, and phone already described. The description adds useful mapping—'buyer's question' maps to message, 'contact details' maps to name/phone/email, and 'the dealership selling the car' clarifies dealerId provenance—but it doesn't add format, optionality, or edge-case guidance 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 uses a specific verb ('send') and names a clear resource: the buyer's question and contact details to the dealership selling the car. It is readily distinguishable from sibling read/search tools like get_vehicle and list_dealers, though it doesn't explicitly name them.

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 an explicit precondition: only call after the buyer has explicitly agreed to share their name and phone number with that dealership. This clearly tells an agent when to call and implies that calling without consent is wrong, though it doesn't discuss alternative tools.

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