Loading ToolBench
A 3D character animation skill server that processes image keypoints and generates skeleton pose maps for character rigging
This server has severe definition quality issues. The single tool 'animate_character' has an extremely vague description (54 chars), lacks proper parameter descriptions, and has an underdocumented output schema. The tool appears to be a stub implementation that returns hardcoded mock data rather than actual animation processing. Parameter 'image_keypoints' is described generically as 'List of keypoint dictionaries...' without specifying the required structure, coordinate ranges, joint identifier constraints, or expected format. The output schema is never explicitly documented, we can only infer from the return statement that it contains 'skeleton_pose_map' with 'joints_count' and 'rigging_status', but there are no type declarations, field descriptions, or constraints. There is no error handling, validation guidance, or recovery paths. The tool name itself ('animate_character') is reasonable but the implementation does not match the promise, no actual animation, skeleton rigging, or pose processing occurs; the function merely counts input items and returns a static 'rigged_successfully' string.
Processes image keypoints and generates a skeleton pose map with joints count and rigging status
Missing input parameter descriptions. 'image_keypoints' parameter has only a generic description 'List of keypoint dictionaries containing joint position and identifier information', no specification of coordinate system, range, required joint names, or expected format. LLMs cannot infer valid input structure.
Output schema is not documented. The tool returns a dict with 'skeleton_pose_map' containing 'joints_count' and 'rigging_status', but there is no explicit schema definition, type declarations, or field descriptions. LLMs cannot plan downstream operations without knowing the response structure.
Tool description is too brief (54 characters) and does not explain WHEN to use this tool or WHAT a skeleton pose map is. The description 'Processes image keypoints and generates a skeleton pose map with joints count and rigging status' lacks context on prerequisites, use cases, and expected behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 28 | 2026-07-28+ | v2 |
No error handling or validation. The tool always returns success with a static 'rigged_successfully' status regardless of input. There is no guidance for failure modes (e.g., invalid keypoints, missing joints, malformed coordinates), recovery paths, or constraints. Pattern: recovery-guide.
Stub implementation: the function does not perform actual 3D animation, skeleton rigging, or pose mapping. It merely counts input items and returns a hardcoded response. This violates the single-responsibility and composition patterns, the tool name promises animation processing but delivers only data counting.
Parameter 'image_keypoints' lacks type specificity. Described as 'array' of 'object' but no specification of required object keys (is 'joint' always present? what about 'x' and 'y'?), valid joint names, coordinate ranges, or validation constraints. LLMs will struggle to construct valid invocations.