toyota-mcp

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

The annotations already indicate a non-read-only, idempotent command, but the description adds meaningful behavioral context: it is synchronized with the car's reported charging state, requires the car to be plugged in, and should only be issued after explicit user consent. There is no contradiction with 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 short, front-loaded with the core action, and every sentence adds a necessary constraint or safety condition. There is no filler or redundant restatement of structured fields.

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 one-parameter command with clear annotations, the description is complete: it covers eligibility, preconditions, user-consent requirements, preview behavior, and verification against vehicle state. Nothing essential is left to guesswork.

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 fully documents the confirm parameter, so the baseline is met. The description adds a useful decision rule—use confirm=false for preview when in doubt—which supplements the schema without replacing it.

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 names the specific action ('Start charging the plug-in battery immediately') and the resource, distinguishing it from read-only sibling tools and from schedule-based charging. Vehicle eligibility and the plugged-in requirement further pin down its scope.

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 states when to use the tool: PHEV/EV, car plugged in, and only on explicit user request. It also gives a concrete fallback instruction—'preview with confirm=false when in doubt'—which provides clear decision guidance even without a same-purpose sibling.

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?

The description discloses the post-command verification behavior and the unsupported-model response, which go beyond the annotations. It aligns with idempotentHint=true and destructiveHint=false; nothing contradicts 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 tight sentences: the main action and verification are front-loaded, followed by the caveat. No filler or redundant restating of schema or annotations.

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 action, verification behavior, and support limitation are all covered. With an output schema present and the confirm parameter documented in the schema, the description is complete enough for an agent to invoke the tool correctly.

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 100%, and the single 'confirm' parameter is fully documented in the schema. The description adds no parameter-level meaning, so the baseline 3 applies.

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 ('Close all power windows') on a clear resource, and adds a verification step that distinguishes it from simple status/read siblings. There is no ambiguity about what the tool does.

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 gives practical context by warning that not every model supports the operation and explains Toyota's 'vehicle not supported' response. There is no close-windows sibling to contrast with, so the lack of explicit alternative routing is acceptable, though an explicit 'use when windows are open' condition would be stronger.

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 flag this as a mutating, idempotent, non-destructive action. The description adds useful behavioral detail: the flash is brief, silent, and verified by the car reporting back. No contradiction with the annotations exists.

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 sentence with no waste. The core action ('Flash the hazard lights briefly') is front-loaded, and the two additional facts—'flent' and 'verified by the car reporting back'—are both meaningful and compact.

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 one-parameter command with an output schema and solid annotations, the description covers the essential behaviors: brief action, silent, and confirmation. It could optionally mention prerequisites such as a selected vehicle, but that is not clearly required and would be redundant across sibling tools.

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 100%, and the single confirm parameter is already fully documented in the schema with its preview-versus-send behavior. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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 and resource: 'Flash the hazard lights briefly'. It also states the purpose ('so the user can spot the car') and adds the distinguishing trait 'silent', which differentiates it from audible alternatives like toyota_sound_horn.

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 conveys a clear use context: visually locating the car. The word 'silent' implies the audible alternative is not used, though it does not explicitly name toyota_sound_horn or state when not to use this tool.

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?

The annotations already mark the operation as read-only, non-destructive, and idempotent. The description adds useful beyond-annotation context: the data source is the French government open-data feed, the server must be started with a specific flag, and the search anchor is the car's last parked position. Nothing in the description contradicts 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 front-loaded: core behavior first, use case second, then the prerequisites. Every sentence contributes useful selection or invocation information, and there is no redundant restatement of schema fields.

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 read-only lookup with fully documented parameters and an output schema, the description covers what an agent needs: user intent, fuel type, location anchor, France-only restriction, and the server flag. The 'cheapest' wording sufficiently conveys the result-ordering intent without needing to restate the output schema.

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 100%, and the schema already documents fuel enum values, default limit, max limit, radius bounds, and defaults. The description adds no parameter-specific semantics beyond the phrase 'given fuel', so the baseline score of 3 is appropriate.

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 'Cheapest stations selling a given fuel around the car's last parked position', which clearly identifies the resource, the search scope, and the ordering criterion. It is immediately distinguishable from the sibling tools, which are vehicle status/control operations, not fuel-price lookups.

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 'Use for:' line explicitly frames the intended user query: 'where can I fill up cheaply near the car?'. It also gives an important geographic boundary ('France only') and a server prerequisite ('--addresses fr'). It does not discuss exclusions or alternatives, but no sibling tool is a plausible alternative for this task.

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 this as read-only, idempotent, and non-destructive, so the description only needs to add context beyond that. It discloses the tool's behavior on incompatible powertrains: an explicit 'not applicable' error, and it enumerates the returned data cateories (charge level, status, EV range, time to full, schedules). This adds meaningful behavioral detail 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?

The description is compact and front-loaded: it opens with a concise data summary, then gives example use cases, then provides the key powertrain exception and sibling tool. Every sentence earns its place and there is no fluff. The structure makes it easy for an agent to quickly decide whether to call it.

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 zero-parameter read-only tool with an output schema present, this description is complete. It covers what data is available, when to use it, and how to route non-plug-in vehicles to the correct alternative. Nothing needed for selection or invocation 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?

The input schema has zero parameters, and schema description coverage is 100%, so there are no parameters to document. The description still contributes selection-relevant context by explaining what kind of vehicle and data the tool applies to. A baseline of 4 is appropriate for a zero-parameter tool.

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 and informative phrase—'Plug-in battery: charge level, charging status, EV range, time to full, schedules'—making it clear this tool returns charging-related state for plug-in vehicles. It also distinguishes itself from sibling tools by noting that non-plug-in powertrains should use toyota_get_energy instead. This is more than a restatement of the name; it defines the resource and scope.

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 explicit example questions the tool answers: 'is it charging? how much EV range? when is the next scheduled charge?' It also states a clear exclusion and routes to an alternative: 'Plug-in hybrids and electric vehicles only — other powertrains get an explicit not applicable error (use toyota_get_energy).' This is exemplary 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 declare the tool as read-only and non-destructive, so the description does not need to restate that. It adds useful behavioral context by clarifying that starting/stopping is delegated to sibling tools and by enumerating what remote-start preset fields are returned. No contradiction 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.

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

The description is compact and front-loaded with the tool's core purpose, followed by concrete usage questions and a pointer to sibling tools. Every sentence contributes meaningful guidance with no filler or repetition.

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 zero-parameter read-only tool with an output schema, the description covers what the tool returns, when to use it, and how it differs from related control tools. The agent has enough context to select and invoke it correctly without missing 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?

The tool has zero parameters and the input schema is already complete, so no parameter documentation is needed. The description still adds value by clarifying the conceptual scope of the request: it reads climate state and the saved preset rather than issuing a command.

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 reports remote pre-conditioning state (running or stopped, temperatures) and the saved remote-start preset (target temperature, duration, defrosters, heated seats). It is explicitly distinguished from control tools by naming toyota_start_climate and toyota_stop_climate as the means to start or stop.

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 gives concrete use cases: 'is the climate running? what temperature is the preset?' It also tells the agent that starting or stopping is not this tool's job, naming the exact sibling tools to use instead. This is explicit 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=true, idempotentHint=true, and destructiveHint=false. The description adds a valuable behavioral nuance beyond those annotations: on self-charging full hybrids, battery data is not returned as nulls but is explicitly explained in battery_note. This helps an agent interpret anomalous responses correctly.

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 short sentences carry the full meaning: the resource, the use cases, and the hybrid edge case. Every sentence contributes, and the most important information is front-loaded.

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 zero-parameter read-only tool with a rich output schema, the description is complete: it states what data is returned, when to call it, and the one notable platform-specific behavior. Nothing an agent needs to invoke it correctly 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?

The tool has zero parameters, so the input schema is already fully self-explanatory. The description does not need to clarify parameter semantics, and the baseline of 4 applies.

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 identifies the resource as fuel, driving range, and battery state, and frames it with concrete user questions ('how much range is left? how full is the tank?'). It is specific enough to distinguish from odometer or vehicle-info tools, though it does not explicitly differentiate from the sibling toyota_get_charging, which makes its scope slightly less sharp.

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 'Use for:' section gives direct, contextual triggers such as range, tank level, and charging status. It does not state any exclusions or name alternative tools like toyota_get_charging, so while the guidance is clear, it stops short of explicit routing.

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 indicate the tool is read-only, idempotent, and non-destructive, so the description does not need to restate those. The description adds useful behavioral boundaries: the data covers current alerts and past service history, but not future maintenance predictions. This helps the agent set expectations about what the tool can and cannot answer.

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 short, front-loaded with the most important data categories, and includes a compact usage note. Every sentence earns its place; there is no repetition or filler.

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 the main response contents and the key limitation about maintenance deadlines. The agent has enough context to select and invoke this tool correctly without additional explanation.

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 tool has zero parameters, so parameter-level semantics are not needed. The description still adds value by enumerating what health-related data the response will contain, which is enough for an agent to know what to expect.

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 identifies the tool as providing warning lights, oil indicators, recent notifications, and service history, which makes the resource scope clear. It does not explicitly state a verb like 'retrieves' or 'gets', but the title and sibling context make the operation obvious. It is distinguishable from siblings like toyota_get_status and toyota_get_vehicle_info by its health/maintenance focus.

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 'Use for' section gives concrete, natural-language triggers: any alerts on the car and when it was last serviced. It also includes an important exclusion by noting that Toyota exposes service history, not upcoming maintenance deadlines. It does not name specific sibling alternatives, but the usage guidance is otherwise clear.

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 the tool read-only and idempotent, so the description does not need to restate safety. It adds useful operational context by noting that start/end addresses require the server to be started with --addresses osm or fr. This is consistent with the annotations and goes beyond them.

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 short sentences: result summary first, then usage examples, then a prerequisite. There is no filler, no repetition of schema or annotations, and all sentences earn 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?

For a zero-parameter, read-only tool with an output schema, the description covers what data is returned, when to use it, and the only known precondition. Nothing important is missing for correct selection and 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?

The tool has zero parameters, so there are no parameter semantics for the description to add. With no input schema properties and 100% schema coverage, a baseline of 4 is appropriate.

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 identifies the resource as the most recent trip and enumerates the returned dimensions: distance, duration, consumption, hybrid mode split, and places. The singular 'Most recent trip' differentiates it from the generic toyota_get_trips sibling, though it does not explicitly name that sibling as an alternative.

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 'Use for' lines explicitly map natural-language queries to this tool: 'how was the last trip?' and 'what did the last drive consume?'. It provides clear context but does not state when-not-to-use or mention alternatives.

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 this as readOnly and idempotent, but the description adds genuinely new behavioral context: the position only updates when the car parks, so it may lag behind live driving, and it instructs the agent to cite freshness.vehicle_reported_at. This is valuable beyond the structured 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?

Every sentence earns its place: the first states the result, the second gives the query intent, and the third covers prerequisites and staleness semantics. It is compact, front-loaded, and free of filler.

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 there are no parameters, an output schema exists, and annotations cover the safety profile, the description fully covers what an agent needs: expected data, address caveat, update behavior, and the freshness field to cite. Nothing essential 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?

The input schema has zero parameters, so there is nothing to document. With no parameters, the baseline is 4, and the description doesn't need to compensate for any missing parameter information.

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 (last parked position) and the exact payload (coordinates, Google Maps link, address). It unambiguously identifies this as the 'where is the car?' tool and is distinct from siblings such as find_car or get_odometer.

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 a clear use case: 'Use for: where is the car?' and adds the server prerequisite for address data. It doesn't explicitly name alternative tools or when-not-to-use conditions, but the context is clear enough for an agent to select this tool.

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 disclose readOnly, idempotent, and non-destructive behavior. The description adds a useful semantic detail—'total' distance vs. trip data—and unit ambiguity (kilometers/miles), but does not add further operational context such as data freshness or refresh requirements.

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 concise sentences front-load the core result and add a practical use-case question. There is no redundant detail or filler.

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 zero-parameter getter with an output schema and read-only annotations, the description covers the main use case. It could be slightly more complete by noting how it differs from vehicle_info/status or whether a vehicle must first be selected, but nothing critical 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?

There are no parameters, so the baseline is 4. The description still adds meaning by specifying that the value is total odometer distance and expected in kilometers/miles, which is all an agent needs beyond the empty 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 explicitly states the resource ('odometer') and the value returned ('total distance'), and gives a concrete user-facing question ('how many kilometers/miles are on the car?'). It is clear enough to distinguish from energy, charging, or location getters, though it does not name a sibling.

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 'Use for:' line gives an explicit triggering question, so an agent knows when to select this tool. It does not state exclusions or mention alternatives such as toyota_get_vehicle_info, but for a zero-parameter getter the usage context is clear.

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 that lock state is pushed by the car when parked and can lag, instructing the agent to cite freshness.vehicle_reported_at. This is meaningful behavioral context that directly affects how an agent should phrase answers.

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 front-loaded: component list first, then usage scenarios, then the freshness caveat, then the exclusion. Every sentence earns its place and none are redundant.

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 zero-parameter read-only tool with an output schema and annotations covering safety, the description covers scope, usage, exclusion, and an important freshness caveat. Nothing essential is missing for an agent to select and invoke this tool correctly.

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 tool has zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The baseline of 4 applies because no parameter semantics could be added; the description appropriately focuses on behavior instead.

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 names a specific set of resources (doors, windows, trunk, hood, lock state, lights, rear-seat reminder) and gives example queries that pin down exactly what this tool answers. It explicitly contrasts itself with toyota_get_health, so an agent can distinguish it from siblings without opening schemas.

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 concrete use-for cases ('is the car locked? are windows or doors open?') and provides an explicit exclusion with a named alternative ('Warning lights are NOT here; use toyota_get_health'). This gives 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 false, covering the safety profile. The description adds useful behavioral context like 'newest first' and 'individual trips,' but does not discuss data freshness, availability, or edge cases. Given the strong annotation coverage, this is adequate but not exceptional.

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 front-loaded: the first sentence defines the behavior, followed by concise use cases and sibling routing. Every sentence earns its place, with no redundancy or filler.

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 an output schema present, full parameter documentation, and safety annotations, the description provides all necessary context: ordering, trip granularity, use cases, and explicit alternatives. Nothing critical is missing for an agent to select and invoke the tool correctly.

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 100%, with both 'days' and 'limit' already clearly documented including defaults, ranges, and meaning. The description does not add significant parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

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 returns individual trips over a recent window, newest first. It explicitly contrasts with trip summaries, which distinguishes it from toyota_get_trip_summary and makes the resource and scope unambiguous.

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 concrete use cases ('list this week's trips', 'when did the car last drive?') and explicitly routes users to toyota_get_trip_summary for averages and windows beyond 92 days. This is strong, actionable when-to-use guidance versus alternatives.

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. The description adds meaningful behavioral context by explaining that consumption is recomputed over the whole window as total fuel vs total distance, not as a mean of daily means. This clarifies a subtle computation behavior 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?

The description is concise, front-loaded with the tool's purpose, and uses brief examples to clarify usage. Every sentence contributes meaningfully without unnecessary 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?

With two optional parameters, full schema coverage, an output schema, and read-only/idempotent annotations, the description provides all essential context. It covers both parameter modes, the computation nuance, and representative use cases, leaving no critical gaps for an agent to select and invoke the tool correctly.

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 100%, so the baseline is 3. The description adds usage-oriented semantics by mapping examples to parameters, such as 'last 7 days' to days and 'this month'/'this year' to period, and recommending period to match the app's calendar figures.

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 returns aggregated driving statistics over a rolling window or calendar period, with concrete use cases such as average consumption over the last 7 days. It differentiates this from raw trip-level tools by emphasizing aggregation and windowed calculations.

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 explicit use cases ('Use for: average consumption over the last 7 days, EV-mode share this month, total distance this year') and explains when to use the period parameter. It does not name alternatives or explicitly state when not to use this tool, so it misses the full exclusion 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 readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context by warning that capability flags are indicative only and pointing to remote_capabilities.note, which is value 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?

The description is compact and front-loaded: a concrete field list, then question-style use cases, then a one-line caveat. Every sentence contributes actionable information, with no repetition of the schema or annotations.

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 zero-parameter read-only tool with an output schema and strong annotations, this description is complete. It explains what data is returned, when to use it, and flags an important caveat about capability semantics.

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 and schema description coverage is 100%, so there is no semantic burden on the description. The baseline for zero-parameter tools is appropriate here.

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 names concrete fields (model, year, plate, colour, first-use date, subscriptions, remote capabilities) and frames the purpose as answering specific questions such as 'what car is this?' and 'can it be locked remotely?'. This clearly distinguishes vehicle identity/capabilities from sibling tools like energy, status, odometer, or location.

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 'Use for' section gives explicit question-based scenarios for when this tool is appropriate. It does not state when not to use it or name an alternative tool, but the context is clear enough for an agent to route correctly.

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 covered. The description adds useful context beyond annotations by indicating that the list also conveys the currently active vehicle that other tools act on.

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?

Every sentence earns its place: the first defines the output and the active-vehicle concept, the second gives the use case and points to the sibling. It is short, front-loaded, and free of 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 a zero-parameter, read-only listing tool with an output schema and strong annotations, this description covers purpose, scope, and the relation to the selection flow. Nothing essential 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?

The tool has zero parameters, so the baseline is 4. The description adds relevant meaning about what the result represents, even though there are no parameters to document.

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 that the tool returns every vehicle on the connected account and identifies which one the tools act on. It also explicitly differentiates itself from toyota_select_vehicle, the sibling used for choosing a 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 'Use for: which cars can I ask about?' line provides a clear trigger condition. It also names toyota_select_vehicle as the next step, giving an agent unambiguous routing 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?

Beyond the annotations, the description discloses that the tool verifies the result against the car-reported state and that confirm=false previews without sending. This is important behavioral context not visible in the schema or annotations, and it aligns with the idempotentHint=true annotation.

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 short sentences carry high signal: the action/verification, the when-to-use rule, and the safety-first parameter guidance. There is no filler, repetition, or schema duplication.

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 a single optional parameter, full schema coverage, and an output schema present, the description covers the necessary invocation context, safety behavior, and verification outcome. Nothing essential is missing for an agent to select and invoke this tool correctly.

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 already fully describes the confirm parameter, so the baseline is 3. The description adds useful decision guidance on how to set confirm, saying 'Call with confirm=false first when in doubt,' and explains that 'the report says whether the car confirmed the new state,' going beyond the schema's definition.

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: 'Lock the doors, then verify against the state the car reports.' This clearly distinguishes the action from sibling tools like toyota_unlock_doors and toyota_lock_trunk, while also adding the verification step that makes the tool's behavior unique.

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 usage condition: 'Only when the user explicitly asked to lock the car.' It also provides a concrete safety procedure for uncertain cases: 'Call with confirm=false first when in doubt,' which tells the agent exactly how to use the tool safely.

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?

The description adds meaningful behavioral context beyond the annotations: after issuing the lock command, it verifies against the car-reported state, implying a postcondition check. It does not contradict readOnlyHint=false or idempotentHint=true, and it gives the agent a clearer model of what the tool does.

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?

One sentence contains the action, the scope, and the verification behavior, with the core command front-loaded. There is no filler or redundant 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?

This is a simple one-parameter command with an output schema and supporting annotations. The description covers the key behavioral contract (lock trunk only, then verify), which is sufficient for an agent to invoke it correctly.

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 the single 'confirm' parameter completely with a clear description and default. The tool description does not need to restate its meaning, so the baseline score of 3 applies; no extra parameter detail is provided.

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?

States a specific verb-resource action ('Lock the trunk only') and the verification step, making it immediately distinguishable from siblings like toyota_unlock_trunk and toyota_lock_doors. No ambiguity exists about what resource is targeted.

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 word 'only' clearly delimits this operation from locking the doors and from unlocking the trunk, and the verification step adds a behavioral condition. However, it does not explicitly name alternatives or state negative-use cases, so it stops short of fully explicit routing.

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 signal read-only and non-destructive behavior, and the description adds value beyond them: it clarifies that the tool reads Toyota's cloud but 'never wakes the car.' It also explains the data freshness model, which helps the agent predict side effects and latency expectations.

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 front-loaded: it states the action first, then the rare-use justification, then the safety-relevant non-behavior. Every sentence earns its place with no redundant filler.

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 zero parameters, an output schema present, and annotations covering read-only/idempotent/non-destructive safety, the description supplies the missing contextual pieces: when the refresh is warranted and that it does not wake the vehicle. Nothing essential is left unspecified.

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 tool has zero parameters and 100% schema description coverage, so the description has no parameter semantics to explain. The baseline of 4 for a zero-parameter tool is appropriate.

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 and resource: 'Re-fetch status, telemetry and location from Toyota's cloud.' It also distinguishes itself from the getter siblings by noting that answers refresh themselves as the car is driven, and from wake_vehicle by explicitly saying it never wakes the car.

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 explicit when-to-use guidance: 'Use only when the user just parked and wants the very latest position or status.' It also explains when not to use it, calling it 'Rarely needed' because the car pushes data at ignition-off and answers self-refresh while driving.

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?

The description discloses an important behavioral trait—'remember it'—indicating that the selection persists and affects subsequent tool calls. Annotations already cover idempotency and non-destructiveness, so the description adds useful statefulness context without contradicting them.

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 short sentences with no wasted words. The core behavior is front-loaded, and the usage condition follows naturally, making it easy for an agent to parse quickly.

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 selection tool with one fully documented parameter, an output schema, and clear behavioral guidance, the description is complete. An agent knows what the tool does, when to use it, and how the selection affects other tools.

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 fully documents the single 'vin' parameter, including the option to use the last four characters from toyota_list_vehicles. The description does not add parameter-level detail, but none is needed given 100% schema coverage.

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: 'Point every other tool at one vehicle of the account, and remember it.' This clearly identifies the tool as a selection/context-switching operation and differentiates it from the many getter/action sibling tools.

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 says when to use it: 'Use when the account holds several vehicles, or to switch between them.' It does not mention when not to use it, but the guidance is clear enough for deciding when this tool is relevant.

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 annotations, the description adds important behavioral context: the horn is audible to everyone around the car, it is a short signal, and success is verified by the car reporting back. This goes beyond the idempotent/non-destructive hints already present.

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 concise sentences carry all essential information: action, side effect, preferred alternative, and verification. There is no fluff or repetition.

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 tool with one optional parameter, full schema coverage, output schema, and supporting annotations, the description is complete. It covers purpose, usage criteria, behavioral consequences, and confirmation of the action.

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 100% and the single 'confirm' parameter is already clearly documented in the schema, including the preview-versus-send behavior. The tool description adds no additional parameter-level information, so the baseline of 3 is appropriate.

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 and resource: 'Sound a short horn signal to locate the car.' It also explicitly distinguishes this from toyota_find_car, making the tool's role clear among siblings.

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 gives explicit guidance: 'prefer toyota_find_car unless the user asked for sound.' This tells an agent when to choose this tool versus the sibling alternative.

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 (destructiveHint=true, idempotentHint=true), the description discloses concrete behavioral consequences: starting a hybrid runs the engine, so it must never be used in an enclosed space. It also clarifies the confirm flag's role as a preview-vs-send mechanism. This is high-value 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 compact and front-loaded: purpose first, then the critical safety warning, then confirmation usage. Every sentence earns its place without redundant 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?

Given the output schema exists and parameters are fully described in the input schema, the description covers the remaining essential context: the preset behavior, the hybrid engine warning, and the confirm/preview semantics. 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?

Schema description coverage is 100%, so the schema already fully documents confirm and temperature_celsius. The description adds useful context about the saved preset and preview behavior, but it does not need to compensate for missing parameter information.

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: "Start remote pre-conditioning with the saved preset (duration, defrosters, seats)." This is clearer than the title alone and distinguishes the tool from siblings like toyota_stop_climate and toyota_get_climate by naming exactly what starting climate does.

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 gives clear when-to-use guidance: "Only when the user explicitly asked; preview with confirm=false unless the user already confirmed." It also warns against use in enclosed spaces for hybrids. It does not explicitly name alternative tools, but the context and safety conditions are sufficient for selection.

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 cover read-only/write/destructive/idempotent status. The description adds transparency beyond annotations by noting the stop command is followed by a verification against the reported climate state, and that confirm=false previews instead of sending. No contradiction 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.

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

Two short sentences front-load the core action, then give the essential safety guard. 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?

For a one-optional-parameter command with rich annotations and an output schema, the description is complete: it covers what happens, the verification behavior, and when it should be invoked. There is no missing information an agent would need to call it correctly.

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 100% and the confirm parameter is fully explained in the schema. The description's mention of preview with confirm=false reinforces that semantics but adds no new parameter meaning beyond the baseline.

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 ('Stop') and resource ('remote pre-conditioning'), and adds a verification step that clarifies its effect. This distinguishes it immediately from siblings like toyota_start_climate and toyota_get_climate.

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 an explicit condition—only when the user explicitly asked—and gives a concrete fallback: preview with confirm=false when in doubt. This is clear when-to-use guidance that reduces the risk of unintended commands.

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 indicate this is mutating (readOnlyHint=false), destructive (destructiveHint=true), and idempotent (idempotentHint=true). The description adds beyond that: post-action verification against reported car state, an explicit security gate, and preview-vs-send behavior that is not available from annotations alone.

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 tight sentences front-load the action and verification, then add the security and confirmation guidance. Every sentence earns its place with no filler or repetition of schema data.

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 tool with an existing output schema, the description covers what the tool does, when it is permitted, and how to handle confirmation. The sibling list makes the intended action unambiguous, and no critical usage context 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?

Schema coverage is 100%, so the baseline is 3. The description adds a meaningful policy on top of the schema: preview with confirm=false unless the user already confirmed. It does not fully restate the schema but reinforces the decision rule, which is helpful for correct invocation.

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 clear action ('Unlock the doors') and adds a verification step, making it distinct from sibling tools like toyota_lock_doors and toyota_unlock_trunk. The verb and resource are specific and immediately recognizable.

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 says this is security-sensitive, only to be used when the user explicitly asked in the conversation, and never on the model's own initiative. It also gives concrete preview guidance: use confirm=false unless the user has already confirmed. This is model-actionable usage context.

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 (readOnlyHint=false, destructiveHint=true), the description adds meaningful behavior: it unlocks only the trunk, leaves doors locked, verifies against the car's reported state, and defaults to preview mode. This exceeds the bare annotation signal and helps the agent understand side effects.

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 compact sentences carry all essential information with no filler. The tool's purpose, safety constraint, and usage pattern are front-loaded 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?

For a low-complexity tool with one optional parameter, full schema coverage, annotations, and an output schema, the description is complete. It covers what the tool does, when to use it, and how the confirm parameter should be handled.

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 100%, so the schema already documents confirm. The description adds a decision rule beyond the schema: preview with confirm=false unless the user already confirmed. This enriches the parameter's meaning and usage context.

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 identifies a specific action and resource: 'Unlock the trunk only.' It also differentiates from siblings like toyota_unlock_doors by noting 'doors stay locked,' and the verb 'unlock' distinguishes it from toyota_lock_trunk.

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 gives clear invocation guidance: only on the user's explicit request, and with confirm=false as a preview unless the user has already confirmed. It does not explicitly name sibling alternatives like toyota_lock_trunk, but the context is sufficient for choosing when to call this tool.

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?

The description discloses meaningful behavioral context beyond the annotations: it sends a wake request, consumes 12V battery and cellular time, and provides current state rather than cached parked state. This aligns with readOnlyHint=false and idempotentHint=true, with no 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 three sentences with no filler: it front-loads the main action, then explains the limitation of passive reads, and finally gives cost and 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?

Given there are no parameters and an output schema exists, the description covers everything an agent needs: what the tool does, why it differs from passive reads, the cost, and when to invoke it. 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?

The tool has zero parameters and 100% schema coverage, so parameter semantics are trivially satisfied and the description does not need to compensate. The baseline for zero-parameter tools is 4.

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: ask the car to report its current state and re-read doors and climate. It also distinguishes itself from passive reads that only see parked data, making its purpose clear among many get_* sibling tools.

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 gives explicit guidance on when to use the tool ('when the user needs the state as of now') and when not to use it ('not routinely'). It contrasts with passive reads, but does not name a specific alternative sibling such as toyota_refresh_data, so the guidance is categorical rather than tool-specific.

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