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

With no annotations at all, the description carries the full burden, and it does disclose the key trait — the operation destroys diagnostic trouble codes and needs user confirmation. It stops short of saying whether the clear is irreversible, which ECUs/session state is required, or what happens to stored freeze-frame data, so a mutation tool remains only partially characterized.

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 clauses, front-loaded with the service identity and followed by the safety directive; nothing is padded. Slightly terser than ideal for a destructive operation, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be described, and the destructive nature is flagged. However, for a diagnostic write action with a fully undocumented parameter, the description leaves the agent guessing on group encoding and on preconditions such as session/security access.

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 description only explains the magic default value 'FFFFFF = all'. It adds real meaning for that one value but never explains the accepted DTC-group encoding (e.g., three-byte groupOfDTC format) or what a non-default group string should look like.

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

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

Names the exact UDS service (0x14 ClearDiagnosticInformation) and the resource it acts on (a DTC group), so an agent knows precisely what the call does. It is distinguishable from read_dtc_information by implication, but the description never states that contrast 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?

Gives a concrete, actionable precondition: 'Confirm with the user before clearing,' which tells the agent this is a destructive action requiring human sign-off. It doesn't name alternatives (e.g., read_dtc_information first to inspect) or state when clearing is appropriate versus unnecessary.

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

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It does not explain that this is a state-changing ECU control operation, what the session switch affects, permission or ignition requirements, or possible negative responses.

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

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

The description is very compact and front-loads the service identifier and parameter values. It wastes no words, though its extreme terseness contributes to gaps handled under 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 state-changing diagnostic control service with no annotations and a safety-relevant automotive context, the description is incomplete. The output schema can cover return values, but prerequisites, session effects, and response handling remain undocumented.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully lists accepted session values (default, programming, extended, safety, or a hex number), but it does not explain each session's semantics, the expected hex format, or the schema default of extended.

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

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

The description identifies the UDS service as 0x10 DiagnosticSessionControl and lists possible session values, so an automotive-aware agent can infer the tool changes diagnostic sessions. However, it largely restates the tool name and does not plainly state the effect or distinguish it from sibling diagnostic services.

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 no guidance on when to use this tool versus alternatives such as security_access or tester_present. There are no prerequisites, exclusions, or conditions for selecting a specific session.

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

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

With no annotations, the description carries the full load and does disclose the key side effect: the ECU returns to the default session, implying the current diagnostic session and its state are lost. It also flags that the action is consequential enough to warrant user confirmation, though it omits whether the ECU drops communication or how failures surface.

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 in a deliberate order: service/identity, parameter values, consequence plus safety instruction. Nothing is padded and the most decision-relevant constraint (confirm first) lands last for emphasis.

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 the single parameter's valid values are given. The remaining gap is operational context — required session or security preconditions and what happens on negative response — for a tool with zero annotation coverage.

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% and the schema only carries a title and a default of "hard", so the description has to compensate. It enumerates the accepted values (hard, key_off_on, soft, or a hex number), which is exactly what the agent needs to construct a call; it stops short of explaining what each mode actually does to the ECU.

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

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

Names the specific UDS service (0x11 ECUReset) and states the concrete effect, so the operation is unambiguous. It does not explicitly contrast itself with siblings like diagnostic_session_control or tester_present, though the domain vocabulary carries most of the distinction.

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?

"Confirm with the user before resetting" gives a real precondition for invoking it, which is more than most definitions offer. However, it never states when a reset is the right call versus alternatives (e.g. session_control to switch sessions) or which prerequisitive state/session the ECU must be in.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Describe' implies a read-only, non-mutating operation, but the description does not explicitly state whether it has side effects, whether it queries the live ECU, or whether a connection or session prerequisite 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?

The description is a single front-loaded sentence with no filler. It efficiently lists the key categories of information the tool returns.

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 output schema documents the return structure, and the description confirms the high-level contents: interface, CAN IDs, current session, DIDs, routines, and security levels. It is sufficient for invocation, but it omits usage context relative to the many diagnostic sibling 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?

The tool has zero parameters, which merits the baseline score of 4. There are no parameter semantics to explain beyond what the empty input schema already conveys.

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

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

The description uses a specific verb, 'Describe', and names the resource, 'the connected ECU'. It also enumerates the returned information, including interface, CAN IDs, current session, known DIDs, routines, and security levels, which clearly separates it from diagnostic action tools, though it does not explicitly name a sibling 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 description does not state when this tool should be used, when it should not, or which sibling tool to use instead. An agent could reasonably infer it is an introspection tool, but it does not clarify whether it should be called before read_data_by_identifier, security_access, or routine_control.

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

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

No annotations are provided, so the description bears the full burden. It does disclose a genuine behavioral trait, the one-at-a-time restriction for DIDs outside the ECU config, which is non-obvious and useful. However, it omits anything about session/security prerequisites and does not state the failure behavior when a DID is unsupported by the ECU.

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, front-loaded with the service name and immediately followed by the parameter format and then the constraint. Nothing is wasted, though the leading '0x22 ReadDataByIdentifier' is largely a restatement of the tool name plus the service code.

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. For a UDS diagnostic read, though, an agent still needs to know about session and security-access preconditions, and the description covers neither, leaving a meaningful gap in operational completeness.

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% for the single 'dids' parameter, so the description has to carry the meaning and partially does, giving a hex-string example ("F190", "F18C") and a batching caveat. It does not specify accepted DID length or case/prefix expectations, so it only partly compensates for the empty schema.

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

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

The description names a specific verb and resource and ties it to the UDS service ID 0x22, which lets a UDS-literate agent distinguish it from siblings like write_data_by_identifier and read_dtc_information. It stops short of explicitly contrasting against the nearest sibling, but the read/write split is clear.

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 guidance is an operational constraint ('DIDs not known to the ECU config must be read one at a time'). There is no statement of when to use this versus send_raw or read_dtc_information, nor any mention of preconditions such as an active diagnostic session or security access.

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

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

With no annotations, the description carries the full behavioral burden but discloses almost nothing: it does not explicitly confirm read-only/non-destructive behavior, session or security-access prerequisites, or any behavioral nuance beyond the raw service ID. Return values are covered by the output schema, so that omission is excusable, but the operational context is thin.

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-scoped sentence with the service identifier front-loaded and zero filler. It borders on under-specification rather than verbosity, but structurally it is tight and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return values, so that needn't be explained. But with no annotations, 0% schema coverage, and this being a diagnostic-service call, the description is barely adequate – it names the service and the one parameter's format but omits session/prerequisite context an agent may need 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 coverage is 0%, so the description must compensate. It does identify status_mask as a 'hex byte' that filters DTCs by status, which adds real meaning over the bare schema (default FF, type string), but it doesn't explain the bit semantics of the mask or valid values, leaving a partial 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 (reads DTCs) and scopes it to those whose status matches status_mask. The service-ID notation (0x19 02) and 'DTCs' vs the sibling clear_diagnostic_information make the read-vs-clear distinction inferable, though the acronym-heavy phrasing keeps it from being maximally self-explanatory.

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 siblings like clear_diagnostic_information or read_data_by_identifier, and no exclusions or preconditions (e.g. required diagnostic session). It only restates what the operation does.

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

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

With no annotations, the description does add real value by warning that routines 'act on the ECU' and require user confirmation before starting, which signals a state-mutating operation. It does not disclose likely prerequisites (diagnostic session, security access) or what stop/results do differently from start.

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 no padding, and the identifying information (service id, routine_id format) is front-loaded ahead of the safety note. Nothing wasteful, though the brevity comes at the cost of parameter coverage.

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 three-parameter UDS mutation tool with no annotations and 0% schema coverage the description omits control semantics, data payload handling, and session/security prerequisites that would matter before invoking it.

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 three parameters, so the description carries the full burden. It clarifies only routine_id (hex encoding with an example) and says nothing about `control` (start/stop/results) or `data_hex`, leaving two of three 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+resource combination (0x31 RoutineControl on a routine_id) with a concrete hex example ("0203"), which lets an agent map it to the UDS service. It does not explicitly differentiate from siblings such as read_data_by_identifier or ecu_reset, which is why it stops short of 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?

The only guidance is a caution to confirm with the user before starting a routine; there is no statement of when to use this tool versus the ten sibling diagnostic tools. No prerequisites (session, security access) or exclusions are given.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the session prerequisite and the seed/key exchange, but it omits important traits such as what ECU state is unlocked, failure/lockout behavior, and whether the operation is state-changing or reversible.

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

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

The description is two compact sentences and front-loads the service identifier and core action. It avoids repetition of schema fields, though phrases like 'odd level' are cryptic rather than self-contained.

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. For a security-critical, state-changing operation with no annotations and 0% parameter-description coverage, the definition is minimally adequate but omits failure behavior and level-value semantics.

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 the undocumented level parameter. It mentions 'odd level' and 'that level,' but does not clarify accepted values, the default of 1, or the odd/even UDS seed-key mapping, leaving the parameter only partially explained.

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

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

The description names the specific UDS service (0x27 SecurityAccess) and states the core action: request a seed and send the computed key. This is a clear verb-and-resource pair, though it does not explicitly contrast with sibling diagnostic tools such as diagnostic_session_control.

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 provides one concrete prerequisite, 'Needs a non-default session,' which is useful usage guidance. However, it does not explain when to use this tool versus related siblings like diagnostic_session_control or send_raw, nor does it describe when not to use it.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool sends arbitrary raw hex and returns the raw response, but it does not warn that raw UDS requests may include write, security-access, reset, or other destructive operations, nor does it mention validation, permissions, or side effects.

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 action, followed by the routing condition. The example earns its place and there is no unnecessary 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 output schema means return values need not be explained, and the single parameter is adequately illustrated. However, for a raw UDS escape hatch with no annotations, the description should do more to disclose safety implications and side effects.

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% and the only parameter is named only as Request Hex in the schema. The description compensates well by saying the input is hex bytes and giving a concrete example, though it leaves spacing and formatting conventions implicit.

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: send a raw UDS request as hex bytes and get the raw response. The example "22 F1 90" and the note to use it for services without a dedicated tool distinguish it clearly from the dedicated diagnostic siblings.

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 says to use it for services without a dedicated tool, which is clear routing guidance against the sibling tools. It does not add when-not-to-use cautions or prerequisites, but the core usage condition is 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?

With no annotations at all, the description carries the full disclosure burden, and the one real nugget it adds — that an automatic keep-alive already runs — is genuinely useful behavioral context. But it omits the core effect (that calling it refreshes the ECU's session/S3 timer and can prevent session timeout), whether the call is idempotent/safe, or what a positive vs. negative response means.

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 waste, with the identifier first and the actionable caveat immediately after. Nothing is buried and nothing is padded.

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 output schema exists, so return values need not be explained, and the absence of parameters keeps the surface small. Still, for an agent-facing tool it lacks a plain-language statement of what the operation does and when invoking it actually matters, which is the remaining gap for a zero-arg mutation-style diagnostic call.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; a baseline of 4 applies. The prose neither helps nor misleads on this dimension.

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?

It names the UDS service by its hex id and mnemonic ('0x3E TesterPresent'), which an agent with domain knowledge can map to 'keep the diagnostic session alive.' However, it never states in plain terms what the tool actually does — telling the ECU the tester is still connected — so an agent without UDS familiarity is left inferring the purpose from the name itself.

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?

'Rarely needed: a keep-alive already runs in the background' is an explicit when-not-to-use signal and points at the implicit alternative (rely on the automatic keep-alive). It stops short of stating the condition under which the tool IS the right call, e.g. when the background keep-alive has lapsed or a specific session requires an explicit ping.

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

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

With no annotations, the description carries the burden well: it discloses that this is a mutating write, typically requires extended session and security access, and should be user-confirmed before execution. It omits error/reversibility behavior, but the safety-relevant traits are covered.

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, front-loaded with the service identity, followed by input format, prerequisites, and the confirmation warning. No wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. However, for a security-sensitive write with an undocumented required 'did' parameter, the description should say more about what the identifier is and failure behavior to be fully 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 coverage is 0%, so the description must compensate. It explains the two value input formats with examples ('00 64' or text), which is useful, but it leaves the required 'did' parameter entirely 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?

The description names the UDS service (0x2E WriteDataByIdentifier), a specific write operation on a data identifier, which is distinguishable from the read_data_by_identifier sibling. It is clear but does not explicitly contrast itself with siblings.

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 practical prerequisites: 'Usually needs the extended session and security access' and 'Confirm with the user before writing.' That is clear usage context, but it never names alternatives or conditions for when not to use it.

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