Skip to main content
Glama
Sign In
BonengDriveMCP

BonengDriveMCP

by time32
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

configure_drive_position_reference

Sets the software zero and optional position limits for this MCP session from the drive's stopped feedback, without writing to the drive or running homing.

Instructions

停机读取反馈后保存本次MCP会话的坐标参考，不写驱动器、不执行回零。先询问是否把当前停止点设为软件零点；existing_device_zero使用用户已建立的设备坐标。默认指令脉冲；圈/角度须明确每圈指令脉冲数。可选同时提供最小/最大软件行程；省略时只防32位溢出，无机械限位。断电、复位、重新回零或MCP重启后须重建，不能声称已验证物理零点。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "zero_method": "<zero_method>"
    },
    "name": "configure_drive_position_reference"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNoCOM7
unitNopulses
transportNoselected_tcp
zero_methodYes
maximum_positionNo
minimum_positionNo
pulses_per_revolutionNo
reference_descriptionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, it discloses critical behavior: the reference is session-scoped and must be rebuilt after power-off, reset, re-homing, or MCP restart, and it must not be claimed as a verified physical zero. It also clarifies the overflow-only fallback when travel limits are omitted. The "does not write drive" note is consistent with readOnlyHint=false because the tool mutates MCP session state, not the physical drive.

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 dense but front-loaded with the core action and its negative scope before moving to parameter semantics and persistence caveats. Every clause carries information; only the enumeration of reset conditions is slightly compressed.

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 an 8-parameter session-state tool with an output schema (so return values need not be explained), the description covers the operation, the zero-method choice, unit requirements, limit fallback, and lifecycle caveats. Minor gaps remain for transport, port, and the free-text reference_description, but nothing essential to correct invocation is missing.

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?

With 0% schema description coverage, the description carries the load and does well on the non-obvious parameters: zero_method's two enum choices, unit's default of command pulses with the pulses_per_revolution requirement for revolutions/degrees, and the min/max position semantics. It leaves port, transport (selected_tcp vs serial), and reference_description unexplained, so it does not fully compensate for the coverage gap.

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 description states a specific action on a specific resource: save the coordinate reference for this MCP session after reading feedback while stopped. It also scopes the tool negatively ("does not write the drive, does not execute homing"), which cleanly separates it from execute_drive_position_move and the homing-related siblings without the agent needing to open the schema.

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?

It gives concrete when-to-use guidance: first ask whether to set the current stopped point as software zero, and use existing_device_zero when the user already has an established device coordinate system. It also explains the optional min/max condition (omit = only 32-bit overflow protection, no mechanical limits). It stops short of naming sibling tools as alternatives, so not a full 5.

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