Skip to main content
Glama
Sign In
PhySpace-Forge

PhySpace-Forge

by jason12343
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

physpace_simulate_grasp_trajectory

Simulate 200Hz tactile grasp trajectories to verify whether a policy or target pressure safely lifts, drops, or crushes an object, returning sensor readouts and correction hints.

Instructions

Run a 200Hz RT-Patch-IPC zero-penetration continuum contact simulation to verify whether an AI Agent's proposed grasp policy or target indentation/pressure will safely lift the object (GOLDEN_SAFE_WINDOW), drop it (SLIP_DROP_RISK), or crush it (CRUSH_DAMAGE). Returns 16x16 commercial tactile sensor readouts and actionable self-correction hints.

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": {
      "object_id": "<object_id>"
    },
    "name": "physpace_simulate_grasp_trajectory"
  }
}

Input Schema

NameRequiredDescriptionDefault
object_idYesObject ID to grasp (e.g., 'tapered_coffee_cup').
policy_modeNoControl policy mode: 'tactile_closed_loop' or 'naive_position'.
hardware_sensor_idNoCommercial tactile sensor profile to emulate.
target_pressure_kpaNoDesired fingertip peak pressure in kPa (e.g., 3.2).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose meaningful behavior — 200Hz simulation rate, zero-penetration contact physics, the three outcome labels, and that sensor readouts plus self-correction hints are returned — but it never states that this is a purely simulated, non-actuating operation, nor any runtime/latency cost or prerequisite assets (e.g., whether the object must first be compiled via physpace_compile_universal_asset).

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?

Two tight sentences with no filler; the outcome classification and return values are front-loaded and the sentence carries a lot of information per word. The opening is dense with internal jargon ('RT-Patch-IPC') before the plain-language purpose, which slightly slows comprehension but does not waste space.

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

Completeness3/5

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

With no output schema, the description must describe returns, and it does so only briefly ('16x16 commercial tactile sensor readouts and actionable self-correction hints') without indicating response structure or how the three verdict labels are surfaced. For a simulation tool with four parameters and inter-tool dependencies, the absence of prerequisite and cost information leaves a real gap.

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 description coverage is 100%, so the schema already documents object_id, policy_mode, hardware_sensor_id, and target_pressure_kpa including enums. The description adds only conceptual linkage ('proposed grasp policy' → policy_mode, 'target indentation/pressure' → target_pressure_kpa) and no format, units, or default guidance beyond what the schema states, so baseline 3 applies.

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 names a specific verb and resource — 'Run a 200Hz RT-Patch-IPC zero-penetration continuum contact simulation' — and states exactly what it verifies (a proposed grasp policy or target indentation/pressure) with three named outcome classes. This is clearly distinguishable from siblings like physpace_inspect_object_safety_envelope or physpace_step_realtime_safety_shield, which are inspection and stepping tools rather than full grasp-policy simulation.

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 rather than stated: 'verify whether an AI Agent's proposed grasp policy ... will safely lift the object' suggests calling this before committing to a grasp, but there is no explicit when-to-use or when-not-to-use clause. None of the sibling tools are named as alternatives, so the agent must infer whether this or physpace_inspect_object_safety_envelope is the right first step.

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