measure

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

The annotations already declare non-read-only, non-destructive, idempotent, and closed-world behavior. The description adds important context beyond those annotations: each requested item is added to the measurement bar, at most 5 are shown with older ones scrolling off, and null means the scope could not measure the item.

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 with the purpose, then parameter formats, then the side effect. The long item enumeration is necessary because the schema provides no parameter descriptions, and there is little 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 0% schema parameter coverage, the description supplies enough parameter vocabulary, return-null semantics, and side-effect context to use the tool correctly. It could still be more complete about the output shape and about when to prefer alternatives like scpi_query or clear_measurements.

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. It fully specifies channel values (1-4 or CHAN1-CHAN4) and enumerates every accepted item abbreviation plus long forms, and it explains the meaning of a null measurement result.

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 the tool returns the scope's automatic measurements for one channel and enumerates the measurable items. It is specific about the resource and action, but it does not explicitly distinguish itself from siblings such as clear_measurements or scpi_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?

There is no explicit when-to-use guidance, prerequisites, or alternative-tool routing. The agent must infer that this is the tool for obtaining automatic measurements rather than clearing them or using a lower-level SCPI query.

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