Skip to main content
Glama

Start Cloud Recording

start_recording

Start Cloud Recording on a camera. This changes what the camera is doing; it is not a read-only query. Confirm with the user before calling it: name the camera and, if you set one, the duration, and wait for them to agree. Never call it to 'check' whether recording works, or as a step in answering some other question. Give both camera_id and recording_id, from list_recordings for that camera; the server refuses a pair that does not match, so a mixed-up id cannot start the wrong camera. It stops by itself after duration_minutes (at most 30) or at stop_at, never both; with neither it records until something stops it. Angelcam rate-limits starting, so a rapid second call may be refused.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "camera_id": "<camera_id>",
      "recording_id": "<recording_id>",
      "session_id": "<session_id>"
    },
    "name": "start_recording"
  }
}

Input Schema

NameRequiredDescriptionDefault
stop_atNoWhen to stop, as a future ISO 8601 UTC datetime (2026-09-15T18:30:00Z).
space_idNoAngelcam space. Call list_spaces; if there is more than one, ask the user which and pass its id - never guess or assume the active one. Reuse it on every later call; omit only with a single space.
camera_idYesCamera the recording belongs to, from find_camera or list_cameras.
session_idYesSession continuity handle, one of two values: the ses_ ID issued for the task underway, or start. This server cannot link your calls between requests on its own, so session continuity travels in this parameter instead. If you were handed a session_id for this task — for example by the agent that spawned you — send that exact value from your first call. Otherwise send start on your first call; the server will issue an opaque correlation ID in the mcp_session field of the result, or in a text block at the start of the result beginning [session_id issued. Then send that exact ses_ value on every later call and hand it to any subagents working the same task. start always begins a new, unrelated task — never send it mid-task. If you send a value this server does not recognize, the result reports it: mcp_session.status of unrecognized, or a text block beginning [session_id unrecognized; re-send the ID issued for this task, or start if none was issued yet. Never invent a ses_ value.
recording_idYesCloud Recording on that camera, from list_recordings.
duration_minutesNoMinutes to record, at most 30. For longer, use stop_at.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety triad (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description adds substantive behavior: the server rejects a mismatched camera_id/recording_id pair, auto-stop semantics via duration_minutes vs stop_at (never both, never neither = records indefinitely), and a rate limit on rapid restarts. That is exactly the extra context annotations cannot carry.

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-loaded with purpose, then confirmation protocol, then prohibitions, then id mechanics, then stop semantics, then rate limits — a sensible priority order with no filler. It is a single dense block whose middle sentences ("Give both camera_id and recording_id...") run long, which costs a little readability.

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

Completeness5/5

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

For a non-idempotent mutation with six parameters and no output schema, the description covers the decision-critical unknowns: user confirmation, id pairing, stopping behavior including the indefinite case, and rate limiting. Nothing an agent needs before calling is missing.

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 coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: the camera_id/recording_id pair is validated server-side so a mixed id cannot start the wrong camera, and duration_minutes and stop_at are mutually exclusive with a 30-minute cap. space_id and session_id are left entirely to their already-detailed schema descriptions.

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?

"Start Cloud Recording on a camera" gives a precise verb and resource, and the following clause ("it is not a read-only query") immediately separates it from the many get_*/list_* siblings. An agent can tell this apart from stop_recording and from read-only inspection tools without opening the schema.

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

Usage Guidelines5/5

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

It states an explicit pre-call protocol (confirm with the user, naming the camera and duration, and wait for agreement) and explicit exclusions (never call it to "check" recording or as a step in another question). It also names the prerequisite source for the ids (list_recordings for that camera).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources