ipcam-mcp

Overview Schema Source Related Servers Discussions Admin

Add a camera

add_camera

Registers an ONVIF/RTSP IP camera by IP address and short name, keeping credentials out of the conversation via a login form or a user-filled secrets file.

Instructions

Add an ONVIF/RTSP IP camera. Ask the user for the camera's IP address (from its app or router) and pick a short name such as "garage".

Credentials are never passed as arguments: by default the user is shown a login form; with credentials_via="file" a secrets file is created for the user to fill in, then call add_camera again with credentials_via="file". Use credentials_via="file" when the user is on Remote Control or a phone and the form does not appear.

onvif_port: only if the camera uses a non-standard ONVIF port (80 and 2020 are tried). scene: the place it watches, if not its own name (several cameras may share a scene).

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": {
      "name": "<name>",
      "host": "<host>"
    },
    "name": "add_camera"
  }
}

Input Schema

Name	Required	Default
`host`	Yes
`name`	Yes
`scene`	No
`onvif_port`	No
`credentials_via`	No	form

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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation, so the safety profile is covered. The description adds behavior the annotations cannot: credentials are never arguments, the default flow pauses for a user-facing login form, and the file variant requires a second add_camera call. It does not mention what happens on failure or duplicate names, keeping it short of 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 action and then the credential flow, which is the hard part, in a few tight sentences. The per-parameter notes at the end are useful but read as a loose list rather than a structured block, and the repeated restatement of credentials_via="file" is slightly redundant.

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 mutation tool with five parameters and a documented output schema, the description covers the genuinely tricky parts: the two-phase credential handshake and the port fallback. The main remaining gap is error/retry behavior and duplicate-name handling, which an agent would have to discover at call time.

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%, so the description must carry the load, and it does explain scene, onvif_port (non-standard port; 80 and 2020 auto-tried), and both values of credentials_via. However, host and name are only described obliquely ('IP address from its app or router', 'short name such as garage') without being tied to the field names, and no format constraints are given, leaving a meaningful gap against a fully undocumented schema.

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: 'Add an ONVIF/RTSP IP camera,' which is unambiguous next to siblings like rename_camera, remove_camera, and list_cameras. It also immediately names the first required inputs (IP address, short name), so an agent knows what it must collect.

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 concrete decision rule for credentials_via: default is a login form, but use "file" when the user is on Remote Control or a phone and the form does not appear, plus the instruction to call again after the file is filled. It doesn't discuss preconditions (e.g., camera reachable, duplicates by name), but the main conditional path is explicit.

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