PPK2 MCP Server

Overview Schema Source Related Servers Discussions Admin

set_source_voltage

Sets the PPK2 source voltage in millivolts (800–5000) to power a DUT or define VDD for current conversion; values outside the range are clamped automatically.

Instructions

设置电压(mV,800-5000,域外自动夹紧)。

SOURCE 模式:稳压器实际输出;AMPERE 模式:作为电流换算的 VDD 估计值。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "millivolts": "<millivolts>"
    },
    "name": "set_source_voltage"
  }
}

Input Schema

Name	Required	Description	Default
`millivolts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose important behavior: the 800-5000 mV range and that out-of-range values are automatically clamped rather than rejected. It stops short of noting permissions, persistence, or interaction with mode state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight lines with the range and clamping front-loaded, then the mode-dependent interpretation. Every sentence carries information; only the mode clause is slightly terse and could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema or annotations, the description covers units, bounds, clamping, and mode-dependent effect, which is enough to call it correctly. It could note the dependency on set_mode having been invoked, but no critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 supplies the unit (mV) and a concrete numeric range plus clamping semantics for the single parameter. That meaningfully exceeds the bare "integer" schema type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("设置电压" / set voltage) with units and valid range, so the agent knows exactly what the tool does. It does not explicitly differentiate itself from siblings like set_dut_power, but the resource and constraint set are unambiguous.

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

Usage Guidelines3/5

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

Explains that meaning depends on the active mode (SOURCE = actual regulator output, AMPERE = VDD estimate for current conversion), which is genuine usage context. However, it never says when to prefer this over alternatives or whether a mode must be set first, so guidance is implied rather than explicit.

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