Skip to main content
Glama
Sign In
SightRadar MCP Server

SightRadar MCP Server

Official
by sightradar-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Index a photo

index_photo

Index a photo to detect all faces and store them in a collection so they can be found later through face search. Returns each face's bounding box, score, and pixel size.

Instructions

Detect every face in a photo and store them in a collection so they can be found later by search_faces. Returns each face's point_id, bounding box (ratios of image width/height), detection score and pixel size. Faces below the quality gate (det_score < 0.6 or under 24 px) are counted as rejected. Indexing the same photo_id twice fails with already_indexed unless override=true. Use a photo_id that is unique across all your collections: on some older accounts photo ids are shared between collections, so reusing one moves its faces out of the other collection (or is refused with photo_id_in_other_collection). The collection is created if missing. Costs 93 credits.

Input Schema

NameRequiredDescriptionDefault
gcs_keyNoObject key of the photo on the CDN configured for your account (instead of a URL).
overrideNoRe-index and replace the faces of a photo_id indexed before.
photo_idNoYour id for the photo; search results return it. Defaults to a content hash.
file_pathNoPath to the photo on this computer (JPEG, PNG, WebP, GIF, BMP, TIFF or HEIC).
image_urlNoPublic http(s) URL of the photo. SightRadar downloads it; it must be reachable from the internet.
image_base64NoThe photo as base64 (a data: URL is fine). Up to 30 MB decoded. Prefer image_url for large files.
collection_idYesCollection id.
idempotency_keyNoOptional. A retry that reuses the key is never charged twice: if the first call finished, the retry gets 409 duplicate_request_already_processed; if it is still running, 409 duplicate_request_in_flight. Use a new key for each different request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Rich disclosure beyond annotations: exact credit cost (93), the quality gate thresholds (det_score < 0.6 or <24 px), auto-creation of the missing collection, and the two named error codes already_indexed and photo_id_in_other_collection. It doesn't disclose rate limits or concurrency behavior, and the destructiveHint=false annotation is not directly addressed even though reuse of a shared photo_id can move faces out of another collection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then return values, quality gate, error semantics, id uniqueness, and cost in a tight sequence. Every sentence carries operational information an agent needs before calling.

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?

With 8 parameters, no output schema, and a write operation, this description covers what it returns (point_id, bounding box ratios, detection score, pixel size), failure modes, side effects, and billing. Nothing material is missing for a correct call.

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?

Schema coverage is 100%, so the baseline is 3; the description still adds genuine meaning by explaining that photo_id must be unique across all collections and that reuse can relocate faces or trigger photo_id_in_other_collection. The override and idempotency parameters are covered by the schema, so no further credit is warranted.

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 — 'Detect every face in a photo and store them in a collection' — plus the downstream payoff (findable via search_faces). This clearly separates it from siblings like detect_faces (no storage) and search_faces (lookup only).

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 clear when-to-use context (index now so faces can be searched later) and when re-indexing is appropriate (override=true). It doesn't explicitly name detect_faces as the no-persist alternative, so the routing between the two detection tools is left partly to inference.

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

Deploy Server

Other Tools