Skip to main content
Glama
mcp-for-cascadeur

mcp-for-cascadeur

by Rickcy

character_pose_preserving_curves

Destructive

Edit existing point position keyframes while preserving key layout, interpolation, easing, tangent metadata, and untouched authored channels; verifies full-clip rig geometry after changes.

Instructions

Edit existing Point position keys without changing key layout, interpolation, easing or tangent metadata. Protects untouched authored keys, finger channels, baked tracks, external data and settings; verifies full-clip rig geometry.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "character_id": "<character_id>",
      "keyframes": "<keyframes>"
    },
    "name": "character_pose_preserving_curves"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyframesYes
character_idYes
position_toleranceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare this is a mutating, destructive operation on a closed world. The description adds genuinely useful context not in the annotations: untouched keys, finger channels, baked tracks and settings are protected, and full-clip rig geometry is verified afterwards. What it does not say is whether it can create keys at frames lacking one, what happens on verification failure, or whether the edit is transactional.

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?

Two tight sentences, front-loaded with the action and its invariant before the protection/verification caveats. The second sentence is a dense semicolon clause but every item earns its place by telling the agent what is safe to assume remains unchanged.

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 destructive edit tool with no output schema and undocumented parameters, the description covers the preservation contract and mentions verification but leaves the failure/return behavior and the meaning of the tolerance parameter unstated. An agent knows what will not break but not how to interpret success or tune the call.

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?

With three parameters at 0% schema description coverage, the description carries the full burden and does not meet it. It never explains character_id, the frame/poses structure, the maxItems limits (8 keyframes, 128 poses), or what position_tolerance controls or how it affects the geometry verification. Only the implicit 'position' subject matter is communicated.

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 and resource: edits existing Point position keys, and enumerates exactly what it will not touch (key layout, interpolation, easing, tangent metadata). This is specific enough to separate it from a general pose/keying tool, though it never names a sibling (e.g., character_offset_preserving_curves) so the distinction must be inferred.

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 'when' is implied by the preserving-curves framing: use it when you want to move existing keys without disturbing timing or tangents. There is no explicit when-not, no mention of the alternative tools for creating new keys or offsetting curves, and no stated prerequisite such as an active scene or character selection.

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

Deploy Server

Other Tools