Loading ToolBench
Canon Camera Proxy - MCP server for controlling Canon cameras via CCAPI
The canon-client MCP server has fundamental gaps in definition quality. While 13 tools are registered with descriptions and declared risk levels, the schemas are severely incomplete. Most parameters lack type definitions, only 'connect-camera' shows a fully-formed input schema with typed properties; all other 12 tools have empty input objects ('{}'), which violates the critical rule that parameters must have type definitions. Descriptions are present but generic and often lack actionable detail (e.g., 'Set the aperture (AV) setting' does not explain what values are valid, what range is acceptable, or why the user would call this). No output schemas are documented. Parameter descriptions are minimal, e.g., 'Aperture value' tells an LLM nothing about valid formats (f/1.4, f/2.8, f/8, etc.). Error handling and recovery guidance are absent. The server lacks any tool composition guidance (e.g., which tools typically follow 'connect-camera'), making it difficult for agents to construct multi-step workflows. Overall, this reads as an early-stage prototype that has not been polished for agent consumption.
Change shooting mode of the camera (e.g. "m" for Manual, "av" for Aperture Priority, "tv" for Shutter Priority, "p" for Program AE, "fv" for Flexible Priority, "a+" for Scene Intelligent Auto, "c3/c2/c1" for Custom Modes, "bulb" for Bulb)
Connect to a Canon camera via CCAPI.
Get the present value of the AF operation setting.
Get battery status information
Get date and time setting
Get all of the present values and ability values of the shooting parameters that can be acquired and supported by the Canon camera.
Get storage status
12 of 13 tools have empty input schemas ({}). No parameter type definitions, constraints, or descriptions visible. Violates critical rule: 'If parameters lack type definitions: schema score CANNOT exceed 30.'
Parameter descriptions are vague and lack actionable detail. E.g., 'Set the aperture (AV) setting' with parameter 'Aperture value' tells the LLM nothing about valid values (f/1.4, f/2.8, etc.), range, or format. Descriptions must include constraints, format, and allowed values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get temperature status
Set the aperture (AV) setting
Set the AF operation setting
Set the ISO setting
Set the shutter speed (TV) setting
Take a photo with the camera using the current shooting settings.
No output schemas documented for any tool. LLMs cannot predict the structure of responses, making it impossible to plan downstream tool calls or extract data reliably. E.g., 'get-shooting-settings' likely returns a complex object, but there is no documentation of its shape.
No error handling or recovery guidance. If a camera is offline, a call fails silently. No guidance to the LLM: 'Try reconnecting with connect-camera' or 'Verify the camera is powered on.' Agents have no path forward on failure.
'change-shooting-mode' has an enum parameter 'mode' but the schema shows 'type: enum' rather than a proper JSON Schema enum constraint with a 'const' or 'enum' array listing valid values. LLMs cannot see the allowed values and will hallucinate modes.
No tool composition or workflow guidance. There is no documentation of which tools typically follow 'connect-camera' or how to chain 'get-shooting-settings' with setter tools. Agents must infer the intended workflow.
Status-getter tools ('get-battery-status', 'get-storage-status', 'get-temperature-status', 'get-datetime-setting') lack descriptions explaining what action the user would take based on the returned status. E.g., 'Get battery status' is missing context: 'Call before critical operations; if low, recommend charging or swapping batteries.'