Skip to main content
Glama
mpolinowski

camera-mcp

by mpolinowski

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
INSTAR_MQTT_HOSTYesMQTT broker hostname
INSTAR_MQTT_PORTNoMQTT broker port, default 1883
INSTAR_MQTT_PASSWORDYesMQTT password
INSTAR_MQTT_USERNAMEYesMQTT username
INSTAR_MQTT_CAMERA_IDNoCamera ID, default '224'
INSTAR_MQTT_CLIENT_PREFIXNoMQTT topic prefix, default 'cameras'

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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
set_camera_valueA

Set a camera capability value and wait for camera observation confirmation.

Requests a camera setting change via MQTT and waits for the camera's observed state. The operation does not succeed simply by sending the command; it requires fresh observation.

Use list_camera_capabilities to discover valid settings and value types.

Returns result status:

  • confirmed: requested value was observed by camera with confidence OBSERVED

  • clamped: camera applied a different valid value (clamped to allowed range)

  • unchanged: requested value was already freshly observed, no publish necessary

  • timeout: fresh confirmation not obtained within timeout

Result is authoritative based on observed state, not requested value.

get_camera_stateA

Get current observed state of a camera capability.

Returns the most recently observed value with confidence metadata.

Confidence levels:

  • OBSERVED: freshly observed from camera via non-retained MQTT message

  • KNOWN_BUT_STALE: value known but not freshly observed (retained or downgraded after disconnect)

  • UNKNOWN: no state available

Do not treat KNOWN_BUT_STALE as current. For fresh state, wait for observation.

Use list_camera_capabilities to discover valid settings.

wait_camera_stateA

Wait for camera capability to reach expected value.

Blocks until the camera observes the expected value or timeout occurs. Requires fresh OBSERVED confidence, not stale state.

Use this to confirm state changes after set_camera_value.

Returns success when expected value is observed with OBSERVED confidence. Timeout if value not observed within timeout period.

get_camera_healthA

Check operational health and connectivity of camera integration.

Distinguishes between MCP server availability and camera/broker connectivity.

Returns operational state:

  • MCP server alive: process is running

  • MQTT broker connected: broker reachable

  • Camera online: camera publishing state messages

  • Camera offline: broker connected but no camera messages

MCP server starts successfully even if camera is offline. Use this tool to diagnose connectivity issues rather than assuming MCP failure.

get_camera_imageA

Retrieve the most recently received image from camera.

This retrieves a cached periodic snapshot published by the camera. It does NOT trigger a new photograph or snapshot.

INSTAR cameras publish snapshots periodically via MQTT. This tool returns the latest received image if available.

max_age parameter enforces freshness: image rejected if older than max_age seconds. Returns confidence metadata:

  • OBSERVED: live image received after connection

  • KNOWN_BUT_STALE: retained image or downgraded after disconnect

Do not treat stale images as current live images.

Use list_camera_capabilities to find image sources (type=image).

list_camera_capabilitiesA

List all capabilities/settings the camera runtime can operate.

Primary discovery primitive. Returns authoritative capability names, types, writable flags, descriptions, and value constraints.

Always use this before attempting unfamiliar camera settings.

Never construct MQTT topics manually. The server maps capability names to topics via the registry. Hermes must not infer topic names from capability names.

Returns structured list of capabilities with metadata for agent decision making.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing capabilities, setting values, getting state, waiting for state, checking health, and retrieving images. No overlap exists, making tool selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_camera_noun pattern using snake_case (list_camera_capabilities, set_camera_value, get_camera_state, wait_camera_state, get_camera_health, get_camera_image). The naming is predictable and uniform.

Tool Count5/5

With 6 tools, the server is well-scoped for camera control and monitoring. Each tool serves a necessary function without redundancy, fitting the expected range for this domain.

Completeness4/5

The tool set covers core lifecycle operations: capability discovery, setting values, reading state, waiting for confirmation, health monitoring, and image retrieval. A minor gap is the lack of a tool to trigger a new snapshot, but since cameras publish periodically, this is acceptable.

Maintenance

ActivityMaintained
ResponsivenessNo issues