Skip to main content
Glama
YidaYang

embodify-mcp

by YidaYang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_gripper

Open or close a robot gripper and wait until the opening width settles, hits a step cap, or exhausts the episode budget, returning stop reason, state, and images.

Instructions

Open or close the gripper. The server keeps sending the command and watches the opening width, and returns only when a definite stop condition triggers, not after a fixed number of steps. action.stop_reason says why the call stopped, one of four:

  • settled: After at least 10 internal steps of the same command, the opening varied by less than 0.5 mm over the last 2 steps. This only means the opening is momentarily stable, possibly because something blocks it; it does not guarantee a fully open gripper, a firm grasp or a released object. Check state.gripper.opening_m and the images.

  • step_cap: Hit the per-call internal step limit before the opening was confirmed stable; the gripper may still be starting or moving. Repeat the same command to continue.

  • budget: The episode's total step budget ran out during the action; only stop_episode can be called afterwards.

  • no_op: The request matches the current gripper target and no gripper call is pending; nothing was executed and no budget was used. It does not mean an object was released. Returns images (two separate PNGs), state (eef_pos_m is the end-effector XYZ position in meters, eef_rpy_rad the RPY orientation in radians, gripper.command the gripper target and gripper.opening_m the opening in meters), action (the requested gripper target, executed_steps, stop_reason, opening_m before and after), step (simulation steps used after the call), steps_left (simulation steps left) and status (running). When the budget is already 0, returns a step_limit error and the gripper target stays unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/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 load and does so exceptionally: it explains the adaptive stop algorithm, that 'settled' does not imply a firm grasp or released object, the no_op case, the budget-exhaustion lockout, and the step_limit error leaving the target unchanged. This is exactly the operational context an agent needs for a stateful actuator.

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?

The first sentence front-loads purpose plus the key behavioral mechanic, then the four stop reasons are cleanly bulleted. Length is justified because it simultaneously serves as the missing output documentation (no output schema exists); every clause is load-bearing.

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?

No annotations and no output schema mean the description must cover both behavior and returns, and it does: it enumerates the returned fields (images, state, action, step, steps_left, status) with units and meanings, plus the error path. Nothing an agent needs to call or interpret this tool correctly is missing.

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% and there is one parameter, but its enum values open/close are self-explanatory. The description never names or explains the 'state' parameter directly, and its references to 'the requested gripper target' do not map cleanly onto a parameter called state, so compensation for the coverage gap is only partial.

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?

"Open or close the gripper" is a precise verb+resource that an agent can act on immediately, and the gripper is a domain no sibling tool (move_relative, observe, stop_episode) touches. It stops short of explicitly positioning itself against those siblings, but the resource is unmistakable.

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 stop_reason breakdown effectively tells the agent what to do next: repeat the same command on step_cap, and note that only stop_episode is callable once budget is exhausted. That is concrete downstream guidance, though it never states the motivating use case (e.g. grasp vs release) or a when-not-to-use condition.

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