uvc-ptz-camera-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| UVC_PTZ_DEVICE | No | Any substring of the camera name printed by --list-devices. Equivalent to the --device argument. A flag wins over the environment, and an empty value means 'not set'. | |
| UVC_PTZ_BACKEND | No | The backend to use: 'auto' (default, prefer a real camera and fall back to the simulator), 'dshow' (Windows DirectShow), or 'simulator' (no hardware). Equivalent to the --backend argument. A flag wins over the environment, and an empty value means 'not set'. | |
| UVC_PTZ_STATE_DIR | No | The directory used to store state. A flag wins over the environment, and an empty value means 'not set'. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| camera_statusA | Report the camera, its axes and ranges, and whether it is a real device. Call this first. It says which camera was found, the range each axis accepts, where the
camera believes it is pointing (a hint, not proof), what has been calibrated, and -- if
no real device was found -- the reason. |
| aimA | Point one axis at an absolute value, and return what the picture confirms.
This moves the camera and waits for it: allow roughly a second for a gimbal axis and
three for a zoom. |
| nudgeB | Move one axis relative to where the device says it is now. Relative moves inherit the device's reported position, which is a hint: after a series of nudges the accumulated position may drift from belief. The picture check still tells you whether this call moved the camera; it cannot tell you it is at an absolute angle. |
| sweepA | Move an axis smoothly to a value over a chosen duration. Use this for any move that should read as deliberate: a slow pan across a scene, a
gradual push in. The axis is driven by streaming absolute targets at 15 Hz rather than
one jump, which is how this hardware was measured moving smoothly. |
| zoomA | 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. |
| recentreA | Return every axis to the camera's own default: centre, level, unzoomed. |
| lookA | Capture one frame of what the camera currently sees, as a PNG image. This observes the camera's view. Call it when the user asks to see the picture, not on your own initiative, and be aware that a still only tells you what is in front of the lens -- not where the camera is, and not whether a move happened. |
| aim_learnA | Remember the current direction under a name, for later use. Pan is an absolute axis whose meaning depends on where the camera is standing, so
"point at the door" is unanswerable without recording it once. Call this with the camera
already pointed where you want, and the label becomes usable with |
| aim_listA | List the directions recorded for this camera, and its calibrated default pose. |
| go_toA | Point the camera at a direction recorded earlier with Each axis is moved and confirmed from the picture, the same as |
| run_shotA | Execute a multi-step camera move, verifying after every waypoint. Each step is an object: {"axis": "pan", "to": 60, "seconds": 2.5, "ease": "in_out"}. Steps run in sequence and every axis that moves in a step is written on each tick, so a step naming two axes produces a genuine diagonal rather than a staircase. Add {"hold": 1.0} to pause after a step. The whole plan is validated against the camera's advertised ranges before anything moves, so an impossible shot fails without touching the hardware. Afterwards the report gives the picture difference at each waypoint, which is how you tell a shot that happened from one that did not. A long shot takes its full duration; do not set a host timeout shorter. |
| mark_viewA | Store the current picture under a label, so it can be compared later. Useful before a move whose result you will judge later, or to establish what "the wide shot" looks like. Marks live in memory for this session only. |
| check_viewA | Compare the current picture with one stored by Answers "is the camera still looking at what it was looking at?", which is the question a scene change can otherwise hide: a person walking through the shot changes the picture as much as a pan does, so treat a small difference as "still there" and a large one as "worth looking at". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools are clearly distinct by resource or action: status, capture, view comparison, labeling, and axis movement. The main overlap is among the movement tools (aim, nudge, sweep, zoom, go_to, run_shot), which all move the camera but differ by absolute/relative/smooth/sequence semantics; descriptions help, though an agent could still pause over which move primitive to choose.
All names use snake_case, but the structural conventions are mixed: single verbs (aim, nudge, sweep, zoom, recentre, look), verb_noun forms (mark_view, check_view, run_shot), noun_noun (camera_status), and less predictable orderings (aim_list, aim_learn). The set remains readable, but there is no single predictable pattern.
13 tools is within the well-scoped range and each tool has a plausible role: movement, scripting, view memory, calibration labels, status, and capture. The set does not feel bloated, and the extra tools support verification and repeatability rather than duplicating obvious functionality.
Core PTZ workflows are covered: status, capture, absolute/relative/smooth movement, zoom convenience, recentre, position labels, view comparison, and multi-step shots. Minor gaps remain, such as no explicit abort/stop for long-running moves and no delete/list operations for stored marks or aim labels, but these are workable within session-only memory.