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

Goes well beyond annotations: no per-reading timestamps, instrument-paced timing, approximate rates by function and speed, duration refusal, and how function/range are retained or changed. These details let an agent predict latency and side effects; annotations already cover safety.

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-loads purpose and return, then uses a structured Args section; the length is justified by five undocumented parameters and instrument-specific constraints. Almost every sentence adds operational 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?

Complete for a complex instrument operation: the output schema handles return structure, while the description covers timing, duration limits, configuration persistence, and parameter requirements. The only minor omission is explicit sibling routing.

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 fully compensates: count range, function enum with lead requirements, valid ranges per function, speed restrictions and sensor requirement. This is substantially more than the raw 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?

States a specific action and return payload: take a series of readings at the instrument's maximum rate and return statistics plus all values. It references measure only for function/range configuration, not to explain when burst should be chosen over measure or sample, so sibling differentiation is partial.

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 clear context for use: many readings in one fast burst, with explicit refusal above 600 s and defaults for function/range. It does not state when to use measure, sample or read instead, nor any exclusion beyond the duration limit.

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, idempotentHint=true, and openWorldHint=false, so the safety profile and repeatability are covered by structured data. The description contributes the notable behavioral detail that the returned configuration is the 'present' one, implying a live snapshot rather than cached data. It does not state whether the call actually touches the instrument bus or whether it can fail/time out on a disconnected device.

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 compact clause with zero filler, front-loading the most identifying fields (model, serial, firmware). It is a noun phrase rather than a sentence, which makes it slightly less self-explanatory as a standalone statement but costs no reading effort.

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 zero parameters, a full output schema, and annotations covering safety and idempotency, the definition only needs to establish purpose – which the field list does adequately. The only missing element is a usage cue relative to the measurement siblings, a minor gap for such a simple read-only query.

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; baseline 4 applies. The description correctly implies the tool is argument-free by framing itself purely as a retrieval of device attributes.

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 enumerates exactly what is retrieved: instrument model, serial number, firmware, VISA resource, and current measurement configuration. Combined with the verb in the name (get_device_info), the resource and scope are unambiguous, and the other siblings (read, measure, sample, burst) are clearly measurement operations rather than identity queries. It stops short of an explicit sentence stating the action, relying on the name for the verb.

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

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

There is no guidance on when to call this versus the measurement siblings, and no stated preconditions (e.g., whether a VISA session must already be open). An agent must infer that this is a discovery/identity call made before measurement, which is plausible but not stated anywhere.

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?

Without relying on the annotations, the description discloses that the call changes instrument state including the front panel (explaining the readOnlyHint=false despite a measurement), that autorange is the default, that `speed` trades PLC count against accuracy, and what the reading includes. That is materially more than the annotation block conveys.

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 purpose is front-loaded in one sentence and the Args block is dense reference material rather than padding. The long per-function range list is heavy, but with 0% schema coverage that detail has to live somewhere, so it earns its place.

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

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

For a four-parameter tool with enum-constrained inputs and conditional requirements, every branch is covered: autorange vs fixed range, speed applicability, temperature sensor, and the state change it causes. An output schema exists, and the reading-summary sentence is a small bonus rather than a 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 carries the full burden and does: it maps each function enum value to its wiring (HI/LO vs I/LO, HI Sense/LO Sense), enumerates valid ranges per function with units, restricts `speed` to four functions with accuracy implications, and states that `sensor` is required for temperature with valid types.

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 gives a specific verb+resource pair: select a measurement function and take one reading, plus the side effect that it switches the instrument (front panel included). It implicitly distinguishes itself from `burst`/`sample` by saying 'one reading', but it never names those siblings or states the contrast explicitly, so the agent must infer the boundary.

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 rather than stated: pick a function, omit `range` for autorange, add `sensor` for temperature. Nothing tells the agent when to call `measure` versus `sample`, `read`, or `burst`, which is exactly the decision it faces among these 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?

Goes meaningfully beyond the annotations: it discloses that the instrument's function/range/speed are preserved, that the trigger is reconfigured to immediate with one reading per trigger, and what comes back. This explains why readOnlyHint is false for an operation otherwise named 'read' — a real ambiguity resolved. It stops short of stating timing/blocking behavior or what happens on instrument error.

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 core action, then state effects, then return value. The 'as measure does' comparison is the one clause that adds ambiguity rather than 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 and the description needn't enumerate returns, though it does briefly. For a zero-parameter instrument action, the key facts — what state is used, what state changes, what comes back — are all 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?

Zero parameters, so the schema carries no burden. The description usefully clarifies that the call implicitly uses whatever function, range and speed are currently configured rather than requiring arguments.

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 concrete action and resource ('take one reading') and the instrument state it acts on (function, range, speed currently set). It does not clearly separate itself from the sibling 'measure' — in fact 'as measure does' implies the two behave alike, which could make an agent unsure which 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?

No explicit guidance on when to use 'read' versus 'measure', 'sample' or 'burst'. The only comparative statement ('as measure does') describes trigger behavior rather than a selection criterion, so the agent has to guess.

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?

Beyond the annotations, the description discloses detailed behavior: reading duration depends on speed/function, shorter intervals cause back-to-back readings, no reading starts later than one interval after duration_s, and the recording ends on time with fewer samples. It also explains state persistence when function/range are omitted. These are meaningful operational details not available 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?

The purpose is front-loaded and the Args section is structured, with detail warranted by zero schema coverage. The pacing sentence is somewhat dense and could be clearer, but there is little wasted content.

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. The description covers timing behavior, parameter constraints, state persistence, and function-specific applicability for a complex six-parameter tool. Nothing material appears missing.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden. It documents all six parameters: duration max, interval min, function lead selection, valid range values per function, speed applicability, and sensor requirements for temperature. This adds essential meaning beyond the bare 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 clearly states a specific action: recording timestamped readings at a fixed interval and returning statistics plus all samples. The scope and output are clear. It references measure for inherited settings, but does not explicitly position itself against burst or read, so sibling differentiation is incomplete.

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

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

The description implies this tool is for timed recording rather than a single measurement, and says omitted function/range keep the present settings while otherwise they are set as in measure. However, it gives no explicit when-to-use versus alternatives like measure, burst, or read, and no exclusions.

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