Skip to main content
Glama

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

by io.rtkmotion
OverviewDiscussionsAdmin

get_trial_bvh

TRIAL — 5-second BVH skeletal sample (300 frames @ 60fps) from the Kimura side-control trial lesson. Same format as full $10 get_bvh — use to evaluate data quality before committing. 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
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
    • 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"
+}
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses exact price ($0.25 USDC), chain, token contract, recipient wallet, and that the payload is limited to 300 frames. It does not state rate limits, whether repeat calls re-charge, or refund behavior, which keeps it short of a 5.

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 distinguishing facts (trial, size, sibling comparison) are front-loaded before the payment block, and every clause is functional. The long hex addresses make it dense but they are load-bearing payment data, not filler.

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 paid, no-annotation, no-output-schema tool, the description covers what an agent needs to pay correctly and know what data comes back. Minor gaps remain around repeat-call charging and the subject parameter's effect, but nothing blocks correct invocation.

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?

Schema coverage is 100%, so the baseline is 3; the description adds value by spelling out the concrete payment amount, chain 8453, and USDC contract for payment_tx, plus an out-of-schema pointer for other chains. It doesn't clarify how `subject` selects skeletons beyond the schema text.

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 resource (a 5-second / 300-frame @60fps BVH skeletal sample from the Kimura side-control trial lesson) and explicitly contrasts it with the full-price sibling get_bvh. An agent can distinguish it from get_bvh and the other get_* sample tools without opening 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 Guidelines5/5

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

Gives an explicit selection rule: 'use to evaluate data quality before committing,' naming the full $10 get_bvh as the alternative. The trial-vs-paid trade-off is unambiguous, and alternate payment routes (quote redemption, x_payment, Eth/Solana via x402) are pointed to.

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