Skip to main content
Glama
ucandevices

UsbServoController

Official
by ucandevices
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

upload_script

Compile a servo script and flash it to the controller board so its firmware runs the sequence without a PC, optionally starting it automatically at every power-up.

Instructions

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).

One statement per line; channels by number or name; times in ms or '1.5s':
  label:                  jump/loop target
  move <ch> <us> [<time>] ramp there; does not wait: moves on different
                          channels run together, a repeat move of the
                          same channel waits for the previous one
  pose <name> [<time>]    move every channel of a GUI pose
  sync                    wait until all moves arrive
  wait <time>
  off <ch>|all
  loop <label> [<n>]      block runs n times in total; no n = forever
  jump <label>
  waitin <ch> >|< <0-4095>   wait for analog input ch (0-7)
  ifin <ch> >|< <0-4095>     run next statement only if true
  end
Positions are clamped to the channel limits. Max 254 instructions.

Input Schema

NameRequiredDescriptionDefault
runNo
scriptYes
autorunNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses compilation, flash persistence, autorun-across-power-ups, clamping to channel limits, and a hard 254-instruction cap. It omits whether an upload overwrites the existing stored script and whether a board connection/port is required, which matters for a write tool.

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

Conciseness5/5

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

Front-loaded purpose sentence, then a scannable grammar block with per-instruction semantics and edge cases (non-blocking move, repeat-move waiting, loop count semantics). Dense but every line carries information an agent needs to author valid input.

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?

No output schema and no annotations, so the description must stand alone; it does so for the script DSL and limits, which is the hard part. The remaining gap is the unexplained 'run' flag and the absence of overwrite/idempotency behavior for the stored flash content.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry all parameter meaning. It does explain 'autorun' ('also start at every power-up') but leaves 'run' completely unaddressed and never connects script-text format to the script parameter beyond the grammar listing.

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

Purpose5/5

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

States a specific verb and resource ('compile a servo script and store it in the board's flash') plus the distinguishing consequence: the firmware executes it without a PC. That scope separates it from play_sequence/run_script at a glance.

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?

Usage is implied by the flash/autorun framing (persistent, PC-independent execution) but no sibling is named, so the agent gets no explicit rule for choosing upload_script over run_script, play_sequence, or go_to_pose. The autorun parenthetical hints at a persistence decision but doesn't route the call.

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

Deploy Server

Other Tools