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

No annotations are provided, so the description must carry the behavioral burden. It repeats the schema's omission behavior but discloses nothing about side effects, reversibility, permissions, or error conditions for this mutation 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?

One short sentence, front-loaded with the primary action and immediately explaining the omitted-resource case. 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?

For a simple one-parameter close tool with an output schema and full schema coverage, the description tells the agent enough to invoke it correctly. It is less complete on the safety/behavioral side because no annotations exist, but the return values are covered by the output schema.

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 the single `resource` parameter is fully documented in the schema. The description only restates the same omission semantics, adding no syntax or format detail beyond the structured field.

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 ('Close') and resource ('open instrument') and defines the default scope when no resource is supplied. It is easy to distinguish from siblings like open_instrument or list_instruments.

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 explains the conditional behavior: close one instrument, or all open instruments if resource is omitted. However, it does not name alternatives such as forget_instrument or state when not to use 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?

With no annotations, the description carries the full behavioral burden. It discloses the precondition (already-open instrument), but says nothing about whether changes persist, whether they affect concurrent sessions, required permissions, or failure modes for a mutation 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?

A single efficient sentence with the key constraint front-loaded. It is well-sized, though the extreme brevity is what leaves the parameter and behavioral 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 needn't be explained, but for a 5-parameter mutation tool with zero annotation coverage and 0% schema coverage, the description documents only 2 of 5 parameters and omits any behavioral context an agent would need.

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 5 parameters, so the schema provides no guidance. The description only names timeout and terminators, leaving 'resource' and 'baud_rate' completely unexplained in both the 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 ('Change') and resource ('timeout and terminators') scoped to a VISA session on an already-open instrument. It's distinguishable from open_instrument and scope_configure, though it doesn't explicitly name a sibling.

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 'on an already-open instrument' implies the prerequisite that a session must exist, which is useful context. However, it never names an alternative tool or states when to prefer this over scope_configure or re-opening the instrument.

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 safety is covered. The description adds genuinely useful behavior beyond that: discovery is unreliable ('many scopes do not advertise') and empty results are expected rather than errors. That expectation-setting is exactly the context annotations cannot convey.

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 mechanism and services, followed by the operational caveat. No filler; each sentence 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?

An output schema exists, so return shape needn't be restated. For a zero-required-param, read-only discovery tool, the description covers purpose, expectation of empty results, and fallback routing — everything needed 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% (timeout_s is fully documented with bounds and default), so the baseline is 3. The description says nothing about the timeout or browse duration tradeoff, adding no 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?

States a specific verb (browse) and resource (mDNS for LXI, VXI-11, HiSLIP, SCPI-raw services), which cleanly separates it from list_instruments (known instruments) and open_instrument (direct connect). An agent can identify the tool's role 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?

The second paragraph tells the agent what an empty result means and routes to the fallback ('open by IP instead'), which implicitly points at open_instrument. It lacks an explicit statement of the primary trigger (e.g. 'use when the instrument's address is unknown'), so it is strong but not fully prescriptive.

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 description does add real behavioral context beyond the annotations: the export is full-resolution (no downsample) and the CSV columns are t_s, v. However, it explicitly states the tool writes a file to disk, which sits in tension with readOnlyHint=true (a filesystem write is an environment modification); overwrite behavior, path/directory requirements, and permissions are not covered. The write disclosure is honest, but the description and annotations pull in different directions.

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 and scope, followed by output format then routing guidance. No filler and no repetition of schema or annotation 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, and the routing guidance is complete. Still, for a 5-parameter export tool with 40% schema coverage, the undefined dialect/resource parameters and the disk-write semantics (overwrite, path expectations) leave gaps an agent must guess at.

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 40%, and the two undocumented parameters (dialect, resource) get no explanation in the description either. 'Fetch a channel trace' only loosely implies the channel parameter, and nothing clarifies how fmt interacts with the path suffix or what dialect/resource control. The description does not 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 ('Fetch a channel trace and write the full record ... to disk') with the key scoping qualifier 'no downsample'. It explicitly names the sibling it is not (scope_capture_waveform) and characterizes that sibling's role, so an agent can separate the two 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?

Provides explicit when-to-use guidance ('Use this for archives') and names the alternative with its own condition ('scope_capture_waveform is for a short preview in the chat'). Nothing about tool selection 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the manual is downloaded into a local brain and indexed, but does not mention permissions needed, network access, whether existing indexed content is overwritten, failure behavior, or other 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?

The description is a single front-loaded sentence with no wasted words. It is concise, though its brevity leaves important behavioral and parameter details unaddressed elsewhere.

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?

Although an output schema exists, the description is incomplete for a tool with no annotations and a partially documented schema. It does not explain the resource parameter, prerequisites, storage implications, or when an agent should prefer this tool over siblings such as learn_instrument.

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 50%. The url parameter is well described in the schema itself, but the resource parameter has no schema description and is not explained in the tool description. The description adds no parameter meaning beyond what is already in the structured 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 states a specific verb+resource: downloading this model's user/programming guide and indexing it locally. It clearly differs from many sibling tools like open_instrument or scope_capture_waveform, but it does not explicitly differentiate itself from learn_instrument or search_scope_knowledge.

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 versus alternatives, nor any listed prerequisites or exclusions. The only implied usage is that an agent should call it to obtain a model manual, but nothing states when that is appropriate.

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 burden. It does disclose that removal is persistent ('from disk'), but says nothing about irreversibility, whether the instrument connection is affected, or permission requirements for a delete 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?

A single front-loaded sentence with no waste. It is appropriately sized, though the brevity comes with the specification gaps noted elsewhere.

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 single parameter is fully documented in the schema. However, for an unannotated destructive operation, missing notes on irreversibility and on the learn/forget lifecycle leave it only minimally 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 100% and the schema already explains the identity param ('*IDN? string or profile_key from list_learned_instruments'). The description adds only the 'per-scope' framing, which is marginal; 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 ('Delete') and resource ('saved per-scope profile'), which maps cleanly onto 'forget' and separates it from open/close/list siblings. It stops short of naming a sibling it is not, 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?

There is no guidance on when to use this versus close_instrument, list_learned_instruments, or learn_instrument, and no stated prerequisites. The agent must infer that this is the inverse of learn_instrument.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the call selects a vendor dialect, which affects how later queries are interpreted. It stops short of saying whether that dialect persists, applies session-wide, or is required before query, so the add is useful but partial.

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 tight sentence with the primary action front-loaded and no filler. Nothing is padded and nothing essential is buried.

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 safety. What is missing is workflow context: whether identify must precede query/write calls and what the chosen dialect implies for downstream tools. Adequate but with a clear gap for a tool that gates later behavior.

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 'resource' parameter is fully documented in the schema (100% coverage), including the 'omit if exactly one instrument is open' default behavior. The description adds nothing about the parameter, which is acceptable given the schema does the work, so the 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 names a concrete verb and target ("Query *IDN?") plus a distinctive side effect ("pick a vendor dialect"), so an agent knows exactly what the tool does. It does not, however, differentiate itself from siblings such as learn_instrument or open_instrument, which plausibly also touch instrument identity.

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 when-to-use guidance, no prerequisites (e.g. that an instrument must be opened first), and no indication of how this differs from learn_instrument or list_instruments. Usage must be inferred entirely from the name and sibling 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?

The description is genuinely informative: it discloses local file writes under ~/.local/share/pyvisa-mcp/ (or PYVISA_MCP_MEMORY), next-session reuse, and optional web fetching via fetch_manual. However, persisting files and searching the web conflicts with the declared readOnlyHint=true and openWorldHint=false, so the behavioral claims and the annotations are inconsistent.

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, front-loaded with the core action before storage location and refresh behavior. No filler; each sentence adds a distinct fact (what it does, where it persists, how to refresh).

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 the description covers persistence, location override, cross-session reuse, and refresh flags. The remaining gap is the mismatch with the read-only/open-world annotations rather than missing description content.

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 explains deep, resource, manual_url, and fetch_manual in detail. The description only adds the refresh framing for deep/fetch_manual, which is a useful pointer but largely duplicates the schema; baseline 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?

States a specific verb ('Build (or reload)') and resource ('a local brain for this exact *IDN?'), and clarifies what the brain contains (profile, remembered SCPI, manual text). It is distinguishable from siblings like list_learned_instruments and forget_instrument, though the 'local brain' metaphor is only loosely standard terminology.

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

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

The description implies when to run it (first-time setup or refresh) and notes the refresh flags, but never explicitly contrasts it with open_instrument, identify, or list_learned_instruments. Usage is inferable rather than stated as explicit 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 readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely non-obvious behavioral context by disclosing that discovery is local-only and that LAN instruments are frequently missed. It doesn't describe output shape, but an output schema exists so that is acceptable.

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 scope statement front-loaded and the caveat plus remediation immediately after. Every clause carries actionable information; 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?

For a single-parameter, read-only discovery tool with an output schema, the description covers scope, the critical gotcha, and the alternative routes. An agent has everything needed to decide whether to call it and what to do when it returns nothing useful.

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 query parameter, its default, and the SOCKET-hiding behavior are already fully documented in the schema. The description adds no parameter-level detail beyond that, which is the expected baseline when the schema does the work.

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 (discover) and resource (local VISA resources) and enumerates the covered transports (USB, GPIB, serial, some LAN). It also implicitly distinguishes itself from the sibling discover_network_instruments by calling out what it does NOT find.

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 names the failure mode (network oscilloscopes frequently do NOT appear) and routes the agent to two concrete alternatives with the triggering condition: open_instrument by IP for known addresses, discover_network_instruments for network scanning. Nothing 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 readOnlyHint=true and openWorldHint=false, so the safety profile is already known. The description adds useful context that the data comes from previous learn_instrument calls and is machine-local, but it doesn't discuss freshness, persistence, or 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?

The description is a single, front-loaded sentence fragment with no wasted words. It efficiently communicates the data source and scope for a simple listing 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?

For a zero-parameter, read-only listing tool with an output schema and annotations, the description gives enough context about what data will be returned. The main gap is the lack of routing guidance relative to list_instruments, but the core purpose is clear.

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, and schema description coverage is 100%, so there are no parameter semantics to clarify. Per the rubric, zero-parameter tools receive a baseline of 4 when no param information is needed.

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 resource precisely: profiles saved from previous learn_instrument calls on this machine. It implicitly differentiates from general instrument lists by scoping to learned profiles, but does not explicitly contrast with the sibling list_instruments 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?

It gives no explicit when-to-use guidance, no prerequisites, and no alternatives. The origin from learn_instrument suggests a context, but the agent must infer that this tool should be called to review previously learned profiles.

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 usefully discloses a non-obvious normalization behavior (bare IP vs host:port mapping to INSTR vs SOCKET), but says nothing about session lifecycle, idempotency of re-opening, or permissions, leaving real gaps for a 6-param connection 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?

Two tightly written sentences with the core action and the resource-format rule front-loaded; nothing is wasted or repetitive.

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 described, and the resource-format guidance covers the required parameter. However, for a tool exposing serial/termination/timeout parameters, the absence of any explanation for those knobs and the lack of lifecycle pointers (e.g., pairing with close_instrument) leaves it only partially 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 only 17% (only 'resource' is documented in the schema). The description adds valuable format semantics for that one parameter, but baud_rate, timeout_ms, read_termination, and write_termination are unexplained in both schema and description, and 'identify' is only implied by 'optionally query *IDN?'.

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 ('Open an instrument') and adds the optional identify behavior. It is clearly distinguishable from siblings like close_instrument and list_instruments, though it never names them 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 concrete guidance on which resource format the agent should pass ('Bare IPs become TCPIP::<ip>::INSTR. host:port becomes a raw TCP SOCKET') and even names typical ports and a specific device, which is genuinely useful usage context. It lacks explicit when-not-to-use or alternative-tool 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=true and openWorldHint=false, so the safety profile is covered. The description usefully adds the return encoding ('ASCII response'), but says nothing about blocking behavior, timeouts, or what happens on an instrument error — relevant for an I/O call to hardware.

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 zero filler; the verb, the input type, and the output format all land 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?

An output schema exists, so return values need no explanation. However, for a 3-parameter hardware I/O tool the undefined 'confirm' parameter (likely a confirmation gate) and the unaddressed target 'resource' leave real gaps that the description does nothing to close.

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 33%: only 'command' is documented ('usually ending with ?'), while 'confirm' and 'resource' are unexplained in both schema and description. With coverage below 50%, the description is expected to compensate, and it adds no parameter meaning at all.

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 ('Send') and resource ('a SCPI query') and names the output format ('ASCII response'), which implicitly separates it from the binary sibling. It is clear but never names query_binary or write explicitly, so the differentiation is inferential rather than stated.

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 statement. The word 'ASCII' weakly implies that binary-response queries belong to query_binary and that mutation belongs to write, but the agent must infer this rather than being told.

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 and openWorldHint=false; the description adds real behavioral detail beyond that — the default return shape (stats plus short preview), the capping of arrays, the CSV side effect of save_path, and the protocol hazard that a terminator byte can appear inside the payload. None of this is derivable 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 default behavior before options and alternatives. No filler, and the most decision-relevant fact (default is a preview, not the data) comes first.

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 description still covers default output, alternatives and the query() hazard. It falls short only on the undocumented parameters (max_return cap value, endianness, resource), which would matter for a tool with 8 params.

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 50%, and the description elaborates only save_path (keeps the full record, written as CSV), return_values (capped array) and the preview concept. Four parameters — resource, max_return, is_big_endian, preview_points — carry no meaning in either the description or the schema titles, so the description partly compensates but leaves real gaps.

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 ('Read an IEEE binary block') and immediately frames the tool against its nearest sibling by warning that query() is unsafe for binary payloads. An agent can distinguish it from query, scope_capture_waveform and export_waveform 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?

Explicit routing rules: default behavior, save_path= for the full record, return_values=true for a capped array, and two named alternatives for oscilloscope traces. It also names the anti-pattern ('Do not use query() for binary') with the reason, which is exactly the exclusion guidance most descriptions lack.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, yet the description adds genuine behavior: it is a draining loop that repeatedly issues SYST:ERR? rather than a single read. It does not disclose what happens if the queue exceeds the cap or whether errors are consumed irretrievably.

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, each earning its place, with the core mechanism front-loaded before the usage cue.

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 the description omits parameter meaning for a 0%-coverage schema and creates an unresolved tension with max_errors: it claims the queue is popped 'until empty' while the schema caps errors at 20 by default, leaving the agent without guidance on that interaction.

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, yet it never mentions either parameter. 'resource' (which instrument, presumably defaulting to the active session) and 'max_errors' (cap on the drain loop) are left entirely for the agent to infer from property names.

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 ('Pop SYST:ERR?') and names the actual mechanism (draining the instrument error queue until empty). No sibling tool covers error retrieval, so it is unambiguous even without explicit sibling contrast.

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?

'Call this after any failed command' gives a clear trigger condition for invocation. It stops short of stating when not to call it or how it relates to write/query siblings that would surface the same failures.

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 it does disclose the key side effect: autoset rewrites vertical/horizontal/trigger and requires an explicit confirm flag. It stops short of describing what run/stop/single do to ongoing state or whether the instrument must be open first, so the disclosure is good but partial.

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 capability and followed by the one high-risk caveat. No filler, every sentence 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?

An output schema exists, so return values need not be explained, and the autoset warning covers the main hazard. Still, the tool has four parameters and the description leaves dialect/resource entirely unexplained, which is a real gap for a control tool whose behavior depends on target selection.

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%: 'action' and 'confirm' are already documented in the schema, and the description's autoset/confirm note merely restates the schema's confirm description. The remaining parameters, 'dialect' and 'resource', are undocumented in both places and the description does nothing to compensate.

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 ('control acquisition') and enumerates the exact action set (run, stop, single, autoset), so an agent immediately knows what this does. It implicitly separates from siblings like scope_configure or scope_capture_waveform, but never names an alternative to sharpen 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?

The description gives a concrete usage rule for one branch – 'Autoset changes vertical/horizontal/trigger; pass confirm=true' – which is actionable. However, there is no guidance on when to prefer this over scope_configure, or whether run/stop/single need any preconditions, leaving usage largely implied.

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 and openWorldHint=false, so safety is covered, and the description adds real context beyond that: it discloses the dialect resolution path and, importantly, that output is downsampled and accompanied by vmin/vmax/vmean/vpp to keep the payload small. That is behavior an agent needs to know for a digitizing/truncating read. No permissions or rate-limit notes, though.

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 purpose is front-loaded ahead of the dialect and payload details. The line break mid-paragraph is slightly odd but harmless.

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 prose, and annotations cover the safety profile. The description is adequate for invocation mechanics but leaves the resource parameter undocumented and gives no routing guidance among the many scope_* siblings, which is the biggest omission for a tool in this crowded namespace.

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 50%: channel and max_points are documented in the schema, while dialect and resource have titles only. The description partially compensates by explaining that dialect can be passed explicitly or inferred from *IDN?, but resource remains unexplained in both places. Marginal added value over 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: "Read a scaled voltage-vs-time trace from one channel," which is unambiguous about what is produced. However, it never distinguishes itself from close siblings like scope_acquire, scope_measure, or export_waveform, which an agent will have to disambiguate on its own.

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 pick this tool over scope_acquire (also an acquisition tool) or export_waveform (which likely also returns trace data). The only usage-adjacent hint is that the dialect comes from *IDN? or the dialect parameter, which is a mechanics note, not selection 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?

No annotations are provided, so the description carries the full disclosure burden. It does add one genuinely useful behavioral fact — 'Only provided fields are sent' (partial-update semantics) — plus the units convention. But for a mutation tool it says nothing about whether changes persist, whether a session/resource must be open, or what happens on invalid values.

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 free of filler; the units note is compact and useful. It is arguably a touch thin given a 13-parameter surface, which keeps it from a perfect score.

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 description does cover the main configuration groups. Still, with no annotations and 13 loosely documented parameters, it leaves substantial gaps: session prerequisites, the meaning of probe/channel/resource, and any error or persistence behavior.

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 ~15%, so the description must compensate, and it partly does: it names the parameter groups (scale, offset, coupling, timebase, trigger) and supplies the units (volts, seconds) that the schema omits for offset_v/trigger_level. However, roughly half the 13 parameters — probe, channel, dialect, display, resource, trigger_source — are never explained in the schema or the 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?

The verb 'Set' is paired with the specific resources it manipulates (channel scale/offset/coupling, timebase, edge trigger), so an agent can immediately tell this configures an oscilloscope. It does not, however, explicitly differentiate itself from adjacent siblings like scope_acquire or scope_capture_waveform, relying on the reader to infer the config-vs-measure split.

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 reach for this tool versus scope_acquire, scope_capture_waveform, or query. Nor does it state any prerequisite such as an open instrument session, which matters given the open_instrument/close_instrument siblings. The reader gets no routing help.

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 and openWorldHint=false, so the safety profile is covered. The description adds that measurements come from the instrument's own measurement engine (device-side, not local math on a captured trace), which is modestly useful, but says nothing about latency, error behavior, or what happens if a kind is unsupported.

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 tight sentence with the essential value front-loaded and no filler. It is efficient, though arguably too sparse given four parameters and instrument-dialect concerns.

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 four parameters at 25% coverage, three undocumented parameters (channel, dialect, resource) and zero usage guidance, the description leaves real gaps for an agent to call this correctly against a multichannel scope.

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 25% — only 'kinds' is documented, listing the valid subset and the vpp+freq default. The description's 'Vpp, frequency, etc.' merely echoes that enum, adding nothing, while channel, dialect, and resource are left unexplained 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 (ask/query), resource (the scope's measurement engine), and illustrative outputs (Vpp, frequency), so the agent knows this retrieves computed measurements rather than raw data. It does not name or contrast with siblings like scope_capture_waveform or scope_acquire, which makes it just 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?

There is no when-to-use guidance at all — nothing says to prefer this over scope_capture_waveform/export_waveform when only scalar values are needed, nor any prerequisite (e.g., a session or channel must be open). The agent must infer the use case entirely.

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 the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, yet the description still adds genuine behavioral detail: it disables the VISA termchar so an embedded 0x0A is not read as EOF, and it errors on non-image payloads instead of silently returning junk. That is exactly the kind of non-obvious context that prevents confusing failures. It does not say where/how the file lands.

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, front-loaded sentences with zero filler: the action first, then two concrete behavioral guarantees. Each sentence 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?

With four parameters, two of them entirely undocumented and no output schema, the description leaves meaningful gaps: what dialect/resource do, whether the return value is the written path, and what happens on timeout. For a tool whose schema carries so little, more explanation is warranted.

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 25% (just 'path'), and the description mentions no parameters at all. Two parameters, dialect and resource, are undocumented in both the schema and the description, and timeout_ms behavior/default is likewise unaddressed. The description does not 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?

The description states a specific verb+resource ('Grab the scope display') and enumerates output formats (PNG/BMP/JPEG), making it clearly distinguishable from sibling waveform tools like scope_capture_waveform and export_waveform. It stops short of explicitly naming those siblings, so 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?

There is no statement of when to use this versus scope_capture_waveform, export_waveform, or scope_acquire in a crowded sibling set. Usage is only implied by the word 'screenshot'; no prerequisites 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower; the description adds that the corpus is local, previously validated knowledge rather than live vendor docs. It does not discuss result ranking, empty-store behavior, or how limit interacts with relevance.

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: first states what is searched, second states the prerequisite and the payoff. No filler, and the core purpose is 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?

An output schema exists, so return format need not be explained, and annotations cover the read-only/local profile. The remaining gap is the undocumented resource parameter, which a caller cannot reason about from description or 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 only 33%: query is documented with good examples, but resource is a bare nullable string with no meaning anywhere, and limit is only bounded by min/max/default. With low coverage the description is expected to compensate, and it adds nothing about what resource scopes to or how limit affects results.

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+resource: it searches a local, persisted knowledge store made of saved manuals, HELP headers, and previously working SCPI. The phrase 'already worked on this box' cleanly separates it from fetch_manual (fetch new) and suggest_scpi (guess/generate), so an agent can pick it without opening sibling schemas.

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?

Explicit prerequisite: 'Call learn_instrument / fetch_manual first,' which tells the agent this is a reuse step, not a discovery step. It names the complementary tools, but does not state when NOT to use it (e.g., if nothing has been learned yet) or what happens on an empty store.

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 readOnlyHint=true, but the description says 'Optionally execute it' and the schema clarifies execute=true 'send[s] the commands' to the instrument, which mutates device state (set mV/div, trigger, reset). A tool that can drive hardware is not read-only, so the description contradicts the annotation. It otherwise adds the useful dialect-default rule ('Uses *IDN? dialect unless you pass dialect=').

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, front-loaded with the core purpose and free of filler. Both the dialect rule and the 'prefer over inventing' guidance earn their space.

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 spelled out, and the dialect-dependent behavior is covered. Still, with 60% schema coverage the description leaves channel/resource semantics unexplained and, given the write capability behind execute=true, should say more about the consequences of the execute path.

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 60% and five params are present. The description adds real meaning for dialect (defaults to the *IDN? dialect unless overridden) and confirms the execute toggle, but channel and resource are undocumented in both schema and description, leaving the semantics partly unaddressed. Baseline 3 for the partially-covered 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 transformation: 'Map a natural-language intent to vendor-correct SCPI', plus the option to execute. An agent can tell this apart from write/query siblings (which take literal SCPI) without opening the schema. It stops short of naming those siblings, 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?

'Prefer this over inventing commands' gives one clear routing rule for the case where the agent lacks the exact command. However it never states when NOT to use it (e.g. when you already have literal SCPI, use write/query) and does not warn that execute=true actually sends commands to hardware. Usage is implied more than specified.

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 present, so the description carries the full burden. It usefully discloses the fire-and-forget semantics ('no reply'), which is the main behavioral trait, but says nothing about error handling, whether execution blocks, or that commands like *RST are destructive/irreversible outside the schema's confirm note.

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 sentence, leading with the verb and the decisive 'no reply' constraint before the examples. Zero wasted words and nothing buried.

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 core no-reply semantic is covered. However, for a 3-parameter tool with zero annotations, it omits prerequisite/error context and any mention of the `resource` parameter's role, leaving gaps an agent must fill by opening the schema.

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 67%, so the schema already documents `command` and `confirm` in detail. The description's examples (settings, *RST, :RUN) illustrate what `command` accepts and implicitly connect *RST to the confirm requirement, but it adds no syntax or format guidance and says nothing about the `resource` parameter.

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 (Send) and resource (SCPI command) and pins the key scope constraint with 'with no reply,' which is what separates it from the sibling `query`. Concrete examples (settings, *RST, :RUN) make the intent unmistakable, though it never names the sibling it complements.

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?

'with no reply' implies the when-to-use condition and the examples show the class of commands, but the alternative (`query` / `query_binary`) is never named and there is no explicit 'use query when you expect a response' rule. Usage is inferable rather than stated.

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