Loading ToolBench
Mechanistic AI Agent Bridge for VRChat Avatar Rigging - MCP server providing tools for Unity scene manipulation, material management, blendshape control, and avatar configuration
UnityVibeBridge is a file-based queue system (not a true MCP server) with severe definition quality gaps. The codebase shows repeated tool definitions across multiple Python scripts without a unified, registered tool registry. No explicit MCP tool definitions are visible in the provided source, tool names, descriptions, and schemas appear to be inferred from file organization and ad-hoc command structures. The server.py entry point references `create_kernel()` from __init__.py, but the actual tool registration logic is not shown. Tools communicate via JSON files written to inbox/outbox queues, this is not an MCP-compliant transport. Descriptions are present but minimal (10-30 chars for most tools). Parameter schemas are documented in the eval input but lack proper JSON Schema validation in the actual implementation. No error handling, recovery guidance, or structured response formats are evident. The architecture suggests a custom IPC protocol, not MCP.
Find optimizer assemblies in the Unity project
Fix broken/pink shaders on selected material
Inspect material properties at a specific index
List materials on an object
Set a blendshape value on an object
Find a scene object by name
List all available tools in the VibeBridge system
No explicit MCP tool registration visible. Tools appear to be inferred from filenames and command strings rather than registered via a proper MCP server framework. The actual tool definitions (names, descriptions, schemas) are not present in the provided source code.
Transport is file-based queue (inbox/outbox JSON files), not MCP-compliant. This is a custom IPC protocol. The server.py stub references 'create_kernel()' but provides no MCP HTTP/SSE/STDIO transport implementation.
Descriptions are minimal and generic (10 - 40 characters). Most do not explain WHEN to use the tool, WHAT it returns, or any prerequisites. Examples: 'List all available tools in the VibeBridge system' (47 chars, acceptable) vs 'Fix broken/pink shaders on selected material' (44 chars, lacks detail on how/return format). Baseline for A+ is 50 - 200 chars with actionable context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
Get telemetry errors from the kernel
Get telemetry errors from the kernel (slash-separated variant)
Parameter descriptions are trivial. Examples: 'Access capability level (read)' appears in 5+ tools but does not explain what values are accepted, when 'read' vs 'write' apply, or what happens if the wrong capability is passed. 'Parameter keys' and 'Parameter values' are generic placeholders with no semantic meaning.
No output schemas documented. Tools list in the input spec what they return (e.g., material properties, object paths) but actual response structures are not specified. LLMs cannot plan downstream calls or validate responses without documented return types.
Duplicate tool definitions with minor naming variations. 'telemetry/get-errors' and 'telemetry/get/errors' appear to do the same thing (both described as 'Get telemetry errors from the kernel'). This creates ambiguity for LLMs and violates the composition principle of one canonical name per task.
No error handling or recovery guidance. None of the tools document what errors can occur, whether they are retryable, or what the LLM should do if the call fails. The file-based queue system provides no mechanism to communicate structured error responses.
Tool naming inconsistencies. Some use slash-separated (system/list-tools, material/fix-broken-mat), others use underscores (debug_find_optimizer). Schema convention is inconsistent, hindering LLM parsing. Verbs are weak or missing: 'debug_find_optimizer' does not clearly state whether it searches, returns, or creates.
Path/ID parameters lack disambiguation. 'path' in material/fix-broken-mat and object/set/blendshape accept 'Path to the game object', but the schema does not specify format (absolute vs relative, separator style, or example). LLMs cannot reliably construct valid paths without examples or format hints.
No security controls visible. No authentication, permission gates, or audit logging in server.py or the tool definitions. The file-based queue allows any process with write access to inbox/ to invoke tools without authorization.
Numeric parameter constraints are absent. object/set/blendshape accepts 'value' as a number 0 - 100 according to the description, but the JSON Schema does not enforce min/max bounds. LLMs could pass 150 or -1, causing silent failures or unexpected behavior.