Skip to main content
Glama
mosandlt

Bosch Smart Home Camera MCP Server

by mosandlt

bosch_camera_stream_url

Get the local RTSPS stream URL for a Bosch camera to watch live video in ffmpeg/VLC/go2rtc without cloud relay. Requires same-network host and local credentials.

Instructions

Get the LAN RTSPS stream URL for one camera. No Bosch cloud relay.

The returned URL is consumable by ffmpeg/VLC/go2rtc. Requires that the MCP host runs on the same network as the camera and has local credentials configured for the camera (bosch_config.json → cameras[name].local_*).

With the local data interface active and a local_data_password set, the URL is rtsps://localuser:***@<ip>:9554/rtsp_tunnel?line=1&inst=<1|2>&enableaudio=<0|1> (password masked). quality: "high" (inst=1) or "low" (inst=2); audio: include AAC audio (16 kHz mono).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
audioNo
cameraYes
qualityNohigh

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoLAN-only — MCP host must be on the same network as the camera.
cameraYesCanonical camera name from config
sourceNo'local_data_interface' when the URL uses the camera's local data interfacetemporary_credentials
rtsps_urlYesLAN RTSPS URL via TLS proxy (rtsps://<user>:<pass>@<ip>:443/...)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.8.1
    • addedInput schema / properties / audio
      Added value: +{
      +  "default": true,
      +  "title": "Audio",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / quality
      Added value: +{
      +  "default": "high",
      +  "title": "Quality",
      +  "type": "string"
      +}
    • addedOutput schema / properties / source
      Added value: +{
      +  "default": "temporary_credentials",
      +  "description": "'local_data_interface' when the URL uses the camera's local data interface",
      +  "title": "Source",
      +  "type": "string"
      +}
  2. First observedv1.6.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the load and does so well: it discloses the LAN-only constraint, the credential/config prerequisites, the consumability by ffmpeg/VLC/go2rtc, and the exact URL shape. It omits failure/error behavior when prerequisites are unmet, hence not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, then prerequisites, then the URL template and per-parameter meanings. Every part earns its place, though the inline URL template is dense and slightly heavy for the average invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return-value exposition is not required, and the description still explains the returned URL's usability. Combined with the explicit prerequisites and parameter meanings, it is nearly complete; only error/edge-case behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for 2 of 3 params: quality maps to inst=1/inst=2 ('high'/'low') and audio is defined as AAC 16 kHz mono. The 'camera' param is left implicit but is self-evident from the name, so this is strong rather than perfect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the LAN RTSPS stream URL for one camera') and immediately scopes the source ('No Bosch cloud relay'). This is unambiguous and distinguishable from the many sibling status/snapshot/config tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete preconditions for use: the MCP host must be on the same LAN as the camera with local credentials in bosch_config.json, and the local data interface plus local_data_password must be active. It does not explicitly name alternative tools (e.g. snapshot vs. stream) but the context is clear enough to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools