Skip to main content
Glama

RTK Motion — Motion Capture, Biomechanics, Threat & Fleet Intelligence

by io.rtkmotion
OverviewDiscussionsAdmin

get_trial_robotarget

TRIAL — 5-second robot-trajectory sample (300 frames @ 60fps NPZ) from the Kimura side-control trial lesson. Same format as full $15 get_robotarget — use to evaluate retargeting quality before committing. Platforms: Unitree G1 (43 DOF: 29 body + 14 hand), Unitree H1 (19 DOF), Apptronik Apollo (32 DOF). Pay $0.25 USDC on Base (chain 8453, USDC 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) to RTK wallet 0x6C11F8a21f7ca922F483Ed21C3b6c2d9B305B10C; pass tx hash as payment_tx. Eth/Solana: /.well-known/x402.

Input Schema

NameRequiredDescriptionDefault
robotNoTarget robot: 'g1' (default, Unitree, 43 DOF = 29 body + 14 hand), 'h1' (Unitree, 19 DOF), or 'apollo' (Apptronik, 32 DOF)
subjectNoSubject name: 'subject_1' (default) or 'subject_2'
quote_idNoRedeem this item from a negotiated quote you already paid with pay_quote (q_...). Use instead of payment_tx / x_payment: no further payment is taken.
x_paymentNoPreferred (x402 exact / gasless): base64 X-PAYMENT payload — a signed EIP-3009 transferWithAuthorization for this tool's USDC price to our wallet. Redeemable only by its signer; no gas needed.
payment_txNoUSDC transaction hash. Send $0.25 USDC on Base to 0x6C11F8a21f7ca922F483Ed21C3b6c2d9B305B10C, then pass tx hash here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / quote_id
      Added value: +{
+  "description": "Redeem this item from a negotiated quote you already paid with pay_quote (q_...). Use instead of payment_tx / x_payment: no further payment is taken.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / robot / description
      Previous value: -"Target robot: 'g1' (default, Unitree, 24 DOF) or 'h1' (Unitree, 19 DOF)"New value: +"Target robot: 'g1' (default, Unitree, 43 DOF = 29 body + 14 hand), 'h1' (Unitree, 19 DOF), or 'apollo' (Apptronik, 32 DOF)"
  3. Changed1 schema field changed
    • addedInput schema / properties / x_payment
      Added value: +{
+  "description": "Preferred (x402 exact / gasless): base64 X-PAYMENT payload — a signed EIP-3009 transferWithAuthorization for this tool's USDC price to our wallet. Redeemable only by its signer; no gas needed.",
+  "type": "string"
+}
  4. Added

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden and does so well: it discloses price, chain, token contract, receiving wallet, accepted payment mechanisms, and the supported robot platforms/DOF. Gaps remain around failure/refund behavior, whether a tx hash can be replayed, and rate limits, which matter for a paid tool.

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?

Front-loaded with the sample size, format, and trial-vs-full framing, which is the right priority order. Some material (DOF lists, wallet address, USDC contract) duplicates the schema, making it denser than needed.

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?

No output schema exists, and the description does characterize the return as a 300-frame 60fps NPZ in the same format as get_robotarget. What's missing is how the file is delivered (base64 payload vs. URL) and the per-robot frame/DOF mapping, which an agent would want before paying.

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 100%, so robot, subject, quote_id, x_payment, and payment_tx are already fully documented. The description mostly restates the payment_tx route already in the schema and adds only the out-of-band Eth/Solana well-known endpoint note. Baseline 3 is appropriate.

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?

States a specific verb+resource with concrete scope: a 5-second, 300-frame @60fps NPZ robot-trajectory sample from a named lesson. It explicitly distinguishes itself from the sibling get_robotarget by calling itself the cheaper evaluation copy of the same format.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use (evaluate retargeting quality before committing) and names the alternative (full $15 get_robotarget). The trade-off between the trial and the full asset is spelled out, not inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All RTK Motion — Motion Capture, Biomechanics, Threat & Fleet Intelligence toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources