Roblox Motion Tools

by kaziislam11

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, specific purposes (e.g., preview vs stop_preview, inspect vs connect_parts). Some overlap exists between generic motion_library_save and more specific save/create tools, but descriptions mostly disambiguate.
Naming Consistency3/5
The motion_ prefix is consistent, but the pattern varies: some are verb-first (motion_library_list, motion_blender_export_fbx), some are noun-first (motion_studio_sessions, motion_studio_job), and categories are mixed (motion_animation_create vs motion_studio_save_animation).
Tool Count3/5
18 tools is on the heavier side and falls within the borderline range. The functionality is complex enough to justify many operations, but some consolidation may be possible.
Completeness4/5
The toolset covers the core workflow: inspecting, creating, saving, previewing, and Blender import/export. Minor gaps like explicit delete or cancel operations exist, but they do not block primary use cases.
Average 4/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Fails to disclose side effects, such as whether the recipe is persisted, overwritten, or if repeated calls create duplicates. Annotations indicate idempotentHint false but the description does not surface this or any other behavioral details.
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 concise, with two sentences. It front-loads the primary purpose. However, the second sentence about reading and revising could be confusingly coupled to the creation action, slightly affecting clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the output or return value, even though an output schema exists. It also does not clarify how the created recipe integrates with sibling tools (e.g., saving to library or studio), leaving gaps in the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter names 'name' and 'preset' are self-explanatory, but the enum values ('charge', 'impact', 'heal') are not explained. The description mentions editable properties like color and size, but these do not map to the actual parameters, and schema coverage is 0%.
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?
Clearly states it creates an editable native Roblox particle recipe, which is a specific action. The verb 'create' is unambiguous, and the resource is a particle recipe. It differentiates from sibling tools that handle animations or library operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not specify when to use this tool versus alternatives like motion_library_save or motion_studio_save_vfx. It mentions reading and revising the recipe but does not clarify under what conditions this tool is preferred or if it complements other workflow steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful context beyond annotations: units for positions/rotations/key times, and the lineage-preserving role of parentId. Annotations already indicate a write operation (readOnlyHint false), so no contradiction. But it does not disclose validation failure behavior, whether saving overwrites an existing recipe, or any side effects beyond saving.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose, followed by the lineage tip and unit definitions. No wasted words, and the key information is immediately accessible.
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?
For a complex tool with two recipe variants and an optional revision parameter, the description covers the essentials but leaves gaps: it does not mention what the output (return value) represents, error handling, or validation rules beyond 'validate.' The output schema likely covers return structure, but the description could still clarify expected outcomes. Given the complexity, more guidance on when to use this vs. studio-specific saves would improve completeness.
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?
With 0% schema description coverage, the description compensates by explaining the purpose of parentId (revision lineage) and the unit system for recipe fields. It does not explain the difference between the animation and vfx variants, nor the meaning of fields like 'kind' or 'tracks' beyond what the schema constraints imply. Partial compensation for a complex nested 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?
States a clear verb-resource: 'Validate and save a custom recipe or revised recipe.' It distinguishes from read-only siblings (motion_library_list/read) and from studio-specific saves by mentioning 'library' and 'revision lineage.' However, it does not explicitly contrast with motion_studio_save_animation or motion_studio_save_vfx, which could overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only hints at one usage condition: 'Supply parentId to preserve revision lineage.' It does not say when to prefer this over motion_studio_save_animation/vfx or motion_animation_create/vfx_create, nor does it mention prerequisites or contexts where this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only indicate read/write/destructive hints), the description adds valuable behavioral context: it does not yet modify a rig, and local joint axes need visual review. This informs the user of side effects and follow-up actions, which is more than the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the primary purpose and adding only essential caveats. It is concise and well-structured with no redundant information.
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?
The description provides key context about the tool's scope (library, no rig modification) and a caveat (visual review needed). However, it lacks details about return values, error conditions, or how this differs from similar library save tools, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for any of the four parameters, and the description does not explain the meaning of 'preset', 'name', 'duration', or 'intensity'. Since coverage is 0%, the description fails to compensate, leaving the agent guessing about units, semantics, and relationships.
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 clearly states the action ('Create'), the resource ('editable simple animation preset'), and the location ('in the library'). It also distinguishes the tool from rig-modifying operations by explicitly saying 'Does not yet modify a rig.'
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?
The description gives some usage guidance by noting what the tool does not do (modify a rig) and that local joint axes need visual review afterward. However, it does not name alternative tools for rig modification or for visual review, leaving the agent to infer when to use this tool vs. siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses undoability, the creation of an Attachment, a disabled ParticleEmitter, and that EmitCount records the burst amount. This complements the readOnlyHint and destructiveHint annotations, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with the primary action and key details. No filler or redundant phrasing.
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?
The description covers the core mutation and undoability, but omits semantic details for assetId and part. The output schema and annotations help, yet the parameter gaps leave moderate ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only rigId and sessionId have schema descriptions. 'part' and especially 'assetId' lack meaningful descriptions, and assetId is defined via a confusing reference to sessionId. The description does not clarify what assetId or part represent.
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?
Description clearly states a specific action: saving a library VFX recipe as a new Attachment and disabled ParticleEmitter on a uniquely named part. It is easily distinguished from sibling tools like motion_studio_save_animation and motion_vfx_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this tool over alternatives such as motion_vfx_create or motion_library_save. The description implies a scenario but never explicitly states use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly and idempotent behavior, so the description's word 'inspect' aligns well. No additional side effects or authentication details are provided, but the annotations cover the primary safety aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, concise sentences convey the purpose and a critical usage hint without any filler or redundancy.
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 simple read-only inspection tool with no parameters, the description is sufficient. It states what it does and gives a practical prerequisite. However, it could be slightly more explicit about the return format (e.g., a list of sessions) but this is a minor 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?
The tool has no parameters, and the schema is empty, so the description does not need to explain parameter meaning. It effectively adds no additional parameter-related information, aligning with the baseline score.
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 states the tool inspects 'connected Studio places and selected model IDs', which is a specific verb and resource. However, it does not explicitly distinguish this from the sibling 'motion_studio_inspect' tool, which may serve a similar purpose.
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?
It provides a usage hint ('Select a rig in Studio before dispatching commands'), but this is more of a prerequisite than a comparison. It does not explicitly explain when to use this tool versus other studio-related tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive behavior, and the description adds that the original .blend is never overwritten and that a new action is created. This gives adequate side-effect transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. Key information is front-loaded and the caveat about axis retargeting is stated clearly.
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?
Given the output schema exists and annotations cover mutability, the description is largely complete. It could mention required preconditions like armature existence, but the provided information is sufficient for typical use.
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 covers descriptions for blendFile and jointMap, but armature and assetId lack descriptions. The main description indirectly clarifies their roles, but parameter-level semantics are incomplete.
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 action: apply a library animation to a named Blender armature and save a new .blend with a new action. This clearly distinguishes it from sibling tools like FBX export or library listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as motion_animation_create or motion_studio_save_animation. The note about axis retargeting is a limitation, not a usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description supplements annotations by explaining it creates a new FBX, bakes animation, disables leaf bones, rejects invalid influence counts, and notes the original .blend is never overwritten. It does not fully disclose output destination or existing-FBX overwrite behavior, but overall behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well structured: purpose first, then constraints, then a practical follow-up note. No unnecessary filler or redundancy.
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?
The description covers core behavior, validation criteria, and a post-export verification step. Since an output schema is present, return-value details are less critical, though the armature parameter ambiguity and unspecified output file location leave small gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only blendFile has a parameter description; armature is a required parameter with no explanation of expected name format or source. Schema description coverage is 50%, and the tool description only refers to a 'named armature' without defining it, so parameter semantics are insufficient.
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 clearly states the tool's specific action: exporting a named armature, bound meshes, and active clip to a new FBX with leaf bones disabled and animation baked. It is easily distinguishable from sibling tools like inspect, animate, or rig.
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?
The description gives purpose and validation behavior, but does not explicitly say when to use this tool versus siblings, such as 'after animation is complete' or 'instead of save operations.' Usage is implied rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable context beyond annotations: the meaning of the 'unknown' state (lost acknowledgement) and the recommendation to inspect the scene before retrying. This enriches the agent's understanding of edge cases without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence plus a brief clarification. It front-loads the core action and result, then adds the one nuance worth knowing. There is no wasted wording, and the structure is ideal for an agent to parse quickly.
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?
With one simple parameter, no nested objects, and a provided output schema (not shown but indicated), the description sufficiently covers the tool's behavior. It enumerates all possible outcomes and explains the only ambiguous one. It does not discuss pagination or return structure, but the presence of an output schema and the simplicity of the operation make this acceptable. Could mention that it is for polling, but that is implied.
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 0%, meaning the schema provides no description for jobId. The description does not explicitly explain that jobId refers to the job being checked, though it is strongly implied by the tool's purpose and the parameter name. For a single, simple UUID parameter, this minimal extra meaning is borderline adequate; the description could have explicitly stated 'the jobId of the job to check' to fully compensate for the schema gap.
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 clearly states the tool's action ('Get') and resource ('Studio job outcome'), enumerating the exact possible outcomes (queued, running, succeeded, failed, expired, unknown). This specificity distinguishes it from sibling tools like motion_studio_inspect or motion_studio_sessions, making its purpose unambiguous even without naming them explicitly.
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?
The description implies usage for checking job status but does not explicitly state when to use this tool versus alternatives. It does provide a conditional behavior ('Unknown means acknowledgement was lost; inspect the scene before retrying') which hints at a follow-up action, but no direct comparison to sibling tools or exclusions are given. This is adequate but leaves room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it creates a new KeyframeSequence, records undo, and uses a ServerStorage folder for storage. Since annotations provide no hints (all false), the description carries the full burden and covers the main side effects without hiding mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, uses precise technical terms, and avoids unnecessary elaboration. It is well-structured and immediately conveys the core functionality.
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?
The description sufficiently explains the core purpose and storage behavior, but it does not mention expected inputs or output. The ambiguity around assetId and the lack of any information about return values means an agent may struggle to fully use the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. The schema provides descriptions for rigId, jointMap, and sessionId, but assetId's description is only a $ref to sessionId's description, leaving a required parameter ambiguous. The tool description offers no clarification on what assetId represents.
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 clearly states the action ('Save a library animation'), the specific output ('new native KeyframeSequence'), the location ('rig's AnimSaves location'), and includes an explicit non-goal ('Does not upload or publish'). It distinguishes this tool from siblings like motion_studio_save_vfx or motion_library_save.
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?
The description implies when to use this tool by specifying it saves to a local rig location and explicitly excludes upload/publish behavior. It does not directly compare with alternatives like motion_library_save, but the behavioral details provide sufficient context for an agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool is annotated as readOnly and idempotent. The description adds that it discovers presets, limits, and connection requirements, but doesn't disclose additional behavioral traits like authentication or rate limits. It is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action 'Discover' and lists the specific categories of information. It is concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a capabilities discovery tool. The output schema is present, so no return value explanation is needed. The description covers all necessary aspects.
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?
The tool has no parameters, so the description doesn't need to explain any. The empty input schema is self-explanatory.
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 clearly states the tool's purpose: to discover available authoring operations, presets, limits, and connection requirements. This distinguishes it from sibling tools that perform specific actions.
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?
The description implies the tool is for discovering capabilities, but it doesn't explicitly guide the agent on when to use it versus sibling tools. There is no mention of alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the source file is unchanged and mentions background Blender, which communicates a read-only, non-destructive behavior. Combined with the readOnly and idempotent annotations, this is transparent, though it does not address error cases or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant details or filler. It efficiently conveys the tool's purpose and key safety property.
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 simple single-parameter inspection tool, the description covers the input, the operation, and the non-destructive nature. The output schema is noted as present, so the lack of an explicit output description is acceptable, though a brief mention of what is returned would make it more complete.
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?
The blendFile parameter is well documented as an absolute path to an existing saved .blend file, matching the parameter description and constraints. It conveys the required file type and path form, though it could add an example or note about permissions.
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 clearly states the tool inspects meshes, world bounds, armatures, and bone names in a .blend file, using background Blender. This is specific and distinguishes it from other motion tools that create, animate, or export.
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?
The purpose is implied but not explicitly contrasted with sibling tools. It does not say 'use this instead of motion_studio_inspect' or provide conditions for when to choose this tool, though the mention of saved .blend files gives some contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details: it creates a Motor6D, preserves rest positions and anchoring, and rejects certain conflicting states. These go beyond the annotations, which only indicate readOnly, idempotent, and destructive hints are false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using four short sentences that front-load the core purpose and then add relevant constraints. There is no unnecessary detail or repetition.
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?
The description provides enough context for an agent to understand the main operation, constraints, and the conditional sessionId requirement. Since an output schema exists, the lack of return-value details is acceptable, though a bit more clarity on the name parameter would improve completeness.
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 only 33%, so the description must compensate. It clarifies that parentPart and childPart are uniquely named parts and that pivot is a world-space position in studs, but the name parameter's purpose remains implicit and the optional nature of pivot is not explained.
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 clearly states the tool creates a Motor6D between two uniquely named parts, which is a specific action and resource. It is easily distinguished from sibling tools like motion_studio_sessions or motion_studio_inspect.
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?
The description gives clear context for when to use the tool by defining the action and constraints such as rejecting cycles, existing child motors, and conflicting welds. It also notes the conditional sessionId requirement, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important side effects beyond the annotations: it creates a temporary clone, fires cues once, leaves the original rig untouched, and is removed by stop. This matches the non-destructive, non-idempotent annotation and adds valuable behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Each sentence adds meaningful information without redundancy, making it easy to parse quickly.
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 tool with nested objects, six parameters, and an output schema, the description covers purpose, safety, side effects, and lifecycle. It lacks explicit usage scenarios or parameter details, but the schema and sibling tool names provide enough surrounding context for an agent to use it correctly.
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?
The description adds some parameter meaning—such as no uploaded animation ID being needed and cues firing once—but the schema already covers sessionId, rigId, and jointMap. It does not explain seconds, effects structure, or animationId beyond what the schema provides, and schema description coverage is only 50%.
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 clearly states the tool's purpose: previewing animation and timed VFX together on a temporary clone without affecting the original rig. It also distinguishes itself by noting no uploaded animation ID is needed and that stop removes the clone, which separates it from save/create tools.
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?
The description provides some usage context—safe preview, no uploaded ID needed, original rig untouched—but does not explicitly state when to prefer this tool over siblings like motion_studio_save_animation or motion_studio_stop_preview. It implies a test-before-save workflow but leaves that inference to the reader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns metadata-only, reinforcing non-destructive behavior and limiting expectations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover purpose, pagination, and return type. Every word adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with pagination and metadata-only response, the description fully covers what the tool does and what to expect. No additional context is needed.
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?
Input schema provides limit and offset with types and defaults (100% coverage), but no parameter descriptions. The description's mention of 'Paginated' hints at their role, but it does not explicitly explain their semantics, so it only slightly adds beyond the schema.
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?
Clearly states the action (list), the resource (saved recipes and immutable revisions), and includes scope (paginated, metadata only). Distinct from sibling motion_library_read, which likely fetches a single item.
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?
The purpose implies when to use it (browsing the library) and contrasts with read for specific items, but it does not explicitly name alternatives or conditions. Still, pagination and metadata-only give functional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds specific behavioral detail: it removes the clone and effects, which are temporary artifacts. This goes beyond the annotation hints and gives the agent a concrete sense of what will happen. It does not mention failure cases or prerequisites, but for a simple stop operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the essential purpose and behavior with zero filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which need not be explained in the description), the simple optional parameter, and the idempotent non-destructive annotations, the description fully covers what an agent needs to call this tool correctly. There is no missing context about return values or edge cases that would hinder usage.
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?
The schema already provides full documentation for the single parameter, sessionId, including its purpose and when it is required. The description adds nothing beyond that. With 100% schema coverage, the baseline of 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?
The description clearly states the action ('Stop the temporary preview') and the resource ('its clone and effects'). It is specific and distinct from sibling tools like motion_studio_preview, which starts a preview, and motion_studio_sessions, which manages sessions. The verb and object are unambiguous.
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?
The context is clear: use this to end a preview that was started with motion_studio_preview. However, there is no explicit mention of when NOT to use it or alternatives, though the sibling list makes the intended pairing obvious. It gives clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important side effects: it creates a new armature, saves a new .blend, never overwrites the original, and trims/audits automatic weights. This goes beyond the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and every sentence adds functional detail. It avoids fluff while covering prerequisites, assumptions, optional refinement, and output behavior.
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?
The description includes enough information to invoke the tool for its intended purpose, including required inputs and side effects. It lacks explicit explanation of bind and name, but the overall workflow is reasonably complete, and an output schema exists for return expectations.
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 40%, and only blendFile and landmarks have meaningful descriptions. The mesh, bind, and name parameters are undocumented, though the tool description partially compensates by explaining the overall rigging workflow.
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 states a specific verb and resource: 'Create a new 16-bone humanoid armature on an unparented, unrigged mesh.' This clearly differentiates the tool from siblings like motion_blender_animate, motion_blender_export_fbx, and motion_blender_inspect.
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?
The description provides clear context by specifying the target input ('unparented, unrigged mesh') and the expected outcome ('Saves a new .blend'). It does not explicitly contrast with sibling tools, but the usage is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. Description adds transparency about queueing a job and needing to check the job result, which are important side effects not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose and follow-up action are both conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the clear instruction to check the job result, the description covers all necessary context. No additional information is required for 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?
Both parameters have meaningful descriptions in the schema: rigId is a stable model ID from motion_studio_sessions, and sessionId is required only in multi-session contexts. The description does not need to add further detail.
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 ('Queue inspection') and resource ('specific rig') with explicit scope: parts, joints, animated names, and structural issues. Clearly distinguishes from immediate inspection tools by indicating asynchronous behavior.
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?
Provides usage direction by saying 'Check job result for the report,' guiding the user to poll the job status. Does not explicitly contrast with sibling inspect tools like motion_blender_inspect, but the async queueing is clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the behavioral side. The description's 'Read' is consistent with these annotations; no side effects or contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. There is no unnecessary detail or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (per context signals), the description need not explain return values. The operation is a straightforward read, and the description provides enough context for an agent to know what the tool does.
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?
The schema defines assetId as a UUID but provides no description. The tool description adds meaning by saying 'by asset ID', clarifying that assetId is the identifier of the asset to read. However, it does not elaborate on how to obtain the asset ID or any additional context.
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 clearly states the action ('Read'), the resource ('a complete editable animation or VFX recipe'), and the scope ('by asset ID'). This distinguishes it from sibling tools like motion_library_list (which likely lists recipes) and motion_library_save (which writes).
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?
The description implies usage for retrieving a specific recipe for editing, but it does not explicitly contrast with alternatives or state when not to use it. The 'complete editable' wording hints at use cases, but explicit when/when-not guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![motion-tools MCP server](https://glama.ai/mcp/servers/kaziislam11/motion-tools/badges/card.svg)](https://glama.ai/mcp/servers/kaziislam11/motion-tools)

Score Badge

Copy to your README.md:

[![motion-tools MCP server](https://glama.ai/mcp/servers/kaziislam11/motion-tools/badges/score.svg)](https://glama.ai/mcp/servers/kaziislam11/motion-tools)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kaziislam11/motion-tools'

If you have feedback or need assistance with the MCP directory API, please join our Discord server