Request a target voltage and current from a connected charger via fast-charge protocols (QC, FCP, AFC, SCP, UFCS) to raise VBUS; disconnect sensitive loads first.
Request a voltage via qc, qc3, fcp, afc, sfcp, scp, vfcp, tfcp or ufcs.
Makes the attached charger raise VBUS on the meter's output; disconnect sensitive loads first.
| Name | Required | Description | Default |
|---|---|---|---|
| request | No | ||
| protocol | Yes | ||
| current_ma | No | ||
| voltage_mv | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key side effect: the attached charger raises VBUS. The safety warning is valuable, but it omits reversibility, reset requirements, error behavior for unsupported protocols, and whether voltage/current are requested or guaranteed.
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 two tightly written sentences with no filler. The purpose is front-loaded, followed immediately by the physical effect and safety warning.
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 hardware-control tool with no annotations, no output schema, and 0% schema description coverage, the definition provides the core purpose and a strong safety warning. It remains incomplete because it does not cover reset semantics, expected return/status behavior, supported voltage ranges, or the meaning of all parameters.
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 must compensate. It usefully enumerates valid protocol strings such as qc, qc3, fcp, afc, sfcp, scp, vfcp, tfcp, and ufcs, but leaves the request and current_ma parameters unexplained and gives no voltage range or units context beyond the parameter name.
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 and resource: requesting a voltage through a named set of fast-charge protocols. It also clarifies the physical effect, raising VBUS on the meter's output, which distinguishes it from status or measurement siblings.
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 warning to disconnect sensitive loads first gives an important usage precondition for this hardware-control tool. However, it does not explicitly say when to use this instead of sibling tools such as trigger_pd_request, trigger_raw, or trigger_reset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.