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

The readOnlyHint/openWorldHint annotations already establish the safety profile, so the bar is lower. The description usefully contributes the status vocabulary (pending, success, failed, timeout), which tells the agent what a non-terminal result looks like, but says nothing about polling cadence, whether terminal states are stable, or how long results are retained.

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 compact sentence with the action and the result states front-loaded in parentheses. Nothing is redundant and nothing needs to be cut.

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?

An output schema exists, so return values need not be spelled out, and the parameters are fully documented in the schema. The only gap is operational guidance about polling/re-checking after a pending result, which is minor for this tool's complexity.

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% — action_id is documented as coming from a prior command and vehicle notes the single-vehicle default — so the schema does the heavy lifting. The description adds no parameter meaning beyond that, making the baseline 3 correct.

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 (check) and resource (status of an earlier remote command), and enumerates the possible outcomes so the agent knows the shape of the answer. It is distinguishable from data-retrieval siblings like get_vehicle_status, though it never explicitly contrasts itself with 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 phrase "an earlier remote command" implies the sequencing context — call this after issuing a command — but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferable rather than stated.

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 openWorldHint=true, so the safety profile is covered. The description usefully adds what the payload contains (energy split plus regenerated energy and distance) and a regional availability caveat, but says nothing about retention limits or granularity boundaries.

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 with the energy breakdown front-loaded and the applicability caveat last. No filler; the trailing fragment ('EVs and PHEVs in some regions') is terse but earns its place as a scope qualifier.

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 annotations covering safety, 100% schema coverage on two params, and an output schema that already describes return values, the description supplies everything an agent needs to select and invoke it. Only the absence of sibling contrast keeps it from a 5.

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 only two parameters (days, vehicle), so the schema fully documents them. The description's 'daily' wording loosely implies the day-bucketing behavior of 'days' but adds no format or default guidance beyond what the schema already provides.

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 and resource ('Get daily electric energy use') and enumerates the exact breakdown returned (driving, climate, electronics, battery care, regenerated energy, distance). This is far more informative than the title, though it never names or contrasts with siblings like get_trips, which is the nearest overlapping 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?

No explicit when-to-use statement or alternatives are named. Usage is only implied by the 'daily' framing, and the 'EVs and PHEVs in some regions' clause acts as an applicability/availability caveat rather than 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the regional availability constraint, which is valuable context not in annotations, but doesn't describe pagination, rate limits, or output format.

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 front-load the core action and then the key constraint; no wasted words.

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 full output schema exists, return values needn't be explained. The tool is read-only with clear annotations. The regional caveat is important, but minor gaps like error behavior or result limits keep this from a 5.

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% with detailed parameter descriptions, so the schema already documents the date formats and vehicle parameter fully. The description only repeats 'day or month summary' without adding format syntax or other meaning.

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 and resource ('Get driving history: trips') and clearly delineates the two modes—day trips vs month summary—distinguishing it from siblings like get_vehicle_location or get_energy_usage.

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 regional support caveat ('Not every region supports this') is useful but there's no explicit guidance on when to use this vs alternatives like get_energy_usage; usage is implied by the purpose but not spelled out.

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 openWorldHint=true, so safety and external-dependency posture are covered. The description adds one genuine behavioral detail — that an address is only returned when geocoding is enabled — but says nothing about freshness, caching, or what happens for a moving vehicle.

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, front-loaded with the action, and the parenthetical clarifies the return rather than padding. Nothing wasted.

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?

An output schema exists, so return-value explanation is optional, yet the description helpfully summarizes the payload. With 100% schema coverage on the lone parameter and annotations covering the safety profile, the definition is essentially complete; only staleness/timing behavior is unaddressed.

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 'vehicle' parameter is fully documented in-schema (name/VIN/ID, optional for single-vehicle accounts). The description adds no parameter meaning beyond that, 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?

States a specific verb+resource ('Get where the car is parked') and even names the returned payload (latitude/longitude, address). It is clearly distinct from siblings like get_trips or get_energy_usage, though it never explicitly contrasts itself with any of 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?

Provides no when-to-use, when-not-to-use, or alternative-tool guidance. The mention of geocoding and single-vehicle accounts lives in the schema, not the description, so an agent gets no routing help here.

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 and openWorldHint, so safety is covered. The description adds genuinely useful non-structured behavior: this returns cached last-reported data and will not wake the vehicle, which matters for battery drain and latency. It does not mention data staleness or freshness bounds, which would complete the picture.

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, front-loaded with the core action and the key behavioral caveat. The long field enumeration is somewhat redundant given an output schema exists, but it still serves as a quick scope preview.

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 covering return values and 100% schema coverage on the sole parameter, the description needs only to explain scope and behavior — which it does. The only gap is guidance on how stale 'last reported' data may be and when to escalate to a refresh.

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% and the single 'vehicle' parameter is fully documented in-schema, including the 'optional if one vehicle' rule. The description adds nothing about the parameter, which is fine given the schema does the work — baseline 3.

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 and resource ('Get the car's last reported state') and enumerates the domains covered, so the agent knows exactly what comes back. The phrase 'last reported state' implicitly separates it from refresh_vehicle_status, which is the sibling that would fetch fresh data.

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?

'Does not wake the car' establishes the key selection criterion against refresh_vehicle_status (the non-waking, cached read). It stops short of naming that sibling explicitly, so the routing requires one small inference rather than being stated outright.

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 openWorldHint=true, so the safety profile is covered. The description adds only 'on the account', a small scoping detail, and says nothing about pagination, account auth, or result ordering; with an output schema present, return details are excused, so a 3 is fair.

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?

A single, front-loaded sentence with no filler or redundancy. It is efficiently sized for a simple list tool, though it is so terse that it forgoes any structural elaboration.

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, full annotation coverage, and no parameters, the description is nearly sufficient, but it omits any relationship to the sibling tools that all consume vehicle identities. For an entry-point listing tool in a seven-tool family, that missing context is a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies. There is no parameter information the description could usefully add beyond what the empty schema already conveys.

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 (List) and resource (vehicles) with scope ('on the account'), so an agent immediately knows this enumerates vehicles. However, it offers no explicit differentiation from sibling tools like get_vehicle_status or get_vehicle_location, leaving the agent to infer that this is the enumeration entry point.

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?

Usage is only implied: an agent can reasonably guess this is the discovery tool to run before the per-vehicle getters, but the description never says when to prefer it or how it relates to the six sibling getters. No exclusions or prerequisites are stated.

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 safety (readOnlyHint, idempotentHint) and open-world reach, but the description adds real context they don't: the call physically wakes the car, drains 12V battery, consumes API quota, and is rate limited. That is exactly the side-effect/cost disclosure an agent needs before calling a 'read' that has real-world impact.

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: the first states the action and the output analogy, the second states the cost constraint. No filler, and the essential behavior 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?

An output schema exists, so return values need no explanation, and the description defers to get_vehicle_status for shape. The cost/rate-limit disclosure is present; only a clearer when-to-use rule against the sibling reads 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 is a single optional parameter and the schema documents it at 100% coverage ('Vehicle name, VIN or ID. Optional if the account has one vehicle'), so the schema carries the full burden. The description adds nothing about the vehicle argument, so the high-coverage baseline of 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?

Specific verb chain (wake, fetch, return) on a clear resource, and it names the sibling get_vehicle_status as the shape of the result, which implicitly tells the agent this is the live-fetch counterpart to a cached read. It stops short of explicitly contrasting the two, so the distinction from get_vehicle_status is inferable rather than stated.

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 rate-limit and battery cost statements imply 'use sparingly, only when fresh state is genuinely needed', which is useful implied guidance. However, it never states when to prefer this over get_vehicle_status or the other read siblings, so the routing decision is left to the agent.

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