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

With no annotations, the description carries the full burden and does a good job: it warns that long recordings take minutes over Bluetooth, describes resume-after-interruption semantics, and enumerates the return payload (file, record count, seconds per record, retries, header). It omits file-overwrite behavior when 'out' already exists and does not discuss permissions or failure modes beyond timeouts.

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 core action and target format lead the description, followed by operational caveats and return shape — a sensible ordering. The parenthetical column list is slightly dense but earns its place by telling the agent what a row contains.

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, file-writing tool with no output schema, the description covers the essentials: what is written, what is returned, latency expectations, and resume behavior. The main residual gaps are overwrite semantics for an existing 'out' path and interaction between `limit` and resume.

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 is already documented, and the description's resume note largely restates what the `start` field says. It adds no semantics for `limit`, `max_wall`, or the default-path behavior of `out`, so the schema is doing the heavy lifting.

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 ('Download trend recording `index`') plus the output format (CSV/JSONL) and row shape. It also routes the agent to the sibling `memory` tool to obtain the index, so it is distinguishable from `read`, `query`, and `live` 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?

Gives clear context: use this to pull a whole recording to a file, and use `memory` for indices. It also documents the resume path ('start' plus the same 'out'). It does not explicitly state when to prefer a sibling such as `read` or `query` for lighter-weight access, so it stops 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 only declare readOnlyHint=true; the description adds meaningful behavior: the ~4 Hz sampling rate, that results are aggregated not streamed, the exact summary fields returned (count, rate, first/last time, min/max/mean, functions/units, last 5 readings), and the default window. It does not discuss adapter error behavior or what happens if the adapter is disconnected.

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 core action, sampling rate, stop conditions, and return shape are front-loaded in one dense sentence, with the routing hint to log_start placed last. The enumeration of summary fields is long but earns its place since there is no output schema.

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 no output schema, the description carries the return-value burden and does so thoroughly, listing every summary field. Combined with the sampling rate, entry conditions, defaults, and the log_start alternative, an agent has everything needed to call 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 100%, so all three parameters are already documented, including the count/seconds 'whichever comes first' semantics. The description restates the default of 20 readings and the count-or-seconds choice but never mentions max_wall and adds no syntax or interaction detail 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 ('Collect real-time readings from the adapter'), the sampling rate (~4/second), and crucially that it returns a summary rather than raw readings. The contrast with log_start makes it distinguishable from the closest sibling without opening either 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?

Explicitly routes long-running or file-persisting cases to log_start, which is the key disambiguation for this tool, and gives the default of 20 readings. It does not differentiate from other siblings such as read, query, or status, so the guidance is clear but not exhaustive.

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 and does so well: it discloses background execution, return values, termination triggers (duration, log_stop, prolonged Bluetooth loss), client-disconnect persistence, and concurrency BUSY behavior. These are exactly the operational traits an agent needs before invoking it.

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, then lifecycle, then constraints. Every sentence adds operational value; there is no repetition or filler.

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

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

For a background logging tool with six optional parameters and no output schema, the description covers what is started, what is returned, how it ends, concurrency limits, and sibling follow-up tools. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already defines each parameter including defaults and examples; the description adds only high-level lifecycle context for duration and reconnect_for. It does not add syntax or format details 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?

The description opens with a specific verb and resource ('Start logging live readings...') and names output formats, background execution, and return values (job id and file). It also distinguishes this tool from log_status and log_stop by defining their roles in the lifecycle.

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 clear lifecycle guidance: follow with log_status, end with log_stop, one log at a time, and other meter tools return BUSY while active. It also states termination conditions. It does not explicitly say when to use this instead of live/read for one-off readings, so it stops short of full alternative 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?

readOnlyHint=true already covers the safety profile, so the description earns credit for adding genuinely new behavior: the summary fields (min/max/mean per unit, link gaps) only appear once the log has ended, which is non-obvious timing information an agent needs. It stops short of saying whether the call blocks, whether state transitions are push or poll, or what happens for an unknown or expired job id.

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 dense but well-ordered sentence that front-loads the core state before the trailing detail. No filler, though the long parenthetical list makes it slightly harder to scan than a two-sentence split would be.

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 no output schema, the description takes on the burden of describing return values and does so field by field, including the conditional post-completion summary. The main residual gap is that nothing describes the failed case beyond a label (error text, exit codes) or how to retrieve the referenced file.

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 `job` parameter has full schema description coverage including its default ('the latest log'), so the schema carries the semantics. The description adds nothing about the parameter, and 100% coverage makes 3 the correct baseline.

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 resource (a background log) and enumerates the exact facets returned: state, records written, last status line, file, and post-completion summary. An agent can tell this is a read-only progress/inspection call, but the description never names the sibling `status`, `live`, or `log_start` tools, so differentiation from `status` is left to inference.

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: 'background log' plus the schema note 'job id from log_start' hints this is the follow-up to log_start for polling progress. There is no explicit statement of when to prefer this over `status` or `live`, nor whether polling repeatedly is expected.

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 burden and does well: it discloses a non-obvious cross-session side effect (stopping a log or live started in a terminal or another client when `job` is omitted) and explains the already_ended flag semantics, including that the summary is stale in that case. It does not cover failure modes, whether the log file is retained, or permission requirements, keeping it short of 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?

Front-loaded with the action and return payload, then the conditional behavior and edge case. The parentheticals are dense but each clause carries information; the second sentence runs long and could be split for readability, but there is no filler.

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

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

With no output schema and no annotations, the description supplies the return fields inline and covers the default-path behavior and the already-ended edge case, which is what an agent needs to call it correctly. Missing only error behavior when no log exists and whether data is preserved after stopping.

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 already 100% for the single `job` parameter, so the baseline is 3. The description earns above baseline by explaining the consequence of omitting `job` — it will reach out and stop a log started elsewhere, not merely default to the latest one — which is meaning the schema does not convey.

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 ('Stop the background log') and immediately enumerates what comes back (file, records, duration, min/max/mean per unit, link gaps). This is clearly distinguishable from log_start, log_status, and live, which would start, inspect, or stream rather than terminate and summarize.

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 makes the primary use case clear (terminate a running log and get its summary) and adds a useful conditional: without `job` it will also stop a log or live started elsewhere. It stops short of explicit routing guidance such as 'use log_status to inspect without stopping' or stating what happens when nothing is running, so there is context but no 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds meaningful context beyond that: it lists the kinds of saved items, the fields each item exposes, and clarifies that recordings include interval, number of records, and duration. It does not describe pagination, error behavior, or response format, but it substantially improves behavioral understanding.

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 front-loaded and dense, with no filler sentences. The long parenthetical listing fields is somewhat hard to parse, but every clause conveys relevant structure. It is appropriately sized for the amount of return-shape information it needs to 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?

There is no output schema, so the description carries the burden of explaining return values, and it does so thoroughly by enumerating item kinds and fields. It also explains the index relationship to download_recording. Minor gaps remain around pagination and error responses, but the definition is complete enough for an agent to understand what memory returns.

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 max_wall has complete schema description coverage, including its default and timeout behavior. The description does not mention max_wall or add any meaning beyond the schema. With 100% coverage, the schema carries parameter semantics adequately, so the baseline score of 3 is appropriate.

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

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

The description clearly states that this tool reports what is saved in the meter's memory, enumerating counts, measurements, MIN MAX sessions, peak sessions, and trend recordings with their fields. It distinguishes the index from the record-fetching behavior of download_recording. The purpose is clear, though it reads more as a data inventory than a crisp verb-resource statement.

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

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

The description implies usage by explaining that download_recording fetches the records of a recording, while this tool provides the index and item metadata. It does not explicitly state when to call memory versus status, read, or query, nor does it give exclusions or prerequisites. The guidance is 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?

With no annotations, the description carries the full burden and does well: it discloses that display state is returned after each key, explains held behavior including RANGE autorange, and warns that ONOFF permanently powers off the meter, cannot be reversed remotely, puts the adapter to sleep, is refused unless allow_off is true, and requires F1/F4 confirmation.

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 compact, front-loaded paragraph: main action first, then held semantics, then the ONOFF safety behavior. Every sentence adds useful information without repetition.

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

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

For a mutation-style tool with no output schema and no annotations, the description covers the important return value, the sequential key behavior, long-press semantics, and the irreversible ONOFF flow. No critical invocation detail is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaningful semantics beyond the schema: held is a long press with special RANGE behavior, and allow_off controls the ONOFF safety gate and confirmation flow. max_wall is left to the schema, which is acceptable.

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 (simulate) and resource (front-panel keys), lists the supported keys, and says it returns the display state after each key. The purpose is clear and distinct from sibling tools such as status, read, and live.

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 gives important invocation constraints for held presses and ONOFF, but it does not explicitly say when to use this tool instead of reading state through siblings. Usage is implied by the purpose and special-key rules.

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, so the safety profile is covered structurally. The description does add real behavior beyond that: the UNSAFE_OPERATION refusal happens before the command reaches the meter, and binary replies come back as hex. It does not discuss per-command failure modes or what a partial multi-command failure looks like, so it adds useful but not complete context.

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

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

Front-loaded with the action and result, then the whitelist, then the refusal rule. Dense but nearly every clause carries information; the parenthetical command examples are slightly list-heavy but functional.

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?

There is no output schema, so the description correctly takes on the job of explaining responses (text, or hex for binary). Combined with the schema's timeout semantics, an agent has enough to call this correctly; only multi-command failure ordering is 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it defines which command strings are legal and shows the QMP <property> sub-syntax, well past the schema's bare example ['ID', 'QM']. Timing semantics for max_wall are already in the schema and are not repeated unnecessarily.

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?

Specific verb plus resource: 'send read-only remote commands to the meter and return each answer'. It enumerates the accepted command vocabulary (ID, IM, Q*, QMP <property>), which lets an agent distinguish this from siblings like press or memory 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 concrete when-to-use scope via the command whitelist and states the exclusion case: anything else (PRESS, MP, CSD, RI, OFF) is refused. It stops short of naming the specific sibling tool (press) an agent should call instead for those operations, leaving that 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, so the safety profile is covered. The description adds valuable behavior beyond annotations by explaining the returned display contents, the SI-base-unit meaning of value, the display text field, and the METER_BUSY error condition.

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 dense but front-loaded around the snapshot concept and then systematically lists returned components. The parenthetical enumerations are somewhat long, but every clause earns its place by clarifying return content or error behavior.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so well by naming the display fields, units, and METER_BUSY state. It is not fully complete on sibling selection or the max_wall parameter, but the core read behavior is sufficiently covered.

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 only parameter, max_wall, is fully documented in the input schema including its default, bounds, and timeout behavior. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the resource and scope: 'One snapshot of the meter display,' then enumerates what the snapshot includes. It is specific enough for an agent to understand the tool, but it does not explicitly contrast itself with siblings such as live or status.

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

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

The phrase 'One snapshot' implies this is for a single sample rather than continuous streaming, which is useful context against the live sibling. However, the description never explicitly states when to use this tool instead of live, status, or memory, nor does it name alternatives.

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 only supply readOnlyHint=true; the description independently reinforces safety ('Never changes the meter') and adds behavior an agent cannot get elsewhere: the check includes a live reading that can take up to 5 s, and failures are surfaced as SELFTEST_FAILED with measured vs expected values. It does not quantify total runtime or describe the success-path return shape.

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 read-only nature and then the concrete check list. The enumeration is dense but every item earns its place by telling the agent what a failure could mean; no filler or restated title beyond 'Self-test'.

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

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

For a zero-required-parameter, no-output-schema tool, the description covers what is validated and how failure is reported, which is the information an agent needs. The only soft spot is no guidance on reading/acting on the result or on choosing max_wall, minor given the 100% schema 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 description coverage is 100%, so the sole parameter max_wall (default 120 s, TIMEOUT on expiry) is already fully documented in the schema. The description says nothing about the time limit or how a 5 s live reading interacts with it, 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?

Names a specific verb and scope ('Read-only health check of adapter, link and meter') and then enumerates exactly what is verified — advertising, connection, meter attached, firmware, ID, display snapshot, live reading within 5 s, batteries. This is clearly distinguishable from data-reading siblings like read, live, status, and query.

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 'health check' framing implies when to reach for it (diagnosing connectivity/setup problems), but there is no explicit when-to-use versus status/live, and no stated prerequisites or exclusions. An agent must infer that this is the diagnostic path rather than the data-retrieval path.

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 readOnlyHint annotation, the description discloses the exact returned information, defines meter.attached false as no powered meter, and explains NOT_FOUND as the adapter not advertising with a concrete recovery action. That is unusually rich behavioral context for a read-only status 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?

The description is dense but front-loaded: the core status question comes first, followed by returned fields and failure semantics. It is slightly run-on in listing adapter and meter fields, but nearly every phrase carries useful 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?

With no output schema, the description carries the return-value burden and does so by naming adapter address, firmware, battery, meter model, serial, memory, clock, saved-item count, and key failure states. It omits response formatting details, but is otherwise complete for this read-only status probe.

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 only parameter, max_wall, is fully documented in the schema with its default, bounds, and TIMEOUT behavior. The description adds no additional meaning about this parameter, so the schema baseline of 3 is appropriate.

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

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

The description states a precise question and resource: whether the IR3000 FC adapter is reachable and a Fluke 287/289 meter is attached and powered. It also enumerates the adapter and meter fields returned, so an agent can tell this is a connectivity/status probe rather than a measurement read or self-test.

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 implies the tool is used to verify adapter and meter presence before other operations, and gives troubleshooting guidance for NOT_FOUND. However, it does not explicitly say when to prefer this over selftest, log_status, or query, nor does it state prerequisites beyond the NOT_FOUND remedy.

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