Skip to main content
Glama
Gearotons

servomotor-mcp

by Gearotons
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

multimove

Queue up to 32 acceleration or velocity moves for a servomotor in one command, requiring the final move to stop the motor to avoid fatal errors.

Instructions

The multimove command allows you to compose multiple moves one after another. Please note that when the queue becomes empty after all the moves are executed and the motor is not at a standstill then a fatal error will be triggered. [Firmware command "Multimove", group: Motion Control.] NOTE: moveList is a list of [value, duration_seconds] pairs (max 32): value is degrees/s^2 for acceleration moves (moveTypes bit = 0) or degrees/s for velocity moves (bit = 1); this server converts to firmware units. The final move must bring the motor to a standstill or the firmware raises a fatal error when the queue empties. This QUEUES the move and returns immediately; poll get_n_queued_items for completion, or use move_to/move_relative which wait. Requires enable_mosfets first. Parameters:

  • moveCount: Specify how many moves are being communicated in this one shot.

  • moveTypes: Each bit specifies if the move is a (bit = 0) MOVE_WITH_ACCELERATION_COMMAND or a (bit = 1) MOVE_WITH_VELOCITY_COMMAND.

  • moveList: A 2D list in Python format (list of lists). Each item in the list is of type [i32, u32] representing a series of move commands. Each move command specifies the acceleration to move at or the velocity to instantly change to (according to the bits above) and the number of time steps over which this command is to be executed. For example: '[[100, 30000], [-200, 60000]]'. There is a limit of 32 move commands that can be listed in this one multi-move command. Each of the moves takes up one queue spot, so make sure there is enough space in the queue to store all of the commands. Returns: success confirmation. motor: an alias number (e.g. 88), a 16-hex-digit unique ID (e.g. "0123456789ABCDEF"), or "all" to broadcast to every motor on the bus (broadcasts get no responses back).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
motorYes
moveListYes
moveCountYes
moveTypesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden. It discloses asynchronous queue-and-return behavior, a fatal error when the queue empties without a standstill, the need for the final move to stop the motor, the enable_mosfets prerequisite, queue-spot consumption, and that broadcasts receive no responses.

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?

The description is well-organized with a summary, critical error note, usage note, and parameter breakdown. It is somewhat redundant, repeating the fatal-error/standstill warning twice and the 32-move limit twice, but the added length is mostly justified for a complex command.

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

Completeness5/5

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

Given no annotations and no output schema, the description covers prerequisites, error conditions, queue behavior, parameter formats, return confirmation, and motor addressing. An agent has enough information to invoke this tool correctly and interpret the main risks.

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?

Since schema description coverage is 0%, the description thoroughly compensates by explaining moveCount, moveTypes bit encoding, moveList structure with units and examples, the 32-command limit, and motor addressing. However, it calls moveList 'a 2D list in Python format' while the schema declares it as a string, creating ambiguity about whether to pass a list object or a stringified representation.

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?

The opening sentence states a specific action: 'compose multiple moves one after another.' It later contrasts with move_to/move_relative, which wait, making the tool's unique role clear relative to its siblings.

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

Usage Guidelines4/5

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

The description gives clear usage context: it queues and returns immediately, suggests polling get_n_queued_items or using move_to/move_relative when waiting is desired, and notes the enable_mosfets prerequisite. It does not explicitly say when not to use this tool in favor of single-move alternatives, but the guidance is otherwise strong.

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