Loading ToolBench
Cross-platform MCP server for OBSBOT Tiny 2 (UVC) camera control
obsbot-mcp provides 31 tools with consistent naming conventions and generally complete input schemas. Tool names follow verb_noun patterns (obsbot_list_devices, obsbot_wake, obsbot_ptz_move_angle). Descriptions are present for all tools and range from 50-200+ characters. All parameters have type definitions and descriptions. However, there are gaps in output schema documentation, parameter validation guidance, and error handling patterns. The implementation is TypeScript with Zod schemas visible in src/mcp/tools.ts, providing strong schema foundations. Most tools are well-structured for LLM consumption, but some descriptions lack actionable context (e.g., obscure low-level tools like obsbot_debug_probe). Parameter descriptions generally explain purpose but sometimes lack range/constraint details. No critical security issues detected, camera control parameters do not expose credentials. The toolkit shows solid engineering but misses advanced patterns like pagination, streaming, and error recovery guidance.
Set the AI tracking movement speed
Enable/disable AI tracking with specified framing or scene mode
Move the camera to frame a specific pixel in the captured image. Converts pixel coordinates to gimbal angles using the current zoom level. Requires a frame from obsbot_capture_snapshot.
List all active captures (recordings and previews)
Start a live preview stream from the camera (MP4 format to a temp file)
Record video from the camera to a file
Capture a single snapshot frame from the camera at the highest available resolution
Output schemas not documented in visible source. Tool descriptions state what they return (e.g., 'Get the current status') but the response field structure is not declared in the source code provided. LLMs cannot reliably plan downstream operations without knowing the output schema.
Parameter constraints lack specific guidance on valid ranges and formats. Tools like obsbot_ptz_move_angle accept numeric angles but descriptions do not state the valid range (e.g., '-180 to 180 for yaw'). obsbot_ai_tracking mode parameter uses free-form strings instead of a clear enum constraint in the description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Stop any active recording or preview stream
Low-level UVC extension unit diagnostic tool: raw send/get bytes on XU selectors, or query table opcodes. MODE: get (read bytes), set (write bytes), query (frame opcode and read reply). GET: returns hex bytes. SET: takes hex input. QUERY: frames the opcode, reads the reply mailbox, polls for freshness.
Enable/disable face-based autofocus
Get the valid exposure range for the current camera
Get the current status of the camera including zoom, gimbal position, AI tracking state, and other settings
Recenter the gimbal to its home position
List all connected OBSBOT cameras with their serial numbers and capabilities
Save the current gimbal position and zoom as a new preset
Delete a saved preset
List all saved gimbal presets
Recall a saved preset and move to that position
Rename an existing preset
Update an existing preset with the current gimbal position and zoom
Move the camera pan/tilt/roll to absolute angles in degrees
Move the camera pan/tilt/roll at specified speeds with auto-stop
Set manual exposure value
Set field of view to a preset (wide/standard/narrow) or custom zoom
Enable/disable HDR mode
Set image processing controls (brightness, contrast, saturation, etc.)
Put the camera into sleep mode
Wake the camera from sleep mode
Set the zoom to an absolute ratio
Zoom to fit a rectangular region of the frame. Takes pixel coordinates and size, computes zoom level to frame that region.
Zoom to a target ratio with specified speed
obsbot_debug_probe is a low-level diagnostic tool with a complex, mode-driven interface (get/set/query modes with optional payload hex). The description is technical but lacks clear guidance on when LLMs should use it vs. high-level tools, and no recovery pattern is documented for malformed probes.
No error handling or recovery guidance visible in tool descriptions. Tools state what they do but do not hint at failure modes, retryability, or next steps if a call fails (e.g., 'If camera is busy, retry after 2 seconds').
camera parameter is optional across all tools but behavior when omitted is not documented. Does the tool use a default/last-selected camera, fail, or auto-select a single connected device? This dependency should be explicit in all tool descriptions.
No pagination or result limiting documented. capture_list and preset_list tools do not advertise limits on returned items or pagination support. Large capture lists could overflow context.