ipcam-mcp

Overview Schema Source Related Servers Discussions Admin

Record a video clip

camera_record

Record a 1–60 second video clip from an IP camera to a local MP4 file and return its path and size; use a snapshot instead if you need to view the scene.

Instructions

Record a video clip (1-60 s) from a camera to an mp4 file on the local machine. Returns the file path and size; the video itself is not returned, so take a snapshot if you need to see the scene.

quality: "high" = main stream (full resolution set on the camera); "low" = sub stream (smaller file).

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": "<camera>"
    },
    "name": "camera_record"
  }
}

Input Schema

Name	Required	Default
`camera`	Yes
`quality`	No	high
`seconds`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Nov 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds real context beyond the annotations: the tool writes a file to the local machine, the media itself is not returned, and the result is a path and size. That said, it does not say whether existing files are overwritten, where files land, or whether the call blocks for the full duration.

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?

The core sentence is front-loaded and wastes nothing, and the snapshot hint follows logically. The trailing 'quality:' paragraph is loosely formatted rather than structured, and the return-value sentence slightly overlaps the output schema.

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?

For a three-parameter, short-running capture tool this covers the essentials: duration bounds, stream selection, and what comes back. The remaining gap is filesystem behavior (naming, overwrite, location), which an agent may want to know before writing files.

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

Parameters3/5

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

Schema description coverage is 0%, and the description compensates for two of three parameters well: it explains high vs low as main stream/full resolution vs sub stream/smaller file, and restates the 1-60 second bound already in the schema. The required 'camera' parameter is not characterized at all, so the coverage gap is only partly closed.

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 ('Record a video clip') plus concrete scope: 1-60 seconds, from a camera, written as an mp4 on the local machine. It also distinguishes the outcome from the visual-inspection path by pointing at snapshotting, so an agent can tell what it gets and what it does not.

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 a clear use condition ('if you need to see the scene') and routes that need to a snapshot instead, and the quality note implies when to prefer the smaller stream. It stops short of explicit when-not conditions or a stated choice between this and other recording siblings.

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