Stows the camera gimbal face-down to a fixed pitch, moving it from its current pose. Use to put the camera to sleep before stopping; wake restores it.
Sleep the camera/gimbal (sends "sleep"). This MOVES the camera: sleeping STOWS the gimbal, tilting it face-down to roughly pitch 84°, so obsbot_gimbal_position will read ~84 rather than the pose you left it in. obsbot_wake un-stows it.
| Name | Required | Description | Default |
|---|---|---|---|
| camera | No |
Changes observed during successful MCP inspections.
v0.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the critical non-obvious side effect: sleeping moves the camera by stowing the gimbal to pitch ~84, which will change obsbot_gimbal_position. It also explains that wake reverses the action, so the agent knows the state impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the action first, then the movement consequence, then the inverse. Every sentence adds relevant information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter command with no output schema, the description covers purpose, side effects, and state consequences well. It falls just short of complete because the parameter's accepted values are undocumented and there is no explicit statement about the expected return/status, but these are minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description never mentions the single 'camera' parameter, so the agent must infer that it identifies which camera/gimbal to sleep. It does not state whether this expects a device ID, name, or index, though the parameter's name and optionality give a weak clue.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Sleep the camera/gimbal') and immediately clarifies what sleeping means by noting the gimbal is stowed face-down at roughly pitch 84. It also names the inverse sibling (obsbot_wake), so the tool is easily distinguished from wake and other gimbal commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It is clear that sleep is the command to stow the gimbal, and the mention that obsbot_wake un-stows it gives the agent the counterpart. It does not explicitly state exclusions or conditions (e.g., when to prefer gimbal_move or recenter), but the usage context is implied strongly enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.