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

Annotations already cover readOnly and idempotent, so the bar is lower; the description still adds real value by disclosing that the call does not wake a sleeping vehicle, which is a non-obvious side-effect trait not encoded in any structured field. It stops short of saying what happens if the car is asleep and unreachable.

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, zero filler, with the return payload front-loaded and the wake caveat as a trailing qualifier. Nothing to trim.

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 shape needn't be described, and the description still previews the payload. For a zero-required-param read tool with full annotation and schema coverage, the only missing piece is behavior when the vehicle is asleep or offline.

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 vin parameter is fully documented in-schema, including the 'omit when the account has one car' guidance. The description adds nothing about the parameter, 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?

Names the specific resource (climate readings) and enumerates exactly what comes back: inside/outside temperature in Celsius plus climate on/off. That is concrete enough to distinguish it from tesla_get_status or tesla_get_odometer, though it never uses an explicit verb like 'get' and doesn't state the car association directly.

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 clause 'Does not wake the car' implicitly tells the agent to prefer this over tesla_wake_and_refresh when the vehicle is asleep, but that inference is left to the reader. It never explicitly names tesla_wake_and_refresh or tesla_get_status as alternatives, nor states when this tool is insufficient.

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 the safety profile (readOnlyHint, idempotentHint), so the bar is lower, and the description still adds two real behavioral facts: it does not wake the vehicle, and the distance figure comes from local snapshots (implying possible staleness). It does not state how fresh those snapshots are or what happens when no snapshot 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?

Two short sentences, zero filler, with the core capability stated first and the wake behavior as a secondary 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?

An output schema exists, so return-shape explanation is unnecessary, and the description covers both the returned metrics and the non-waking behavior. It could still note snapshot freshness or the no-snapshot fallback, but it is sufficient to invoke 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 both vin and period are already documented, including the accepted period values. The description only echoes 'over a period' without adding format or default behavior beyond the schema, 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?

Names the specific resource returned (odometer in miles plus distance over a period), which an agent can distinguish from status/climate/software siblings. Units are given explicitly. It lacks a verb and does not explicitly contrast with the closest sibling (tesla_usage or tesla_query_history), so it stops short of a 5.

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' implies this is the non-intrusive read path versus tesla_wake_and_refresh, but the description never states when to choose this over tesla_get_status or tesla_usage. Usage is inferable rather than explicit.

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 establish read-only, idempotent, and open-world behavior, while the description adds meaningful context: it does not wake the car and missing fields indicate firmware did not return them. It does not cover auth, rate limits, or error behavior, but it adds useful behavioral detail beyond 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 and front-loaded, with the main purpose in the first sentence and useful caveats after it. Every sentence adds information without 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 simple read-only tool with an output schema, one optional parameter, and safety annotations, the description is largely complete. The main remaining gap is that it does not clarify when to prefer this tool over tesla_get_status for broader vehicle information.

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 100% description coverage and fully documents the optional vin parameter. The description adds no parameter-specific details, so the schema appropriately carries parameter semantics.

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 specific resource and return focus: installed software version and pending update status. It also distinguishes itself somewhat from wake-related tools by saying it does not wake the car, though it does not explicitly position itself against tesla_get_status.

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 "Does not wake the car" implies a useful context for querying software state without waking the vehicle. However, there is no explicit when-to-use guidance or named alternative such as tesla_get_status for broader vehicle state.

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, idempotent, and open-world behavior, so the description wisely adds operational context: live versus cached responses and the fact that the call does not wake the vehicle. It also specifies miles as the distance unit returned by the Fleet API.

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 and front-loaded with the returned status fields. Each sentence adds useful information: data freshness, distance units, and the non-waking behavior.

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 available output schema, rich annotations, and fully documented single parameter, the description provides everything needed for correct invocation. It covers status contents, freshness semantics, units, and wake behavior without redundant return-value 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?

Schema description coverage is 100%, and the optional vin parameter is fully documented in the schema as a vehicle name or masked VIN that can be omitted for single-car accounts. The description adds no parameter-specific meaning beyond the schema, 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 identifies the resource contents: battery, range, charging, and lock state. It is specific enough to distinguish this status tool from siblings like tesla_get_climate, tesla_get_odometer, and tesla_get_software, though it does not explicitly name those alternatives.

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 note that data is live when the car is online and otherwise cached, plus the statement that it does not wake the car, gives useful contextual guidance. However, it does not explicitly say when to use this versus tesla_wake_and_refresh or when cached data is insufficient.

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 the read-only/idempotent safety profile, but the description adds two non-obvious behavioral facts: VINs are masked in the response, and the call avoids the side effect of waking the vehicle. That is valuable context beyond structured fields, though pagination or account-permission behavior is unaddressed.

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 with zero waste. The purpose comes first, and the two caveats (masked VINs, no wake) follow immediately.

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 and no parameters, the description carries little burden and covers the key non-obvious behaviors. Only the absence of any note on multi-vehicle/account-scoping ambiguity 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond confirming the call is unscoped.

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 ('List vehicles on the Tesla account'), which is clearly distinguishable from siblings like tesla_get_status or tesla_get_odometer. It does not explicitly name a sibling to differentiate against, keeping it just below a 5.

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?

'This does not wake the car' implicitly tells the agent to prefer this call over tesla_wake_and_refresh when it just wants a cheap read. It gives a clear usage context but states no explicit exclusions or prerequisites.

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 establish read-only, idempotent, non-open-world behavior. The description adds meaningful context beyond that: it uses a local snapshot database and avoids calling Tesla or waking the car, which is important operational behavior. It does not describe data freshness or staleness, but it adds real value over 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 short sentences, front-loaded with the data source and followed by the key operational constraint. There is no wasted text.

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 tool has a complete input schema and an output schema, so return values need not be explained. The description covers the source and non-wake behavior, but it omits any note on snapshot freshness or data lag, which would help an agent decide when local history is appropriate.

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 documents metric, dates, bucket, and vin semantics. The description does not add parameter-level meaning beyond the schema, which is acceptable given full 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 identifies the resource as a time series from the local snapshot database and distinguishes it from live/wake tools by saying it does not call Tesla or wake the car. It is clear enough for an agent to recognize historical local data retrieval, though it does not explicitly use a query/retrieve verb.

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 'Does not call Tesla or wake the car' strongly implies when this tool is preferable: when avoiding vehicle wake-up or live API calls. However, it gives no explicit alternatives or when-not guidance versus siblings like tesla_usage or tesla_get_odometer.

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 substantial behavioral context beyond the read-only annotations: it notes that local reports do not wake the car, specifies data windows for weekly_mileage and range_trend, defines the low_charge alert condition and staleness caveat, and clarifies that charging_summary only calls Tesla when opted in. This is exactly the kind of operational detail an agent needs.

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 tightly structured: a two-sentence summary up front, followed by one focused line per report type. There is no redundant filler, and the most important behavioral note (local reports do not wake the car) 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?

Given the tool's moderate complexity, the 100% schema coverage, and the presence of an output schema, the description provides everything an agent needs: the report types, their data windows, external-call behavior, and staleness handling. No important call-selection 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 schema already documents both parameters. The description goes further by explaining what each type value produces (weekly_mileage, range_trend, charging_summary, low_charge), adding meaningful semantics beyond the schema's short type list.

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 produces a ready-to-read summary and enumerates the four report types, which is a specific verb+resource. However, it does not explicitly name or contrast with sibling tools like tesla_query_history or tesla_get_odometer, leaving some differentiation implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through phrases like 'ready-to-read summary' and details each report type, but it never explicitly says when to choose this tool over alternatives such as tesla_query_history or tesla_get_odometer. The guidance is implicit rather than explicit.

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 readOnly, idempotent, and closed-world, so the bar is lowered. The description still adds two things beyond them: the reporting window ('this month') and the 'Local only' guarantee that no vehicle wake or network call occurs — exactly the side-effect detail an agent needs before calling a Tesla tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences, front-loaded with what is returned, with the operational constraint last. No 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?

An output schema exists, so return values need not be documented. What the tool reports, the time window, and the fact it stays local are all covered; only durability/scope of the recorded history is left unstated, which is minor for a zero-parameter read.

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?

Zero parameters, so the baseline of 4 applies. The description correctly implies no input is needed, consistent with 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 names the concrete payload (calls this month, estimated cost, wake budget), which is specific enough to tell it apart from the vehicle-data siblings like tesla_get_status or tesla_get_odometer. It lacks an explicit verb ('returns'/'shows'), but the resource and scope are 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?

'Local only' implicitly signals when to prefer this over siblings that touch the vehicle (tesla_wake_and_refresh, tesla_get_status), but no alternative is named and no explicit when/when-not condition is stated. Usage is inferable rather than guided.

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 real side effects — the wake is billed, it brings the car online, it is rate-limited to one wake per 30 minutes and three per 24 hours, plus a hard 3-per-minute cap — which is exactly the kind of state-changing, cost-incurring behavior readOnlyHint=true denies. The annotation profile directly conflicts with the described semantics.

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?

Action and snapshot outcome are front-loaded in the first clause, the confirm gate follows immediately, and the remaining sentences carry only non-obvious operational constraints (budget, hard cap, exclusivity). No filler sentences.

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?

Output schema exists so snapshot contents need no explanation, parameters are documented, and the rate-limit model is fully spelled out for a tool with side effects. The only remaining gap is guidance on when the car is already awake versus which read tool to use instead.

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 both parameters already carry the essential meaning (vin optional for single-car accounts, confirm must be true and is billed). The description's "Refuses unless confirm is true" reinforces the schema but adds no new syntax or edge-case detail beyond it, 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 two-step action ("Wake the car, then store a fresh snapshot") with a concrete resource, and explicitly claims exclusivity ("This is the only wake path"), which separates it from the passive getters like tesla_get_status and tesla_get_odometer in the sibling list.

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?

Clearly establishes the precondition ("Refuses unless confirm is true") and the routing rule that this is the only way to wake a vehicle, so an agent knows to use it when the car is asleep. It stops short of explicitly contrasting with tesla_get_status for the already-awake case, leaving a small inference gap.

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