Skip to main content
Glama
Gearotons

servomotor-mcp

by Gearotons
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_status

Check motor status flags and fatal error code to detect faults and determine if a reset is needed.

Instructions

Gets the status of the motor [Firmware command "Get status", group: Status & Monitoring.] Returns:

  • statusFlags: A series of flags which are 1 bit each

  • fatalErrorCode: The fatal error code. If 0 then there is no fatal error. Once a fatal error happens, the motor becomes disabled and cannot do much anymore until reset. You can press the reset button on the motor or you can execute the System reset command to get out of the fatal error state. 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.1
    • removedInput schema / properties / motor / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / motor / default
      Removed value: -null
    • addedInput schema / properties / motor / type
      Added value: +"string"
    • addedInput schema / required
      Added value: +[
+  "motor"
+]
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It usefully explains that broadcasts to 'all' motors produce no responses, and it details the fatal-error consequence and reset options, which goes beyond a simple 'get' operation. It does not explicitly state that the operation is side-effect-free, but the name and content imply a read-only status query.

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

Conciseness3/5

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

The content is mostly concise and information-dense, but the structure is confusing: 'motor:' is listed under 'Returns:' even though it is an input parameter, not a return value. The firmware command reference is useful but not essential, and the lack of separate 'Args:' and 'Returns:' labels harms clarity.

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 single-parameter tool with no output schema and no annotations, the description covers the parameter forms, the return fields, and the critical broadcast no-response behavior. It is nearly complete, though the ambiguous placement of the motor parameter prevents it from being excellent.

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

Parameters5/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 fully. It does: it explains that 'motor' can be an alias number, a 16-hex-digit unique ID, or 'all' for broadcast, and it notes that broadcasts receive no responses. This gives an agent everything needed to construct the parameter correctly.

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?

The description clearly states the tool 'gets the status of the motor' and enumerates specific returned fields, making the core purpose evident. However, it does not differentiate from the sibling tool get_motor_status, so an agent could not tell which status tool to prefer without additional context.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as get_motor_status or other monitoring tools. It mentions the firmware command group but offers no explicit context or exclusions to help an agent choose correctly.

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