km003c-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KM003C_SERIAL | No | Pick a meter by USB serial number when several are attached | |
| KM003C_COM_PORT | No | Override the trigger's virtual serial port (e.g. COM14) | |
| KM003C_LIBUSB_DLL | No | Use a specific libusb-1.0.dll instead of the bundled one |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| device_infoA | Identify the attached KM003C: model, hardware/firmware version, serial, trigger port. |
| measureA | Read VBUS/IBUS/power, CC1/CC2, D+/D-, VDD and temperature (V, A, W, °C). With samples > 1 the readings are taken interval_ms apart and mean/min/max are returned for vbus_v, ibus_a and power_w. Positive current flows from the meter's USB-C receptacle (input) to its plug (output). |
| pd_statusA | Read the PD-side status snapshot (timestamp, VBUS, IBUS, CC1, CC2). Not available while a PD capture runs, because reading would consume captured events. |
| stream_startA | Start high-rate VBUS/IBUS sampling in the background (2, 10, 50 or 1000 samples/s). Optionally writes every sample to csv_path. Use stream_status / stream_samples while running and stream_stop for the final statistics (energy, charge, min/max/mean). |
| stream_statusB | Running state, error (if any), live statistics and the most recent samples. |
| stream_samplesB | Return up to max_samples evenly spaced samples from the running stream's buffer. |
| stream_stopB | Stop the stream and return its statistics. |
| pd_capture_startA | Start capturing USB PD traffic (messages, attach/detach) in the background. |
| pd_capture_readC | Page through captured PD events from index |
| pd_capture_stopA | Stop the PD capture; captured events stay readable until the next start. |
| trigger_detectA | Detect the fast-charge protocols the attached charger supports ( extended=True also probes VOOC/MTK PE ( |
| trigger_enterC | Enter a trigger protocol: pd, ufcs, qc, fcp, scp, afc, vfcp, sfcp, tfcp, bc, apple. |
| trigger_pd_source_capsB | Ask the charger for its PD Source_Capabilities ( |
| trigger_pd_requestA | Request PDO Makes the attached charger raise VBUS on the meter's output; disconnect sensitive loads first. |
| trigger_fast_chargeA | 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. |
| trigger_resetA | Reset the protocol trigger to its initial state (re-opened on the next trigger call). |
| trigger_closeB | Leave protocol trigger mode ( |
| trigger_rawC | Send any trigger command from ChargerLab's virtual serial port sheet verbatim. Makes the attached charger raise VBUS on the meter's output; disconnect sensitive loads first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools map to a distinct resource+action: measurement, streaming, PD capture, and protocol triggers are cleanly separated, and the start/status/samples/stop quadrilogy is unambiguous. The only fuzzy edges are within the trigger group, where trigger_enter (which accepts 'pd'), trigger_fast_charge, and trigger_pd_request could be confused, and trigger_raw overlaps with all of them as an escape hatch.
The set uses a systematic prefix scheme (stream_*, pd_capture_*, trigger_*) with verb or noun suffixes applied consistently inside each group. Minor deviation: the three ungrouped tools mix noun and verb forms (device_info, pd_status vs measure), but the pattern is still highly readable.
18 tools is on the upper end but each supports a real capability: device identification, one-shot measurement, background streaming, PD traffic capture, and the multi-step trigger workflow. Nothing looks redundant enough to be obviously removable, though the trigger family alone accounts for seven tools.
The surface covers the device lifecycle well: identify, measure, high-rate stream with CSV output and final statistics, PD capture with paging, and protocol entry/request/reset/close. Gaps are minor: no tool to query currently configured PDO/trigger state after entry, and no raw PD message transmit, but trigger_raw provides a general fallback for unsupported commands.