Fuel, range and battery

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.