ipcam-mcp

Overview Schema Source Related Servers Discussions Admin

Take a snapshot

camera_snapshot

Capture a still from an IP camera and return a downscaled preview plus the full-size JPEG path. Crop or select a region to inspect detail, or reuse an earlier snapshot to zoom without a new capture.

Instructions

Take a still picture from a camera. Returns the image (downscaled to at most 1280 px wide) and the path of the full-size JPEG saved on the local machine.

quality: "high" = main stream (full resolution set on the camera); "low" = sub stream (smaller, quicker). crop: [x, y, w, h] as fractions of the frame (0-1) to see a detail at full resolution. region: a named ninth of the frame instead of crop (not both). from_path: reuse an earlier full-size snapshot (e.g. the one just viewed, or one from scene_timeline) instead of taking a new one; combine with crop/region to zoom into it. The camera is not contacted, and camera may be omitted.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "camera_snapshot"
  }
}

Input Schema

Name	Required	Default
`crop`	No
`camera`	No
`region`	No
`quality`	No	high
`from_path`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Nov 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations only declare the generic profile (readOnlyHint=false, destructiveHint=false), so the description must carry the load, and it does: it discloses that a full-size JPEG is written to the local machine (explaining why this is not read-only) and that from_path mode does not contact the camera at all. It omits error behavior for an unknown camera name or invalid crop fractions.

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 purpose and return values are front-loaded in the first two sentences, then parameter semantics follow in a compact enumerated block. Nearly every clause carries information; the only weak spot is that parameter notes are embedded in prose rather than tied explicitly to schema field names.

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 five-parameter tool with no output schema and no schema descriptions, the definition covers the return contract (downscaling limit, saved JPEG path) and four of five parameters, which is close to sufficient. The unexplained camera parameter and absent failure modes are the remaining gaps.

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?

With 0% schema description coverage, the description must compensate for all five parameters, and it documents four in detail: quality's main vs sub stream meaning, crop as fractional [x, y, w, h], region as a named ninth of the frame with mutual exclusion against crop, and from_path as reuse of an earlier snapshot with camera optional. The camera parameter itself is never described.

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

Purpose4/5

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

The description states a specific verb and resource ("take a still picture from a camera") and even describes the two return artifacts: a downscaled image and the path of the full-size JPEG. It does not differentiate itself from nearby tools such as camera_compare or scene_snapshot, so it stops short of a 5.

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

Usage Guidelines3/5

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

It gives clear mode-selection rules inside the tool: "region ... instead of crop (not both)" and "from_path: reuse an earlier full-size snapshot ... instead of taking a new one." However, it never says when to pick this tool over camera_compare, scene_snapshot, or camera_record, so cross-tool routing is left to inference.

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