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

With no annotations, the description carries the full transparency burden. It does disclose that the tool supports progressive updates ('You don't need everything at once') and implies a partial update model. It also mentions the dealer uses this info for the offer. But it does not state whether the operation overwrites existing fields, whether it creates or updates a record, or any potential side effects like changes to the deal. This is moderate transparency for a mutation tool.

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 concise (about 55 words) and front-loaded with the action and resource. It packs essential guidance into three sentences without redundancy. Each sentence adds either purpose, usage strategy, or tiering information.

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 complexity (19 parameters) and lack of output schema/annotations, the description is largely complete: it explains what to collect, how to approach it progressively, and the tiers. The only gap is that it mentions 'photos via the bridge page' but the schema has no photo parameter, which may be slightly confusing. It also does not describe the return value, but that is secondary for an update tool.

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 covers all 19 parameters with descriptions, so the baseline is 3. The tool description adds value by grouping parameters into tiers (quick = VIN/plate + mileage, standard = condition answers, full = photos via bridge page), which helps the agent decide which optional parameters to include. This semantic grouping goes beyond the flat schema descriptions.

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+resource: 'Set or update the buyer's trade-in vehicle information.' This clearly distinguishes the tool from its sibling cars_session_tradein_read, which is for reading. It also defines the scope (trade-in vehicle) and the goal (dealer makes offer based on this info).

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 clear usage context: gather trade-in info from the conversation, start with what the buyer knows, and build progressively. It also defines three tiers (quick/standard/full) that guide how much info to collect. However, it does not explicitly mention when to avoid this tool or point to alternatives, so it stops short of a 5.

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