Set the camera's optical magnification ratio, where 1.0 is wide and higher values narrow the view. The requested value is clamped to the supported range and returned.
Set optical zoom as a multiplier: 1.0 is wide, up to the camera's maximum.
Convenience over the raw zoom axis, which counts in hundredths. The requested ratio is clamped to what the camera supports and the clamped value is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| ratio | Yes |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a real behavioral trait: the requested ratio is clamped to hardware limits and the clamped value is returned, which tells the caller the value may not be honored as requested. It stops short of saying whether zoom persists across other operations, what permissions or connection state are needed, or how it interacts with concurrent camera tools.
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?
Three short sentences, front-loaded with the action and the value semantics before the contrasting/raw-axis note. No filler, no restatement of the tool name or the schema title.
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 one-parameter, no-output-schema tool, the description covers value semantics, hardware limits, clamping, and the return of the resolved value – everything needed to call it correctly. The remaining gap is environmental context (does it require an active camera session, does zoom persist), which is minor.
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% for the single 'ratio' parameter, so the description must compensate and does: it defines the unit (multiplier, not hundredths), the anchor point (1.0 is wide), the upper bound (camera maximum), and the clamping behavior with returned resolved value. That is more meaning than the bare name 'ratio' conveys by a wide margin.
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 gives a specific verb+resource ('Set optical zoom') and immediately defines the value domain: a multiplier where 1.0 is wide, up to the camera's max. It also positions itself as a convenience layer over the raw zoom axis. It does not distinguish itself from any of the listed siblings (aim, nudge, sweep), but the intent is unambiguous.
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?
Usage is only implied: the reader learns this is the 'convenience' alternative to the raw hundredths-based zoom axis, but that raw tool isn't among the siblings and no when-to-use/when-not guidance is given relative to aim, look, or the other camera tools. An agent can infer the appropriate context but is not told explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.