Set the Power Profiler Kit II measurement mode to AMPERE for current measurement with external supply or SOURCE to power a DUT, then set source voltage before capture.
设置测量模式:AMPERE(电流表,外部供电)或 SOURCE(源表,PPK2 给 DUT 供电)。
SOURCE 模式采集前还需 set_source_voltage。
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes |
Changes observed during successful MCP inspections.
v1.0.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 the cross-tool dependency (SOURCE requires set_source_voltage before capture), but says nothing about whether switching modes interrupts an active capture, whether the setting persists, or what permissions/connection state are needed for this mutation.
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 mode choices front-loaded and the SOURCE prerequisite appended as a second, actionable sentence. No filler, though the phrasing is terse enough that a reader may want slightly more framing.
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 covers the essential facts an agent needs: the two valid modes, their semantics, and the SOURCE-mode prerequisite. Missing only peripheral state/edge-case behavior (mid-capture switching, persistence), which is a minor gap for a single-parameter setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema defines no enum for `mode`, so the description is the only source of accepted values. It compensates well by naming and explaining both legal values, though it does not state case-sensitivity or the default.
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+resource (设置测量模式) and immediately enumerates the two valid values, AMPERE and SOURCE, with a short gloss of each. An agent can distinguish this from siblings like set_source_voltage or set_dut_power 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?
Explains the condition that selects each mode (AMPERE = external supply, SOURCE = PPK2 powers the DUT) and adds the prerequisite that SOURCE mode requires set_source_voltage before capturing. It stops short of stating when *not* to use the tool, whether mode can be switched mid-capture, or the default mode, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.