Skip to main content
Glama

IvedaAI: Roi

ivedaai_roi
Destructive

Manage video analytics ROIs: create, retrieve, update, and delete regions of interest to control camera alert areas and analysis.

Instructions

IvedaAI API — Roi operations. Response JSON: "status" is the HTTP status code; "truncated"/"timedOut" flag a cut-off response.

GET /api/rois — Find rois query: offset?:integer, page?:any, pageNumber?:integer, pageSize?:integer, paged?:boolean, size?:any, sort?:any, sort.sorted?:boolean, sort.unsorted?:boolean, unpaged?:boolean, ainvrIds?:integer, nameContains?:string, cameraIds?:integer, types?:string enum:CAMERA_ABNORMAL|CROWD_DETECTION|DWELL|FACE_RECOGNITION|FALL|HUMAN_ATTRIBUTE|INTRUSION|LPR, excludeUnused?:boolean, roiIds?:integer, roiParameters?:string

POST /api/rois — Create roi body: RoiRequest — required: cameraId, condition, name, parameter, roiContour; ivedaai_get_schema for all fields

DELETE /api/rois/{roiId} — Delete roi by id path: roiId*:integer

GET /api/rois/{roiId} — Find roi by id path: roiId*:integer

PATCH /api/rois/{roiId} — Patch roi path: roiId*:integer body: RoiRequest — required: cameraId, condition, name, parameter, roiContour; ivedaai_get_schema for all fields NOTE: GET /api/rois/{roiId} returns these fields under a different key — cameraId → camera.cameraId, condition → types, conditionLogic → logical, excludeRoiContour → excludedRegion, isEnabled → enabled, name → eventName, parameter → parameters, roiContour → region[].contour, type → eventType. This endpoint has been confirmed to leave omitted fields alone, so this is for reading the value, not a warning about losing it.

PUT /api/rois/{roiId} — Update roi path: roiId*:integer body: RoiRequest — required: cameraId, condition, name, parameter, roiContour; ivedaai_get_schema for all fields NOTE: GET /api/rois/{roiId} returns these fields under a different key — cameraId → camera.cameraId, condition → types, conditionLogic → logical, excludeRoiContour → excludedRegion, isEnabled → enabled, name → eventName, parameter → parameters, roiContour → region[].contour, type → eventType. This endpoint has been confirmed to leave omitted fields alone, so this is for reading the value, not a warning about losing it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoJSON request body, or form field values when uploading a file.
fileNoLocal file to upload, for operations that accept a file.
pathNoPath parameters, e.g. { "cameraId": 12 }
queryNoQuery string parameters for this operation.
operationYesWhich API operation to call, from the list in this tool's description.
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it explains the response envelope (status, truncated, timedOut flags), details the field mapping between GET /api/rois/{roiId} and PATCH/PUT request bodies, and explicitly notes that PATCH/PUT leave omitted fields unchanged. This complements the destructiveHint annotation by providing actionable, non-obvious detail without contradicting any annotation.

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 description is well-structured with a clear front-loaded overview and a per-operation reference format. However, the long field-mapping NOTE is repeated verbatim for both PATCH and PUT, and the 'ivedaai_get_schema for all fields' phrase appears three times, introducing avoidable redundancy. Despite this, the overall organization makes it easy to scan and locate relevant details.

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 tool exposing six operations, the description is remarkably complete: it covers all operations, query parameters, required body fields, path parameters, response envelope quirks, and a critical field-mapping behavioral note. It also appropriately points to ivedaai_get_schema for full RoiRequest field definitions, filling the one remaining gap without overloading the description.

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

Parameters5/5

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

The input schema offers only generic descriptions (path, query, body), but the tool description enumerates every query parameter for GET /api/rois (with types and a detailed enum), lists the required body fields for create/patch/update, and defines the path parameter type. It also clarifies the field-name transformation between GET and PATCH/PUT responses, adding meaning far beyond the schema's generic property placeholders.

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?

The description clearly enumerates six specific REST operations (GET, POST, DELETE, GET by id, PATCH, PUT) against the /api/rois resource, giving concrete verb+resource pairs for each. This distinguishes ivedaai_roi from its sibling tools, which are named for different IvedaAI resources (e.g., ivedaai_camera, ivedaai_alert).

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or conditions that favor another tool. The usage is only implicitly inferred from the tool name and the listed operations, but there is no direct statement like 'use this for managing ROIs' or 'use ivedaai_get_schema for schema details.'

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/WillORepO/ivedaAI-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server