UsbServoController
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| mock | No | Run the MCP server without hardware. Passed to the MCP server as "--mock". | |
| port | No | Serial port to use, e.g. COM5. Passed to the MCP server as "--port", "COM5". |
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 |
|---|---|
| board_statusB | Rail current/voltage, faults, protection limits, and every channel's name, mode, travel limits, speed and current position (0 = off). |
| move_servosA | Move one or more servos and wait until they arrive. |
| disable_servosB | Stop driving the given channels (numbers or names); the servos go limp. |
| stop_allA | Panic stop: every channel off immediately. |
| list_posesC | Poses and the sequence saved from the GUI (servogui.json). |
| go_to_poseB | Move to a saved pose (see list_poses) and wait until it arrives. |
| play_sequenceA | Play the GUI's saved sequence of poses (move and hold times as saved),
repeated |
| read_analogB | Read channel 0-7 as an analog input (0-4095 counts, 0-3.3 V). |
| measure_currentB | Sample the servo-rail current continuously; returns peak, mean and min mA. |
| set_protectionA | Set the rail trip limits (0 disables either). Overcurrent is capped at 7500 mA: the board's continuous budget is ~5 A. Resets at power-up. |
| clear_faultsA | Clear a latched overcurrent/undervoltage fault so channels can move again. |
| upload_scriptA | Compile a servo script and store it in the board's flash, where the firmware runs it without a PC (autorun: also start at every power-up). |
| script_statusB | What script is stored on the board, and whether it is running. |
| run_scriptB | Start the stored script from the top. |
| stop_scriptA | Stop the stored script; servos keep their positions (stop_all to let go). |
| release_portA | Close the serial port now (servos keep holding) so the GUI or flash.py can use the board. It reopens automatically on the next tool call. |
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 16 tools
Each tool targets a fairly distinct action: motion (move_servos, go_to_pose, play_sequence), lifecycle (upload/run/stop script), and hardware ops (read_analog, measure_current, set_protection). The only mild overlaps are disable_servos vs stop_all and board_status vs measure_current, but the descriptions clarify panic-stop vs selective release and status snapshot vs continuous sampling.
Nearly everything follows a snake_case verb_noun pattern (move_servos, clear_faults, upload_script, release_port). The small deviations are noun-first status reads (board_status, script_status) which break the verb-first convention but are still readable and predictable.
16 tools is slightly on the heavy side but justified: motion control, pose/sequence playback, analog sensing, current measurement, protection/fault handling, on-board scripting, and port management are all genuine subdomains. Nothing looks redundant enough to clearly cut.
The surface covers motion, playback, sensing, protection, and scripting well. However, board_status exposes channel names, modes, travel limits, and speed with no corresponding setter tools, so an agent cannot configure channels—a notable gap that likely forces reliance on the GUI.