Medium Risk

camera-tool

This tool can perform some action pertaining to the video stream of a camera. There are four types of requests that can be passed into "requestType": - image - get-settings - get-media-uris - get-ai-thresholds What follows is a description of the behavior of this tool given the requestType "image...

Part of the Rhombus Node server.

camera-tool can modify Rhombus Node data, with no limits today. PolicyLayer puts allow, deny, and rate-limit rules on every call. Live in minutes.

SECURE RHOMBUS NODE →

Free to start. No card required.

AI agents use camera-tool to create or modify resources in Rhombus Node. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.

Without a policy, an AI agent could call camera-tool repeatedly, creating or modifying resources faster than any human could review. PolicyLayer's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach Rhombus Node.

Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.

policy.json
{
  "version": "1",
  "default": "deny",
  "tools": {
    "camera-tool": {
      "limits": [
        {
          "counter": "camera-tool_rate",
          "window": "minute",
          "max": 30,
          "scope": "grant"
        }
      ]
    }
  }
}

See the full Rhombus Node policy for all 31 tools.

Get this rule live on your own Rhombus Node server in minutes. PolicyLayer enforces it on every call, before it runs.

ENFORCE ON MY RHOMBUS NODE →

View all 31 tools →

These attack patterns abuse exactly the kind of access camera-tool gives an agent. Each links to the full case and the policy that stops it:

Browse the full MCP Attack Database →

Every attack above starts with a tool call. PolicyLayer checks each one against your policy first, so camera-tool only ever does what you allow.

SECURE RHOMBUS NODE →

Other write tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.

What does the camera-tool tool do? +

This tool can perform some action pertaining to the video stream of a camera. There are four types of requests that can be passed into "requestType": - image - get-settings - get-media-uris - get-ai-thresholds What follows is a description of the behavior of this tool given the requestType "image" This tool should be used any time someone wants to specify a subset of cameras to use for a task, based on some features that the camera sees. For example, interior cameras, cameras facing the street, cameras with a view of X, Y, Z, etc. For instance if someone says "I want X using cameras with Y" then this tool should get a snapshot of the image to answer the question of if the camera satisfies the Y predicate. This tool captures and returns a real-time snapshot from a designated security camera. The image reflects the current scene in the camera's field of view and serves as a contextual input source for downstream tasks such as object recognition, anomaly detection, incident investigation, or situational assessment. When invoked, the tool provides the following: - Visual Scene Capture: A high-resolution image of what the camera is actively observing, including people, vehicles, license plates, and any detectable objects. - The frameUri that was used to fetch the image. It may be useful to show the user this image as well through the frameUri. What follows is a description of the behavior of this tool given the requestType "get-settings" This tool retrieves the current configuration for a specified camera or associated device (e.g., sensor, access controller). The returned JSON object can include detailed camera settings (e.g., resolution, bitrate) and various device-specific configurations (e.g. storage settings). NOTE: To update camera settings, use the update-tool instead. --- AUTOMATIC SNAPSHOT FOR IMAGE QUALITY ISSUES — When a user mentions camera image quality (darkness, brightness, blur, washed out, "doesn't look great", "fix the image", etc.), you MUST IMMEDIATELY: 1. Call camera-tool with requestType "image" to capture a snapshot WITHOUT asking first. 2. Analyze the image to identify quality issues. 3. Call camera-tool with requestType "get-settings" to check current camera settings. 4. Propose specific setting changes based on your analysis (store the exact values you plan to change, e.g. img_brightness, wdr_strength). 5. When the user confirms ("yes", "confirm", "fix it", "apply", "go ahead", "ok", etc.), call update-tool with those stored settings — see update-tool's description for the confirmation flow. NEVER skip the update-tool call. Examples that REQUIRE the automatic snapshot flow: - "This camera's image doesn't look great" - "The image quality is poor" - "Can you fix the image" - "Adjust settings to be optimal" - "The camera looks blurry/dark/washed out" - Any mention of image appearance problems. VISUAL-FEATURE CAMERA FILTERING — When the user asks for cameras filtered by what they can see (indoors/outdoors, "facing the street", "with a view of X", parking lot, entrance), you MUST: 1. First get the camera list via get-entity-tool or location-tool. 2. Then call camera-tool with requestType "image" for EACH candidate camera (in PARALLEL). 3. Analyze each image to determine if it meets the user's criteria. 4. Return only the cameras that match. Output filtering (all tools): - includeFields (string[]): Dot-notation paths to keep in the response (e.g. "vehicleEvents.vehicleLicensePlate"). Omit to return all fields. - filterBy (array): Predicates to filter array items. Each entry: {field, op, value} where op is one of = != > >= < <= contains. All conditions are ANDed. Example: [{field:"vehicleLicensePlate", op:"=", value:"ABC123"}] WARNING: some tool responses exceed 400k characters — use these params to request only the data you need.. It is categorised as a Write tool in the Rhombus Node MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

How do I enforce a policy on camera-tool? +

Register the Rhombus Node MCP server in PolicyLayer and add a rule for camera-tool: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Rhombus Node. Nothing to install.

What risk level is camera-tool? +

camera-tool is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Can I rate-limit camera-tool? +

Yes. Add a rate_limit block to the camera-tool rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block camera-tool completely? +

Set action: deny in the PolicyLayer policy for camera-tool. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides camera-tool? +

camera-tool is provided by the Rhombus Node MCP server (rhombus-node-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.

Enforce policy on every Rhombus Node tool call.

Deterministic rules across all 31 Rhombus Node tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.

Free to start. No card required.

4,600+ MCP servers and 31,000+ tools scanned and risk-classified.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.