Skip to main content
Glama
RhombusSystems

Rhombus MCP Server

Official

user-tool

List and find users, view permissions and permission groups for Rhombus physical security systems.

Instructions

This tool manages Rhombus user operations including listing users, finding users by email, and viewing permissions.

It has the following modes of operation, determined by the "requestType" parameter:

  • list-users: List all users in the organization with their details and roles.

  • find-by-email: Find a specific user by their email address. Requires the email parameter.

  • get-permissions: Get the permissions for the current API user/token.

  • get-permission-groups: List all permission groups defined in the organization. Each row can be very large — see below.

User UUIDs returned here can be used with the access-control-tool to look up credentials.

IMPORTANT for 'get-permission-groups': Each permission group row includes five access maps whose size scales with the org's locations, devices, and other permission groups. The total payload for 'userPermissionGroupAccessMap' across all rows grows O(N^2) in the number of permission groups. Before calling, decide which fields you actually need and pass them via 'includeFields':

  • Safe/small fields (O(1) per row): 'permissionGroups.uuid', 'permissionGroups.name', 'permissionGroups.description', 'permissionGroups.mutable', 'permissionGroups.superAdmin', 'permissionGroups.installer', 'permissionGroups.defaultPermissionForNewLocations', 'permissionGroups.defaultAccessControlPermissionForNewLocations'.

  • Bounded fields (O(K) per row): 'permissionGroups.functionalityList', 'permissionGroups.accessibleLocations', 'permissionGroups.assignablePermissionGroups'.

  • Heavy fields (O(locations) / O(devices) / O(groups) per row): 'permissionGroups.locationAccessMap', 'permissionGroups.accessControlLocationAccessMap', 'permissionGroups.deviceAccessMap', 'permissionGroups.userPermissionGroupAccessMap', 'permissionGroups.locationGranularAccessMap'. Only request these when you specifically need them for a user. Typical usage when just picking a role uuid: 'includeFields: ["permissionGroups.uuid", "permissionGroups.name", "permissionGroups.description"]'.

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
requestTypeYesThe type of user request to make.
emailYesThe email address of the user to find. Required for 'find-by-email'.
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
usersNoList of users in the organization
userNoA single user found by email
permissionsNoCurrent user permissions
permissionGroupsNoList of permission groups in the organization.
errorNoAn error message if the request failed.
Behavior4/5

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

With no annotations, the description fully carries the burden of behavioral disclosure. It warns about response sizes (400k+ characters), explains the O(N^2) growth for permission group access maps, and recommends field filtering. This is comprehensive for a user management tool.

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 relatively long but well-structured with sections and bullet points. It is front-loaded with the tool's purpose and then dives into details. Each sentence seems necessary, though some redundancy could be trimmed (e.g., repeating the warning about response size in includeFields description).

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?

Given the complexity (four modes, output filtering, heavy payload warnings) and the existence of an output schema, the description is mostly complete. It covers all modes, filter parameters, and performance considerations. It does not mention error handling or rate limits, but those are beyond typical expectations for a tool 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 description adds significant meaning beyond the input schema. For requestType, it explains each mode. For includeFields and filterBy, it provides examples and notes on performance. The schema coverage is 100% but the description enriches understanding, especially for the complex filtering and mode selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages Rhombus user operations with four specific modes. It mentions using UUIDs with access-control-tool, which helps differentiate, but does not explicitly contrast with other user-related sibling tools like user-audit-tool.

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

Usage Guidelines3/5

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

The description provides guidance on when to use each requestType and warns about heavy payloads for get-permission-groups. It also suggests using includeFields and filterBy to control output. However, it does not compare with sibling tools or specify when to use this tool versus alternatives like user-audit-tool.

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