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

With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the tool never returns raw tokens and hedges with 'looks valid,' suggesting a heuristic check. But it does not disclose whether the call is read-only, whether it refreshes the session, or whether any side effects occur.

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 filler. The core purpose is stated first, and the security-relevant constraint 'Never returns raw tokens' is a valuable second sentence. Every word 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?

For a zero-parameter status check with an output schema present, the description is mostly sufficient. It states what is checked and adds an important security constraint. It lacks explicit guidance on prerequisites, such as whether a session must already exist, but this is a minor gap given the tool's simplicity.

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 schema description coverage is 100%, so the baseline is 4. The description adds no parameter information, but none is needed because there is nothing 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 identifies the resource (a session) and the condition (whether it looks valid), and the auth_status name distinguishes it from the vehicle/trip/charge siblings. However, it lacks a direct imperative verb like 'Checks' or 'Validates,' so the phrasing is a noun clause rather than a precise action statement.

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 this tool is used to determine if a session is valid, and the warning 'Never returns raw tokens' hints that it should not be used for token retrieval. However, it never explicitly states when to use it versus the sibling tools or excludes alternatives, leaving the usage context to inference.

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?

With no annotations present, the description carries the full behavioral burden. It usefully discloses that the result is empty when not charging, preventing misinterpretation of a no-active-session state. It does not mention auth, rate limits, or read-only semantics, but for a zero-parameter current-state getter this is sufficient.

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 two short sentences with no filler. The main resource is front-loaded, and the important conditional behavior ('Empty when not charging') is stated separately and clearly.

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 tool with an output schema available, the description covers the key edge case and return semantics. It is slightly terse about what 'current' refers to and does not cross-reference sibling tools, but nothing essential is missing for a simple read operation.

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 an empty object, so there is nothing for the description to add. The baseline for a parameterless tool 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 clearly identifies the resource ('current charge session') and the conditional empty state, which distinguishes it from siblings like evolute_vehicles or evolute_trips. It lacks an explicit verb such as 'retrieve' or 'list,' but the intent is unambiguous for a simple getter.

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 when the tool is relevant: use it to inspect the current charge session, knowing it will be empty when not charging. However, it does not explicitly contrast it with sibling tools such as evolute_status or state when not to use it.

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?

With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that coordinates are hidden unless include_pii is true, which is important privacy behavior not apparent from the schema. It does not disclose authentication needs, side effects, or read-only guarantees, but 'telemetry' implies a read operation and the PII note adds meaningful behavioral 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 concise: two sentences, no filler, and the core resource and telemetry domains are front-loaded. The PII behavior is placed second, which is appropriate. It could have used an active verb for slightly better readability, but it is otherwise well structured.

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?

Because an output schema exists, return-value details do not need to be repeated. The description covers the main domain, default/given vehicle behavior, and the key PII nuance. It still lacks explicit usage boundaries and fuller car_id semantics, so it is adequate but not complete for an agent that has no other context.

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 0%, so the description must compensate. It explicitly explains include_pii by tying it to coordinate visibility, and 'default (or given) vehicle' indirectly hints at car_id. However, car_id is never named nor its selection semantics fully described, leaving a required-for-advanced-use parameter underspecified.

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 the resource (vehicle telemetry) and enumerates the covered domains: charge, climate, doors, online. It also clarifies the default-vs-given vehicle behavior and the PII gating, which helps distinguish this from simpler siblings. However, it lacks an explicit verb such as 'retrieves' and does not explicitly contrast with evolute_charge, so it is clear but not fully differentiated.

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 when to use the tool ('default or given vehicle') but gives no explicit guidance about when to choose evolute_status over siblings like evolute_charge or evolute_vehicles. There are no when-to-use rules, exclusions, or alternative routing. An agent must infer the intended scope from the listed telemetry categories.

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?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: track points are gated by include_track, addresses by include_pii, and start_time maps to segmentStartTime. However, it does not disclose whether the operation is read-only, what happens when optional flags are false, or any other behavioral constraints.

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 very short and every clause adds some information; there is no filler. The telegraphic style somewhat reduces readability, but the content is front-loaded with "One trip" and then compactly lists the key conditional behaviors.

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-format documentation is not the main gap. Still, the description omits a clear primary action, fails to explain required travel_id, and gives no guidance on how this tool relates to evolute_trips. An agent would struggle to invoke this correctly without additional context.

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 0%, so the description must compensate. It clarifies the meaning of three parameters (include_track, include_pii, and start_time mapping to segmentStartTime), but two parameters remain unexplained, including the required travel_id. This is partial compensation, not complete.

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 begins with "One trip," which largely restates the tool name rather than stating a clear action such as retrieve or list. It hints at scoping (single trip) and conditional fields, but it never says what the tool actually does with the trip. The implied distinction from evolute_trips is not made explicit.

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 parameter-level conditions ("Track points only if include_track=true", "Addresses only if include_pii=true") but no guidance on when to choose evolute_trip over siblings like evolute_trips or evolute_status. There is no explicit tool-selection guidance, and no mention of prerequisites such as where travel_id comes from.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does meaningfully disclose that addresses and tracks are omitted and that distance is a raw integer with unknown units, which are valuable caveats not visible in the schema. It does not mention auth or rate limits, but for a read-like trip listing this is a strong level of transparency.

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 concise sentences with no fluff. It front-loads the core purpose and then states two important caveats, each earning 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?

The description covers the main purpose and key output caveats, and the presence of an output schema reduces the need to describe return values. However, it does not clarify expected values for sort_by, the effect of include_pii, or pagination behavior, leaving an agent to guess for important invocation choices.

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 0%, so the description must compensate for parameter documentation. It only clarifies car_id through 'default (or given) vehicle' and says nothing about limit, offset, sort_by, sort_dir, or include_pii semantics. This is insufficient given the complete lack of schema-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies trips as the resource and distinguishes this from the singular evolute_trip sibling by focusing on 'Recent trips' and vehicle selection. It lacks an explicit verb like 'list' or 'retrieve,' but the intent is still readily inferable.

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 guidance is given about when to use this tool versus alternatives like evolute_trip or evolute_vehicles. The plural 'trips' hints at a listing operation, but there is no stated condition, prerequisite, or exclusion to help the agent choose 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses that VIN/IMEI are masked unless include_pii is true, which is valuable. However, it does not mention pagination, auth requirements, or any other operational behavior, leaving some gaps.

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 with no filler. The primary action is front-loaded, and the masking caveat follows naturally. Every word 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?

For a simple list tool with one optional boolean and an existing output schema, the description covers the essentials: what the tool does and the key parameter behavior. It lacks explicit scope or pagination details, but these are less critical given the output schema and simple nature of the operation.

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 0%, so the description must compensate. The masking note directly explains the effect of include_pii: setting it to true reveals VIN/IMEI. This adds essential meaning beyond the bare boolean schema, though it could have explicitly stated 'set include_pii=true'.

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 action and resource: 'List vehicles.' It also adds a relevant behavior about masking VIN/IMEI. It does not explicitly differentiate it from sibling tools, but the sibling names clearly suggest different resources, so the purpose is not ambiguous.

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?

There is no guidance on when to use this tool versus alternatives such as evolute_status or evolute_trips. The phrase 'List vehicles' implies its use, but the description provides no explicit context, exclusions, or conditions for choosing it over siblings.

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