TuneWorks

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds genuinely new behavior: the operation is atomic and additive, leaving existing categories and items untouched, which directly reassures the caller about mutation scope. It omits what happens with duplicate category names or what permission level 'editable' requires.

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; the scope constraint appears before the non-replacement guarantee, in the order an agent needs 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?

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. Still, for a three-parameter mutation tool with zero schema descriptions, the definition should clarify sortOrder's role and duplicate-name handling to be fully sufficient.

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 carry parameter meaning, and it supplies only indirect hints: 'category' maps loosely to name, 'existing shop list' to listId. The third parameter, sortOrder, is never mentioned, nor are format, constraints, or default behavior, leaving most parameter semantics undocumented.

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 (add) and resource (one category) scoped to an existing editable shop list, and explicitly contrasts with replacement behavior. An agent can distinguish it from update_shop_list and reset_shop_list_items without opening a schema.

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 'existing editable shop list' communicates a prerequisite (the list must exist and be editable) and the 'without replacing' clause implicitly contrasts with bulk-update/reset siblings. It does not name an explicit alternative tool or state when this would be the wrong choice, so it stops short of full 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 non-destructive, non-read-only, closed-world semantics. The description adds genuine beyond-annotation context: the operation is atomic, does not replace existing items, and has a side effect of creating a missing category — exactly the kind of disclosure an agent needs before mutating a list.

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 tightly written sentences with no filler; the append-not-replace semantics come first, followed by the conditional side effect. Front-loaded and complete.

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 mutation semantics are covered. But with 6 params and 17% schema coverage, half the parameters (quantity, sortOrder, status, listId, label constraints) get no semantic help anywhere, which is a real gap for a write tool.

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 only 17% (only `section` is documented), so the description carries real compensating weight: it explains that the category is auto-created if absent, giving `section` behavioral meaning. However, `quantity`, `sortOrder`, and `status` remain entirely undocumented in both schema and description.

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 (add) and resource (item to a shop list) plus a distinguishing scope note ('one item... without replacing existing items'), which separates it from bulk tools like update_shop_list. It never names the closest siblings (add_shop_list_category, update_shop_list_item) explicitly, 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?

'existing editable shop list' implies the precondition that the list must exist and be mutable, and the category-creation note hints at how this differs from add_shop_list_category. But there is no explicit when-to-use/when-not or named alternative, leaving the agent to infer the 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 declare readOnlyHint, destructiveHint=false, and openWorldHint=false; the description's one added fact is that no TuneWorks authentication or account data is required, which is genuinely useful beyond the structured hints. It does not disclose what the interpretation actually produces (camber/pressure conclusions) or how the threshold parameters change the output.

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 front-loaded sentence with no filler or redundancy. It is under-specified rather than bloated, which is a completeness problem, not a verbosity one.

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 six-parameter analytical tool with nested objects, five undocumented parameters, and no explanation of the interpretation method, the definition is far too thin. An output schema exists so return values need not be described, but the agent still cannot predict how the thresholds and camber spreads affect results.

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 only 17%, so the description carries the burden of explaining the six parameters — yet it explains none of them. targetTemp, tempWindow, frontCamberSpread, rearCamberSpread, and unit are left entirely undocumented, and the readings object is only echoed from the 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?

States a specific verb (interprets) and resource (inside/middle/outside tire temperature readings), which is more precise than the title alone. It does not distinguish itself from nearby siblings such as calculate_tire_pressure_adjustment or diagnose_handling_issue, so an agent cannot tell from the text which analysis path to pick.

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 never says when to reach for this tool, what inputs it expects, or which sibling to use instead for pressure vs. handling diagnostics. The only usage-adjacent signal is the no-auth remark, which is a constraint rather than 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=false and destructiveHint=true, so the description's job is to add context beyond that. 'Never hard-deletes data' usefully clarifies that the archive is reversible, but the confirmation requirement largely restates the required boolean 'confirmed' parameter, and the description never says what an archived item looks like afterward (hidden from list_maintenance, restorable, etc.).

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-loaded with the action and followed by the safety constraint. No filler, though 'connected user maintenance item' is slightly vague phrasing.

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 explained, but for a mutation tool with fully undocumented parameters the description should say what identifier combination targets the item and what the post-archive state is. It is adequate but leaves real gaps.

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% for all three parameters. The description only indirectly covers 'confirmed' via 'requires explicit user confirmation' and says nothing about what vehicleId and trackerId identify or how they relate to each other.

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: 'Archive a connected user maintenance item.' An agent can tell it apart from the delete_* siblings and from update_maintenance, though the odd qualifier 'connected user' is never explained.

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 'Requires explicit user confirmation' line gives a precondition, but there is no guidance on when to archive versus update_maintenance, complete_maintenance, or the delete_* tools in the sibling set. Usage is only implied by the verb.

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 destructiveHint=true and readOnlyHint=false, so the description's job is to refine that picture — and it does, stating the operation is a soft archive that 'never hard-deletes data' and that explicit user confirmation is required. What is left out is what happens to an archived session downstream (visibility in list_sessions, whether it can be restored, who may archive).

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 padding, with the object of the operation front-loaded and the safety constraint immediately after. Every clause carries 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?

An output schema exists so return values need not be described, and the confirmation requirement plus non-destructive behavior are covered. Still missing for a mutating, destructive-flagged tool: reversibility/restore path, permission requirements, and effect on related data, which leaves an agent under-informed before acting.

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 both parameters rely on the description. 'Explicit user confirmation' maps the `confirmed` boolean to a meaningful semantic, but `sessionId` is only implied by 'a connected user driving session' with no format or sourcing hint. Partial compensation for the coverage gap.

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 ('Archive a connected user driving session'), making clear this targets a session object rather than a vehicle, setup, or shop list. It does not explicitly contrast with the adjacent siblings like update_session or delete_* tools, so it falls short of full sibling differentiation.

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 'Requires explicit user confirmation' gives a real precondition for invoking it, which is useful for an agent. However, there is no guidance on when to archive versus update a session, or when archiving is preferable to leaving the session active, and no mention of the alternative siblings.

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 declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating tool. The description adds valuable context beyond annotations: it archives 'all active revisions' and 'never hard-deletes data', clarifying the destructive hint is scoped to archiving rather than permanent deletion. It does not cover permissions or whether an archive can be undone, keeping it from a 5.

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 scope and confirmation requirement are front-loaded, and the non-hard-delete guarantee follows 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?

Given a simple two-parameter mutation tool with annotations and an output schema, the description covers purpose, mandatory confirmation, and the non-destructive nature of archiving. It omits setupId semantics, but the output schema handles return values and the annotations cover the safety profile. For this complexity level, it is nearly complete.

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 both undocumented parameters. It implies the need for user confirmation, which loosely maps to the 'confirmed' boolean, but it says nothing about 'setupId' or what value to supply. The agent must infer the primary identifier from the parameter name alone.

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: 'Archive all active revisions of a connected user setup.' It clearly distinguishes the setup resource from the many archive_* siblings that target maintenance, sessions, vehicles, and shop lists. An agent can identify the operation without opening the schema.

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 a key usage precondition: 'Requires explicit user confirmation.' That tells the agent a confirmation step is mandatory before calling. It does not explicitly name alternatives such as update_setup or explain when not to archive, so it falls short of full when/when-not 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 destructiveHint=true and readOnlyHint=false, so the description's job is to add what annotations cannot. It does that by characterizing the operation as a soft archive (list stops appearing in active lists) and imposing a user-confirmation gate, which is meaningful behavioral context beyond the hints. It stops short of stating reversibility or what happens to the list's items.

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, no filler, with the effect stated first and the prerequisite second. Every clause carries information an agent needs.

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 presence of an output schema relieves the description of explaining return values, and annotations cover the safety profile. Still, for a destructive mutation it omits recoverability (can an archived list be restored?), idempotency, and the identity/format of listId, leaving real gaps.

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 only 50% and the undescribed parameter is listId, which the description never mentions in any form (format, source, or how to obtain it). The confirmation sentence only echoes the already-documented 'confirmed' boolean in the schema, so the description adds little beyond structured data.

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 (Archive) and resource (connected user shop list) plus the observable effect: 'no longer appears in active lists,' which implicitly separates it from delete_shop_list. It does not explicitly name the delete sibling, so differentiation is inferential rather than 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 prerequisite 'Requires explicit user confirmation' is a real usage constraint that tells the agent to gate the call behind user consent. However, it never says when to pick this over delete_shop_list or update_shop_list, so the choice among the three siblings is left 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?

Annotations declare destructiveHint=true and readOnlyHint=false; the description adds the crucial qualifier that destruction is a TuneWorks soft delete and data is never hard-deleted, which meaningfully refines the destructive profile rather than contradicting it. It also discloses the confirmation requirement, though it does not say what happens to dependent objects or whether the action can be undone.

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 action and the soft-delete caveat front-loaded. Nothing repeats the title verbatim without adding 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description fills the important gap—soft delete plus required confirmation—but omits what archiving does to the vehicle's related records and whether the state is recoverable.

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% for both parameters, so the description must carry the load. 'Requires explicit user confirmation' effectively explains the `confirmed` boolean, but `vehicleId` is never mentioned, leaving half the parameters undocumented.

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 ('Archive a connected user vehicle') and qualifies the operation as a soft delete, which separates it from the archive_* siblings on maintenance/session/setup by object. It stops short of naming any sibling explicitly, so an agent still has to infer which archive target applies.

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 statement of when to archive versus when to use update_vehicle or a delete path, and no prerequisites beyond 'requires explicit user confirmation.' The agent gets a hint about confirmation but no routing guidance or exclusions.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered. The description adds useful behavior that the modification is canceled but retained in history and that explicit confirmation is required, but it does not explain reversibility, authorization needs, or what happens to related records.

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 core effect and followed by the confirmation requirement. There is 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?

The tool is simple and an output schema exists, so return values need not be explained. Still, the description leaves gaps around parameter semantics and explicit differentiation from delete_vehicle_modification, which matters given the rich set of archive/delete siblings.

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 should compensate for all three required parameters. It clarifies the confirmed parameter via 'Requires explicit confirmation' and implies modificationId through 'modification,' but it adds no meaningful detail about vehicleId or the ID formats/constraints.

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: mark a vehicle modification canceled. It also clarifies the outcome, that it remains in vehicle history, which helps distinguish archive from an outright delete, though it does not explicitly name delete_vehicle_modification as the 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 phrase 'so it remains in vehicle history' implies when to use this tool rather than deleting, and 'Requires explicit confirmation' states a precondition. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative among the many sibling tools.

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/non-destructive/closed-world, but the description adds genuinely new behavioral facts: no authentication required and no account data is read or saved. It also discloses a scope limitation (purely mechanical bias), which prevents over-trusting the output. It stops short of describing determinism or precision/rounding behavior.

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 tight sentences: purpose first, then operational properties, then limitations. No repetition of the title and no filler; every clause adds a distinct fact.

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, return values need no explanation, and the description covers what the tool computes, its data-access profile, and its modeling limits. The only minor gap is any note on input consistency (e.g., both axles in the same unit system), which the per-field schema largely handles.

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 units and semantics documented per field, so the schema carries the parameter burden. The description only echoes the categories of input (piston area, rotor size, pad friction) and says nothing about unit-system interaction or the exclusiveMinimum>0 constraints beyond what the schema states, so 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 ('Estimate') plus a precise resource ('front brake bias') and names the exact inputs that determine it (piston area, rotor size, pad friction). This cleanly separates it from siblings such as calculate_corner_balance or diagnose_handling_issue without needing to open any schema.

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 result is appropriate by listing what it does not model ('Tire grip, weight transfer, ABS, and balance bars still matter'), which hints the agent should reach for a handling/diagnostic sibling in those cases. However, it never explicitly names an alternative or states a when-not-to-use condition, leaving routing 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema behavior: no authentication, no account data read or written, and the measurement-state precondition that affects result validity.

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 sentences, front-loaded with the core capability, then side-effect disclosure, then the measurement precondition. Every sentence carries information, though the middle sentence slightly overlaps with what the read-only annotations already convey.

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 explained, and annotations cover the safety profile. The description supplies the auth/data-access behavior and input preconditions an agent needs, leaving only minor gaps like input ordering or unit consistency reminders.

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 each pad and the unitSystem enum are already fully documented, establishing the baseline of 3. The description adds only the 'four scale pads' framing and a reminder that measurement conditions matter, which is helpful but does not add per-parameter detail beyond the 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?

States a specific verb ('Calculate') and the exact outputs (cross weight, left/right balance, front/rear split) plus the input source (four scale pads). This clearly separates it from sibling calculators such as calculate_brake_bias or calculate_spring_wheel_rate without opening any schema.

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?

Gives a clear usage context ('Calculates from measured inputs without authentication and does not read or save account data') and even a precondition ('measure the car in the same state you drive it'). It stops short of naming when to prefer a sibling tool or when not to use it, so it falls just below the explicit-alternatives bar.

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, destructiveHint=false, and openWorldHint=false; the description reinforces this with "without authentication or account-data access" and adds a genuinely new behavioral caveat, "Source ethanol contents are measured values" (i.e., E85 is not assumed to be exactly 85%). It does not discuss rounding, precision, or infeasible-blend handling, so it is good but not exhaustive.

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 sentences, front-loaded with purpose and ending with the mode-requirement table; essentially no filler. The mode clause is a dense run-on list, but every item carries information an agent needs, so the density is justified rather than wasteful.

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 the safety profile and an output schema covering return values, the description only needs to cover inputs and modes, which it largely does. The remaining gap is conceptual: it never explains what correction mode actually computes versus existing mode, which matters for a 9-parameter calculator.

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 78% and the schema descriptions are thin (unit or range only), so the description earns credit for supplying the conditional requirement logic that a flat schema cannot express, plus the reminder that percentages are 0–100 and all volumes share volumeUnit. It does not clarify that targetEthanol, highFuelEthanol, and pumpGasEthanol are always required regardless of mode.

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+resource ("Calculates an ethanol blend") and immediately enumerates the four supported scenarios (fresh tank, existing fuel, correction, ratio), which lets an agent distinguish this from nearby calculators like calculate_race_fuel_and_weight. It stops short of naming any sibling tool as the wrong choice, 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?

It gives concrete per-mode entry conditions ("Fresh mode requires finalVolume; existing mode requires finalVolume, currentVolume, and currentEthanol..."), which is real routing guidance for picking a mode. What it omits is the semantic distinction between "existing" and "correct" modes, so an agent may still hesitate between those two.

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, openWorldHint=false and destructiveHint=false, so the low-level safety profile is covered; the description goes beyond them by stating the calculation needs no authentication and does not read or save account data, plus flagging that the output is an estimate that should be confirmed against tuner/fuel-pressure data. It stops short of describing determinism assumptions (e.g. BSFC basis) or output shape, so it is not a 5.

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 the core purpose front-loaded and no filler. The middle sentence about authentication and account data is slightly boilerplate for a pure calculation but is short enough to earn 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?

With an output schema present, return values need not be described, and all five required parameters carry schema descriptions with units and bounds. The description supplies purpose, the calculation's side-effect-free nature, and an accuracy caveat, leaving nothing an agent needs in order 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?

Schema description coverage is 100%, so every parameter including the fuel enum and numeric bounds is already documented and the baseline is 3. The description restates four of the five inputs but never explains the role of the required 'current' (current injector size in cc/min), which is the least self-evident parameter and would have been the highest-value addition.

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 ('Estimate injector size') and enumerates the driving inputs (horsepower, fuel type, injector count, duty cycle), so an agent can tell it apart from sibling calculators like calculate_ethanol_blend or calculate_race_fuel_and_weight. It does not name any sibling or clarify how it differs from adjacent fuel/flow calculators, which keeps it 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?

There is no explicit when-to-use or when-not-to-use guidance and no reference to any alternative tool. The closest thing is the caveat 'This is a sizing estimate. Confirm with your tuner and fuel pressure data,' which is a caution about results, not a routing rule for tool 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 safety (readOnly, non-destructive, closed-world), and the description adds genuinely new behavioral context: it runs without authentication, touches no account data, and it warns that tire growth and converter/clutch slip cause real-world deviation from computed numbers. That caveat is the kind of nuance annotations cannot express.

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?

Four short sentences, front-loaded with the purpose, then scope, then input advice, then caveat. No filler, though the authentication/account-data sentence is somewhat boilerplate for a pure arithmetic tool.

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 all eight required parameters are schema-documented. The remaining gap is that the description never explains the required 'mode' parameter's role in driving the primary answer, which an agent must infer from the schema alone.

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 each field (rpm, speed, gear, finalDrive, tireDiameter, nextGear, mode, unitSystem) is already documented, so the schema does the heavy lifting. The only added meaning is the guidance to prefer a measured tire diameter, which is useful but narrow; the mode and unitSystem enums are left entirely to the 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 opens with a specific verb and outputs ('Check speed, RPM, and shift drop') plus the exact input drivers (tire size, final drive, gear ratio), which is enough to distinguish it from calculators like calculate_brake_bias or calculate_ethanol_blend. It does not explicitly name a sibling it is not, but the domain specificity is strong.

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 one concrete usage hint ('Use measured tire diameter when possible') and rules out account scope, but says nothing about when to choose this tool over neighboring calculators, nor how the required 'mode' enum (speed vs rpm) should be selected for a given question. Usage is implied rather than directed.

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, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds that it needs no authentication and touches no account data, which is useful but largely a restatement of read-only behavior; it says nothing about computation assumptions or edge cases beyond that.

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?

Purpose is front-loaded in the first sentence and the remaining sentences are short. The closing line about blaming setup is coaching rather than tool behavior and is the one sentence that doesn't fully earn 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?

An output schema exists, so return values needn't be described, and a pure read-only calculator needs little behavioral disclosure. What's slightly missing is any hint that exactly three sectors per lap are expected and that the theoretical lap is a best-sector composite.

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 every parameter is labeled with a unit (sec) and an exclusiveMinimum, so the schema carries the parameter burden. The description only adds that sectors can come from timing/video/logs — context, not syntax or semantics beyond the schema, so 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 and resource — comparing two laps/sector sets — plus the derived output (best theoretical lap). This is clearly distinguishable from the many other calculate_* siblings such as calculate_brake_bias or calculate_gear_ratio_speed.

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?

"Use sectors from timing, video, or data logs" tells the agent acceptable input sources, and "Compare similar conditions before blaming setup" gives a soft usage caveat. However, no alternative tool is named and no condition is given for when NOT to use it, so guidance remains implied 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false; the description adds genuinely new context: no authentication needed, no account data read or saved, the consumption assumption extended to formation and allowance laps, and that finish weight retains only the selected reserve. That is meaningful behavioral disclosure beyond the annotation flags.

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?

Four short sentences, front-loaded with purpose and followed by behavior, assumptions, and a caution. Each sentence carries information; the only mild redundancy is the safety restatement that annotations already cover.

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 14-parameter calculator with an output schema, the description covers what it computes, its scope (no auth, no account data), and its modeling assumptions. Minor gaps remain around timed-vs-laps mode interactions (duration vs raceLaps), but the schema documents those fields.

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, but the description adds real semantic content: it states that the entered per-lap consumption is applied to race, formation, and allowance laps, and that reserve selection determines retained finish weight. Those clarifications tie parameters together in a way the flat schema cannot.

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 first sentence names concrete outputs – race fuel load, reserve, start weight, and projected minimum-weight margin – which is a specific verb+resource statement rather than a restatement of the title. It is clearly separable from siblings like calculate_ethanol_blend or calculate_fuel_injector_size, though it never explicitly contrasts 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?

Usage is implied by the purpose and by the closing caution to 'confirm your series weighing rules and validate consumption with real data', but there is no explicit when-to-use / when-not-to-use guidance and no named alternative tool. An agent can infer this is the planning calculator, not a lookup, but must infer 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?

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; the description nonetheless reinforces this with 'without authentication and does not read or save account data.' The genuinely additive content is the model-boundary disclosure that bars, bump stops, tires, and aero load are ignored, which tells the agent when this result will mislead. It does not mention numeric behavior such as rounding or unit echoes, but the output schema covers returns.

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?

Four short sentences, front-loaded with the purpose before the safety and limitation notes. 'Wheel rate compares spring changes' is the one soft sentence that restates the premise without adding information, keeping this just short of a 5.

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 a full output schema and complete annotations, the description does not need to explain return values or permissions. It covers purpose, output semantics ('wheel rate'), and the physical model's exclusions. The only gap is that it never signals the required spring angle or corner weight inputs, which an agent skimming the prose would not anticipate.

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 every parameter including springAngle, cornerWeight, and the unitSystem enum is documented inline, so the baseline of 3 applies. The description only names 'spring rate and motion ratio' and never mentions spring angle or corner weight, so it adds no meaning beyond the schema and is actually narrower than the required parameter set.

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 transformation: converts spring rate and motion ratio into wheel rate. The physics scope is unambiguous and clearly distinct from siblings like calculate_corner_balance or calculate_brake_bias. It stops short of naming the sibling it supersedes for a given question, so it lands at 4 rather than 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?

'For setup comparisons' and 'Wheel rate compares spring changes' imply the use case, and the closing sentence excludes bars, bump stops, tires, and aero load from scope. However, no sibling alternative is named and no explicit when-not condition routes the agent elsewhere, so the guidance is implied 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: no authentication is needed, no account data is read or saved, and the result is an experimental next-test pressure rather than a universal target.

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 transformation, and each sentence adds useful context. There is no redundant or filler 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 an output schema and full parameter documentation, so the description does not need to explain return values or every input detail. It covers the key caveat about the result being a next-test pressure, though it could say slightly more about assumptions or expected input relationships.

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 all five parameters, including unitSystem and ambientChange. The description reinforces the main pressure inputs but does not add meaning beyond what the schema 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?

The description states a specific calculation: converting cold, hot, and target hot pressures into the next cold pressure to try. It is clear what the tool does, but it does not explicitly distinguish itself from nearby tire-related siblings such as analyze_tire_temperatures.

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 by explaining that it produces a next-test pressure rather than a universal ideal and says to recheck after the next run. However, it does not state explicit when-to-use conditions, prerequisites, or alternative tools to choose instead.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: no authentication required, no account data read or saved, and it is a pure calculation from measured inputs. That is useful detail an agent cannot infer from 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?

Four short sentences, front-loaded with the action and reference ranges, then disclaimers, then the handoff advice. No sentence is filler and each adds a distinct piece of 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?

An output schema exists, so return values need no explanation, and annotations cover safety. The description supplies the key interpretive caveats (baseline-only, unit-agnostic inputs). Minor gap: it doesn't state what the check compares against per use case, but that is largely inferable.

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 all six parameters including the use and unitSystem enums are documented there, which sets the baseline at 3. The description names camber and total toe but adds no unit conventions or interpretation guidance for use/unitSystem beyond what the schema already states.

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 ('Check camber and total toe') plus the reference frame ('broad autocross and track baseline ranges'). It explicitly contrasts itself with 'a vehicle-specific prescription,' which separates it from siblings like diagnose_handling_issue or recommend_autocross_damper_adjustment, though it never names those siblings 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?

Explicitly bounds when to rely on the result ('baseline checker, not a vehicle-specific prescription') and redirects the next step to tire wear and driver feedback. It stops short of naming concrete alternative tools, so routing is implied rather than 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 and destructiveHint=false, so the description earns credit for adding genuinely new context: no authentication required, no account data read or saved, and a real accuracy caveat that mounted diameter varies by model and pressure. It stops short of noting rounding/precision or unit-mixing pitfalls, but the added disclosure is substantive.

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?

Front-loaded with what is compared, then safety and accuracy notes in three short sentences. The authentication/account-data sentence is marginally redundant with the read-only annotations but still informative.

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?

Seven required parameters are fully documented in the schema, an output schema exists to explain return values, and the description covers the accuracy limitation that matters most for a calculator. Missing only explicit scoping against sibling calculators.

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 units, ranges, and the unitSystem enum fully documented per field, so the baseline is 3. The description only alludes generically to 'measured inputs' and adds no per-parameter meaning beyond the 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?

Opens with a specific verb and resource ('Compare tire diameter, circumference, ride height, and speedometer change'), naming the exact outputs. This clearly separates it from calculation siblings like calculate_gear_ratio_speed or calculate_tire_pressure_adjustment.

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 establishes context ('calculates from measured inputs') and an input-source preference ('use manufacturer specs when available'), but never states when to prefer this tool over a sibling or what inputs would make it inappropriate. Usage is implied 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutating-but-non-destructive profile is covered. The description adds one genuinely non-obvious behavior beyond that: the call advances the vehicle's tracker, a state transition not visible in the schema. It does not say whether the tracker is closed/reset, whether repeated calls are idempotent, or what happens if the record already 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?

One sentence, no filler, and the action plus its consequence are front-loaded. It is efficient but unstructured for a multi-parameter write, lumping the history record and the tracker advance into a single clause.

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 described. But for an 8-parameter mutation with a state-transition side effect and 0% parameter documentation, an agent gets almost nothing about which optional fields are meaningful or what the tracker advance implies, leaving it under-specified 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 0% across 8 parameters, so the description must carry the burden and largely does not. It only weakly implies vehicleId ("vehicle history"), trackerId ("its tracker") and completedAt ("completed"), and says nothing about notes, mileage, engineHours, logCount or trackEvents, which look like optional history-append values whose effect on the vehicle record is unexplained.

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 ("Record completed maintenance in vehicle history") plus a distinct side effect ("advance its tracker"), which separates it from the plain create_/update_maintenance siblings that only write a record. It never names those siblings explicitly, so an agent must infer that this is the completion/state-transition path rather than the edit path.

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 call this versus update_maintenance, create_maintenance, or archive_maintenance, all of which appear in the sibling list and touch the same resource. No preconditions (must a tracker exist? must it be open? can it be completed twice?) 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that the tool "Calculates from measured inputs without authentication and does not read or save account data," which is useful non-obvious context, but it says nothing about precision, unit conventions, or how the result is derived and returned.

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?

Purpose is front-loaded in the first sentence and the remaining sentences add scope and safety context rather than repeating the name. It is slightly padded by two consecutive disclaimer-flavored sentences that could be merged.

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?

A simple pure-calculation tool with full required-parameter documentation and an output schema, so return values need no explanation. The only real gap is not explaining how afr and lambda inputs interact, plus no note on precision or rounding.

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 fuel enum is self-documenting, so the schema already carries the parameter burden. The description restates the four fuels but never clarifies the relationship between the two required numeric inputs (afr and lambda), which is the one ambiguity a converter description should resolve.

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 a specific verb (Convert) and resource (AFR and lambda) plus the set of fuel scales handled, which distinguishes it from data-mutation siblings in the garage/team toolset. It stops short of naming the nearest sibling converters (e.g. calculate_ethanol_blend), but the purpose is 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?

"Use this as a conversion reference" and the note that "Tune targets depend on fuel, engine, load, and calibration strategy" frame the intent and warn against treating output as tuning advice. However there is no explicit guidance on when to prefer this over related calculators such as calculate_ethanol_blend or calculate_race_fuel_and_weight.

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 that this is a non-read-only, non-destructive, closed-world operation. The description adds useful context with 'additive' (the original session is preserved) and 'accessible' (permission scoping), but it does not explain what data is copied or whether special access is required.

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 a single front-loaded sentence with no wasted words. It is appropriately concise, though its brevity contributes to gaps covered in other dimensions.

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 one-parameter copy operation, annotations cover the safety profile and an output schema exists, so return values need not be described. However, the description is still thin on what an additive copy includes and how the source session is selected, leaving it only minimally sufficient.

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 single parameter, sessionId, has 0% schema description coverage, and the description only implies that an accessible session is the source. It does not explicitly say that sessionId identifies the session to copy or provide any format expectations.

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: create an additive copy of a TuneWorks driving session. It is clear what the tool does, though it does not name or distinguish itself from siblings such as create_session or update_session.

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 explicit guidance on when to use this tool instead of create_session, update_session, or other copy operations. The word 'copy' implies duplication, but the description gives no alternatives, prerequisites, or exclusions.

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=false and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: the result is an editable copy and all item checks are reset. It does not specify whether the original list is left untouched or what permissions are required, but the key behavioral trait is disclosed.

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 a single front-loaded sentence with no filler. Every phrase contributes: the action ('Create an editable copy'), the resource ('connected user shop list'), and the reset behavior ('all item checks reset').

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 annotations covering the write/safety profile, the description does not need to explain return values. It adequately covers purpose and key side effect, but leaves the source-list parameter unexplained and provides no usage guidance, which is a meaningful gap for an agent selecting between similar shop-list 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 0% for the single listId parameter, and the description does not mention listId or explain that it identifies the source list to copy. The agent can infer this from 'a connected user shop list,' but the description fails to compensate for the schema's lack of parameter documentation.

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: 'Create an editable copy of a connected user shop list' and adds the distinguishing behavior 'with all item checks reset.' It clearly separates copying from creating a new list or simply reading one, though it does not explicitly name sibling tools like create_shop_list or reset_shop_list_items.

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 explains what the tool does but gives no guidance on when to use it instead of alternatives such as create_shop_list, get_shop_list, or reset_shop_list_items. There is no mention of prerequisites, exclusions, or selection 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds almost no behavioral context beyond the title — it does not say whether saving with an existing name overwrites, whether channels are validated, or whether the operation is idempotent. For a mutation tool, that is a meaningful gap even with annotations 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?

The single sentence is efficient and front-loads the operation. It is not padded, though its brevity is under-specification rather than disciplined conciseness given the schema gaps.

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 explained. But with 0% schema description coverage and a mutation operation, the description should clarify name-collision behavior, channel format, and whether existing sets can be replaced — none of which are present.

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 the two undocumented required parameters, but it provides almost no detail. It implies 'name' and 'channels' exist but gives no format, constraints, or expected channel identifier structure for the array items.

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 ('Save') and resource ('a named set of chart channels'), making the operation clear. However, it does not differentiate this tool from siblings like delete_chart_channel_set, list_chart_channel_sets, or mark_chart_channel_set_used, leaving routing to be inferred from the name alone.

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 list_chart_channel_sets or mark_chart_channel_set_used. The description offers implied usage only through the word 'Save' and never states prerequisites or exclusions.

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=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine permission constraint (the target team must be 'editable'), but says nothing about duplicate handling, required location fields, or side effects on existing tracks.

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 well-formed sentence with the scope constraint front-loaded and no padding. It is efficient, though its terseness is part of why parameter semantics are under-covered.

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 explained, but for a six-parameter mutation with zero schema descriptions, the description should explain the venue/location parameters and how teamId scoping works. It leaves an agent guessing at most of the input contract.

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% across six parameters, so the description carries the full burden and largely fails: it clarifies only teamId's intent and leaves city, venue, region, country and countryCode entirely unexplained, including which location fields are required beyond venue.

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 ('Create') and resource ('custom track'), and adds the ownership scope ('for the connected user or an editable team'), which distinguishes it from update_custom_track and delete_custom_track siblings. It does not explicitly name those siblings, so it falls 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?

Usage is only implied by the name and the ownership phrasing; the description hints that a teamId targets a team versus a personal track, but never states when to choose one over the other, nor any prerequisites such as needing an editable team.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only a vague access constraint ('accessible vehicle') and says nothing about duplicate handling, whether saving overwrites an existing favorite, or what happens if sourceLogId is invalid.

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 short sentence with no padding, so it is concise, but concision comes at the cost of substance — there is nothing beyond the bare action statement to front-load.

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 moderately complex write tool with 7 params, a nested object, and an enum, and the description leaves the parameter space entirely undocumented. The output schema covers return values, but the input side is far too thin for a create operation of this shape.

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% across 7 parameters, including a free-form nested chartConfig object with additionalProperties=true, an enumerated source field, and channelSetId. The description explains none of them, so the agent gets no help on the most ambiguous inputs.

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: save a favorite chart, scoped to a vehicle and source log. The phrasing 'accessible vehicle' is vague and the description never distinguishes this from sibling create/list/delete_favorite_chart operations, so an agent must rely on the tool name to disambiguate.

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 guidance on when to use this versus list_favorite_charts, delete_favorite_chart, or create_chart_channel_set. No mention of prerequisites such as the vehicle needing to be shared/accessible to the caller, which is the one constraint the sentence gestures at without explaining.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the 'no deletes' note and says nothing about whether creation is immediate, what happens on duplicate names, whether dueDate/interval fields are optional in practice, or what the output schema returns.

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, and the core action is front-loaded. However, the second sentence about deletes is somewhat tangential to a creation tool and consumes space that could have described the parameters.

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 9 parameters, 4 required, low schema coverage, and minimal annotations, the description is far too thin for an agent to call this correctly — particularly around intervalType/intervalValue vs. dueDate semantics. The output schema existing relieves the need to describe returns, but parameter behavior and validation remain 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 only 22% across 9 parameters, so the description must compensate — and it does not. It never explains vehicleId, name, category, intervalType, intervalValue, reminderDaysBefore, or the relationship between doneDate and dueDate. The schema documents only doneDate and dueDate, leaving most params undocumented anywhere.

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 (creates) and resource (TuneWorks maintenance reminder or service item), which is clearer than the bare title. It does not explicitly distinguish itself from siblings like update_maintenance, complete_maintenance, or archive_maintenance, but the 'creates' verb does most of the work.

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 only usage signal is the negative 'Deletes are not supported,' which faintly gestures at archive_maintenance but never names it or any alternative. There is no guidance on when to create a reminder vs. a service item, or how this differs from update_maintenance or complete_maintenance.

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=false and destructiveHint=false, so the write-and-safe profile is covered. The description adds nothing about required fields, validation of vehicleId, whether dataLogIds must reference existing logs, or what the response returns — and 'Deletes are not supported' is irrelevant boilerplate for a create 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?

Very short and front-loaded, so it doesn't waste the reader's time. But the second sentence earns no place — it restates an obvious limitation of a create endpoint rather than adding guidance or parameter meaning.

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 needn't be explained. However, a 22-param create tool with only 3 required fields and near-zero schema coverage needs the description to orient the agent toward required inputs and field purposes; it does none of that.

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?

22 parameters at 5% schema description coverage, and the description contributes zero parameter semantics. It doesn't mention that vehicleId, sessionDate, and sessionFormat are required, nor explain the many free-text session fields (worked, braking, cornerEntry, overallBalance) or the two enums.

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 ('Saves a new TuneWorks driving session'), which is precise enough to distinguish it from update_session, copy_session, and archive_session siblings. The trailing 'Deletes are not supported' sentence muddies rather than clarifies 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?

No indication of when to call this versus update_session (for editing an existing session) or copy_session (for duplicating one). The only contextual statement given — that deletes aren't supported — is a negative that doesn't route the agent anywhere useful.

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=false, destructiveHint=false, so the safety profile is covered structurally. The description adds almost nothing beyond that: no mention of duplicate-name behavior, validation failures, side effects on related sessions/logs, or what 'Deletes are not supported' is meant to warn against in a create operation.

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?

Very short and front-loaded, which is good, but the second sentence is a non sequitur for a create tool and consumes half the available text without 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?

With seven parameters, a nested open-ended object, and low schema coverage, the description is far too thin. An output schema existing excuses explaining return values, but the input-side gaps (especially setupData contents and dataLogIds/influencedSessionId linkage) remain 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 only 43% across seven parameters, including a free-form nested setupData object and undocumented vehicleId, setupName, dataLogIds, and influencedSessionId. The description provides no parameter meaning at all, so it fails to compensate for the coverage gap.

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 ('Saves a new TuneWorks setup for a vehicle'), which is clearly distinguishable from update_setup and archive_setup. The scope of 'new' is stated explicitly. It stops short of differentiating itself by naming any sibling 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 indication of when to use this versus update_setup or archive_setup, no prerequisites (e.g., vehicle must already exist), and no guidance about duplicate setups. The only usage-adjacent statement, 'Deletes are not supported,' describes an unrelated capability rather than 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention that a valid 'purpose' value is required, no side effects, no indication of what is returned or whether duplicate titles are allowed.

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 — the verb and resource come first. It is efficient, though the brevity comes at the cost of detail rather than because no detail was needed.

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 create tool with 9 parameters, nested item/category arrays, and one documented parameter, the description is far too thin. It omits how the list attaches to a setup/session/vehicle and what constitutes a valid purpose value, leaving the agent to reverse-engineer the schema; only the existence of an output schema excuses return-value documentation.

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 only 11% across 9 parameters, so the description carries the full burden and largely fails. It only alludes to categories and items being optional, giving no meaning for setupId, sessionId, vehicleId, status, note, or the nested item fields; the required 'purpose' enum-like constraint is left entirely to the 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?

States a specific verb and resource ("Creates a TuneWorks shop list, task list, or parts list") and clarifies that the three list types are variants of one resource. It does not name differentiating siblings like add_shop_list_item or add_shop_list_category, so the boundary is only implied by "optionally including categories and items."

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 explicit when-to-use statement, no prerequisites, and no alternative named. The only hint is the word "optionally," which vaguely implies you may create the list empty and populate it later with add_shop_list_item/add_shop_list_category, but the agent must infer that.

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 non-read-only, non-destructive, closed-world behavior, so the safety profile is covered. Beyond that the description adds only that the team belongs to the connected user; it says nothing about whether the caller becomes owner, whether names must be unique, how many teams a user may hold, or what happens on duplicate names.

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 short sentence with the verb and resource front-loaded and zero filler. It is efficient, though the brevity is under-specification rather than disciplined compression.

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 needn't be described, and annotations cover safety. But for a mutation tool sitting among 80+ siblings with an undocumented parameter, the description should at least cover ownership semantics and name constraints; those gaps make it thin 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 0% and the single 'name' property is an undescribed string, so the description must compensate — but it says nothing about format, length, uniqueness, or validation. An agent could pass a duplicate or malformed name with no warning.

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 ("Create a new team"), so an agent knows exactly what entity is produced. However, it offers no differentiation from the many sibling team tools (rename_team, delete_team, send_team_invite, leave_team), leaving the agent to infer the boundary from names alone.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as send_team_invite for adding people or list_teams for checking existing teams. The single clause "for the connected user" is the only contextual hint and it is about scoping, not usage 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 declare a non-read-only, non-destructive, closed-world mutation, so the bar is lower. The description contributes real context: the record is scoped to the connected user's garage and there is no delete counterpart. It omits duplicate handling, ownership constraints beyond the default, and any required-field prerequisites.

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 creation scope front-loaded and the deletion caveat second. Nothing is padded, though the list of attached entity types is somewhat incidental 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 19 parameters and near-zero schema prose, an agent gets no help on what the required engine/drivetrain fields expect or how enums like aspiration and purpose should be chosen. The output schema covers return values, but the input-side burden is left almost entirely unmet.

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 only 11% across 19 parameters (10 required, 5 enums), so the description must compensate and it does not — it mentions no fields at all. Only 'owner' has schema prose, and the description's 'connected user's garage' phrasing merely restates that default.

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 ('Adds a vehicle to the connected user's TuneWorks garage') and explains the downstream value (setups, sessions, modifications, maintenance). The verb 'Adds' distinguishes it from update_vehicle/archive_vehicle, though no sibling is named explicitly.

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?

Implies this is the creation path for a new garage vehicle and adds the constraint 'Deletes are not supported,' which nudges toward archive_vehicle for removal. However, it never states when to use this versus update_vehicle or what happens if the vehicle already exists.

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=false, destructiveHint=false, and openWorldHint=false, so the mutation profile is covered. The description adds the useful scope note that this writes to connected user settings, but says nothing about idempotency, duplicate handling, or whether the make becomes immediately selectable.

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; the key action and target come first. It is efficient but so terse that it leaves the teamId ambiguity unaddressed.

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 is simple (2 params, output schema present, annotations present), yet the description omits the one thing an agent cannot infer: the meaning and effect of teamId, and whether duplicate makes are rejected or merged. For a create operation that is a material 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?

Schema description coverage is 0%, so the description must carry parameter meaning and it does not. "Vehicle make" loosely maps to the required make parameter, but the optional teamId is completely unexplained — an agent cannot tell whether omitting it creates a personal make or fails.

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 ("Add") and resource ("custom vehicle make") and scopes it to "connected user settings." An agent can tell this creates a user-defined lookup value rather than a vehicle, but it never distinguishes itself from siblings like create_vehicle or update_vehicle_make.

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 statement of when to use this versus update_vehicle_make (for existing makes) or create_vehicle (which presumably also involves a make). No prerequisites, no mention of what happens if the make already exists.

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