Loading ToolBench
A Model Context Protocol server for WDP camera control that manages camera views, settings, and provides tools for camera information retrieval and control
This server has fundamental quality gaps across naming, descriptions, schemas, and error handling. Of 5 tools, 3 have inadequate descriptions (<20 chars), 2 lack proper parameter typing, and none include output schema documentation. The naming is inconsistent (some follow verb_noun, others are unclear). Parameter descriptions are missing entirely for several required/optional fields. No error handling guidance is present. The server mixes camera control with a basic notes system without clear boundaries.
Stop camera movement
Create a new note
Get camera information and status
Send message to WebSocket server
Update camera parameters and control settings
get_camera_info description is 42 characters ('Get camera information and status') but has NO explanation of when to use it vs update_camera, what it returns, or whether guid is actually required (schema shows required: [], contradicting the description parameter hint). This violates the WHEN to use principle, the LLM cannot distinguish this from similar tools.
camera_stop and send_message descriptions are vague and too short (<30 chars). 'Stop camera movement' does not explain: Is this safe to retry? Does it affect other cameras? What parameters must be passed? 'Send message to WebSocket server' does not explain the message format, expected response, or error handling.
update_camera has complex nested schema (location [x,y,z], rotation with pitch/yaw, multiple *Limit arrays) but NO parameter-level descriptions. The description only says 'Update camera parameters and control settings' (39 chars). The LLM cannot infer: What do pitch/yaw angles mean? Are they degrees or radians? What are valid ranges for location coordinates? What does locationLimit represent?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
send_message parameter 'message' has a trivial description ('Message to send'). No format constraints: plaintext? JSON? Binary? Length limits? Required fields? The WebSocket server expects a specific protocol, but the LLM has no guidance on what to send.
NO tool includes output schema documentation. Production rules require documented return types so agents know what fields to expect. E.g. create_note should document: returns {id: string, title: string, content: string, created_at: ISO8601}. get_camera_info should document the CameraDataInfo structure. Without this, downstream tool chaining is broken.
Error handling is absent. No tool description mentions what errors could occur, when to retry, or how to recover. E.g. if get_camera_info is called with an invalid guid, what happens? Is there a suggestions list of available cameras? Does send_message fail gracefully if the WebSocket is disconnected? Agents have no recovery guidance.
guid parameter in get_camera_info and camera_stop is marked required: [] (optional) but described as required in intent. Additionally, the schema has no enum of valid GUIDs, format constraints, or pattern. The code has predefined camera names ('Reception', 'ConferenceRoom1', etc.), the tool should guide the LLM to use those, not arbitrary GUIDs.
Naming ambiguity: 'send_message' is vague, send to whom? To the WebSocket server? To a user? To a camera? This violates the principle that names alone should convey intent. A clearer name would be 'send_websocket_message' or 'send_camera_command'.
Tool composition issue: update_camera accepts optional guid (defaults to empty string per description) but get_camera_info also accepts guid. The relationship is unclear, does update_camera require a prior get_camera_info call? Can it fail if the camera doesn't exist? No guidance on the interaction.
Parameter 'guid' in multiple tools has no description of its format. Is it a UUID? A string ID? How is it obtained? The code shows predefined camera names in CameraDatas object (e.g., 'Reception'), are these valid guids, or is guid separate? The tool design forces the LLM to guess.