Skip to main content
Glama
RhombusSystems

Rhombus MCP Server

Official

lpr-tool

Retrieve license plate recognition events, manage saved vehicles and labels, and search or save license plates across your organization.

Instructions

This tool interacts with the Rhombus LPR system to retrieve information about license plate recognition events and registered license plates.

Vs events-tool (camera): events-tool with eventType camera returns that camera’s VOD footage seekpoints (many activity types on the timeline, including vehicle-related activity when present). lpr-tool is for the LPR product surface: plate events, saved vehicles, labels, and plate search APIs across the org—use it when the user needs registry, labeling, or org-wide LPR queries, not only “what showed up on this camera’s timeline.”

The system's cameras may have LPR enabled, and when it is enabled, it will detect "license plate recognition" events when it sees a license plate come into view. However, it is possible that the recognized license is only a partial match, so keep that in mind when using this tool. Users will be able to save license plates into the system, and then additionally label them with a name.

Regarding vehicle labels: Users in the Rhombus LPR system can assign labels to vehicles. When a vehicle (license plate) is assigned a label, and then later is recognized by a rhombus security camera, it will attach the label to the event and will be available on the events returned from (get-saved-vehicles).

You should use the location-tool if trying to pair vehicle events to a particular location. Never use location UUIDs in reports, use names.

As such, if the user is asking anything about a label or labels it would be best practice to first call get-vehicle-labels and then get-vehicle-events or get-vehicle-events.

This tool has 3 modes of operation, determined by the "requestType" parameter:

  • get-vehicle-events: Retrieves a list of vehicle events that have been detected by the system. Please keep in mind that this has the potential to return a lot of data. However, 7 days should be a reasonable time range to start from if the user is not specific.

  • get-saved-vehicles: Retrieves a list of saved vehicles that have been saved in the organization.

  • get-vehicle-labels: Retrieves a list of vehicle labels that have been saved in the organization.

Its very likely that "vehicle", "car", and "license plates" are used interchangeably. Please keep this in mind.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestTypeYesOrg LPR operation (vehicle events, saved vehicles, labels, plate search, save vehicle). Per-camera VOD timeline seekpoints use events-tool (eventType camera).
vehicleEventsArgsYesOnly necessary for requestType 'get-vehicle-events'
timeZoneYesThe timezone for formatting timestamps which should come from the location of the device for the LPR event, or the user's timezone. This is necessary for the tool to produce accurate formatted timestamps.
licensePlateQueryYesLicense plate number to search. Required for 'search-license-plates'.
vehicleNameYesName for the vehicle. Required for 'save-vehicle'.
vehicleLicensePlateYesLicense plate for the vehicle. Required for 'save-vehicle'.
vehicleDescriptionYesDescription for the vehicle. Optional for 'save-vehicle'.
includeFieldsYesDot-notation field paths to include in the response (e.g. "vehicleEvents.vehicleLicensePlate"). Pass null to return all fields. WARNING: some responses can exceed 400k characters — use includeFields to request only the data you need. For high-volume tools this may be required to get a complete answer.
filterByYesFilter array items in the response by field values. All conditions are ANDed. Example: [{field: "vehicleLicensePlate", op: "=", value: "ABC123"}, {field: "confidence", op: ">", value: 0.8}] Use alongside includeFields to get only the specific records and fields you need.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
vehicleEventsNoA list of license plate events, as requested by the request typeget-vehicle-events
vehicleLabelsNoA list of vehicle labels, as requested by the request typeget-vehicle-labels
savedVehiclesNoA list of saved vehicles, as requested by the request typeget-saved-vehicles
licensePlateSearchResultsNoLicense plate search results
saveVehicleResultNoResult of saving a vehicle
errorNoAn error message if the request failed.
Behavior3/5

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

No annotations provided, so description carries full burden. It warns about potential large responses and partial matches. However, it claims '3 modes' while the schema includes 5 modes (missing search-license-plates and save-vehicle), which is a significant omission.

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 sections, bold text for sibling tool comparison, and bullet-like formatting for modes. It front-loads the purpose. However, it is somewhat lengthy and repeats mode names unnecessarily.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers most aspects but misses two schema modes (search-license-plates, save-vehicle). Also lacks explanation of the output schema (though output exists). The description is fragmented with mode details mixed with general notes.

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 baseline is 3. The description adds value by explaining which parameters are used for which modes and providing context like date range recommendation. It enhances understanding beyond the 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?

The description clearly states the tool interacts with the Rhombus LPR system for license plate events and registered plates. It explicitly distinguishes itself from the events-tool, making the purpose unambiguous.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use this tool vs. events-tool (camera), and mentions location-tool for pairing events with locations. Also gives a best practice for labels: first call get-vehicle-labels then get-vehicle-events.

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/RhombusSystems/rhombus-node-mcp'

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