Check whether the oscilloscope's previous save operation has completed by querying storage status; returns done=True when saving is finished.
Query the storage state (:SAVE:STATus?). Returns done=True when the previous saving operation has completed (firmware returns 1).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does 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 usefully discloses that done=True corresponds to firmware returning 1, i.e. the previous save completed. It does not mention polling cadence, timeouts, or whether the status resets, which an agent would want for a completion-check query.
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 sentences, front-loaded with the action and the SCPI form, followed by the one behavioral fact that matters (done=True semantics). 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?
An output schema exists, so the description needn't restate the return structure; it adds the key semantic mapping of done to completion. For a simple parameterless query tool this is nearly complete, missing only the relationship to wait_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?
The tool takes zero parameters, so no parameter documentation is needed and the baseline is 4. The description correctly indicates a parameterless query.
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 (Query) and resource (storage/save status), and even names the underlying SCPI command (:SAVE:STATus?). An agent can tell it concerns save-operation state rather than general device status. It stops short of distinguishing itself from the sibling wait_complete, which addresses a similar concern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (poll this after a save to learn whether the save finished), but there is no explicit when-to-use, when-not, or routing to the obvious alternative wait_complete. With a sibling that appears to serve the same goal, the absence of a disambiguation is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.