FREE motion capture sample — first 5 seconds of BVH skeletal animation (frame count = 5 × lesson fps). Enough to validate format, joint hierarchy, and data quality for sim_to_real_retargeting or action_recognition. Full files are 20–120 seconds ($10 USDC via get_bvh).
| Name | Required | Description | Default |
|---|---|---|---|
| subject | No | Subject name. Defaults to 'subject_1'. | subject_1 |
| lesson_path | No | Lesson path. Defaults to first available lesson. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / competitorRemoved value: -{
- "default": "Professor",
- "description": "Competitor name. Defaults to 'Professor'.",
- "type": "string"
-}Input schema / properties / subjectAdded value: +{
+ "default": "subject_1",
+ "description": "Subject name. Defaults to 'subject_1'.",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the sample is free, limited to 5 seconds, and intended for validation. It also notes the paid full-file option. While it doesn't describe the exact return format or any potential side effects, it gives substantial context for a read-only sample tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the key facts (FREE, first 5 seconds) and pack in use cases and an alternative. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description fully covers what the tool does, its limitations, pricing, and use cases. It is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions), so the baseline is 3. The description adds minimal extra meaning beyond the schema, though it does mention 'lesson fps', which subtly ties to lesson_path. No further parameter detail is needed given the self-descriptive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: providing a free 5-second BVH motion capture sample. It includes specific details (frame count = 5 × lesson fps) and distinguishes it from the full-file alternative (get_bvh), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions use cases (validating format, joint hierarchy, data quality for sim_to_real_retargeting or action_recognition) and points to the alternative get_bvh for full files (20–120 seconds, $10 USDC). This provides clear guidance on when to use this tool versus the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly separated by domain and tier (profile/sample/full), but get_mocap_sample and get_trial_bvh both return 5-second BVH samples and could be misselected. The rehab sample/profile tools are also close in evaluation purpose, though descriptions do help distinguish them.
The data-access tools consistently follow get_<domain>_<variant>, and the only navigation tools are browse_catalog and search_catalog, which also use a predictable verb_noun pattern. There is no mixing of naming styles or inconsistent verb forms.
With 21 tools, the set is borderline heavy for a data marketplace, especially since many tools are trial/sample/profile variants of the same paid products. The broad multi-domain scope justifies some size, but several variants could be consolidated without much loss of clarity.
The tools cover catalog browsing/searching, free profiles and samples, and paid full products across motion capture, rehab biomechanics, and threat/fleet intelligence. Minor gaps exist, such as no video trial and no generic fetch-any-catalog-item tool, but agents can work around these with the existing sample tools.