Skip to main content
Glama

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

by io.rtkmotion
OverviewDiscussionsAdmin

get_bundle

Complete session bundle — EVERY modality for one lesson in a single purchase: all 12 camera views (1080p MP4), BVH skeletal animation for both subjects (60 fps, 56-joint), and robot-ready NPZ joint trajectories for every supported platform (Unitree G1 43 DOF, Unitree H1 19 DOF, Apptronik Apollo 32 DOF). 20 files, ~$170 bought individually. Does NOT include the rigged FBX/OBJ mesh assets, which are licensed separately via Fab.com. Pay $50 USDC on Base (chain 8453, USDC 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) to RTK wallet 0x6C11F8a21f7ca922F483Ed21C3b6c2d9B305B10C; pass tx hash as payment_tx. Solana USDC to 7vV3cV7iCtmwKCzK1tWRdbWop31zw7pVFe8HxfFKrTZV also accepted — pass the base58 signature as payment_tx. See /.well-known/x402.

Input Schema

NameRequiredDescriptionDefault
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 on Base (x402 exact / gasless): base64 X-PAYMENT payload — a signed EIP-3009 transferWithAuthorization for $50 USDC to our wallet. Redeemable only by its signer; no gas needed. Solana must use payment_tx.
payment_txNoUSDC transaction hash/signature. Send $50 USDC on Base to 0x6C11F8a21f7ca922F483Ed21C3b6c2d9B305B10C, or on Solana to 7vV3cV7iCtmwKCzK1tWRdbWop31zw7pVFe8HxfFKrTZV, then pass the tx hash (0x…) or base58 signature here.
lesson_pathNoLesson path, e.g. 'BJJ/Training/KimuraFromSideControl/Lesson001'. Defaults to first available lesson. Use browse_catalog to list lessons and their bundle_price.

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. Added

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses exactly what is included, what is excluded (rigged FBX/OBJ mesh assets), the price, accepted chains, and payment method. It does not explain post-payment behavior, such as how files are delivered or whether access is time-limited.

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-loads the key idea — complete bundle contents — before moving to payment logistics. Some payment address details duplicate the schema, but the overall length is justified for a high-stakes purchase tool.

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 complex, payment-gated purchase tool with no output schema, the description covers the core contents, exclusions, price, and payment rails well. It still leaves the return behavior vague, since it does not state what the caller receives after a successful payment.

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 baseline is 3. The description mentions payment methods and the $50 price, but most of that detail is already present in the payment_tx and x_payment schema descriptions; it adds little parameter-level meaning beyond the schema.

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 identifies the resource and scope: a complete session bundle containing every modality for one lesson in a single purchase, with specific file counts and formats. It implies differentiation from single-modality siblings like get_bvh and get_video_url by saying it includes EVERY modality, but it does not explicitly name those alternatives.

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 clear purchase context and precise payment instructions for Base and Solana, including the amount and wallet addresses. However, it never explicitly states when to use this bundle versus individual modality tools such as get_bvh or get_robotarget; that choice is left implicit.

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