Skip to main content
Glama
RhombusSystems

Rhombus MCP Server

Official

access-control-tool

Execute Rhombus access control tasks: unlock doors, list groups, get credentials, activate/deactivate lockdowns, retrieve door schedules and access grants.

Instructions

This tool manages Rhombus access control operations including door unlocking, access groups, credentials, lockdown plans, door schedules, and access grants.

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

  • unlock-door: Remotely unlock an access controlled door. Requires doorUuid.

  • get-groups: List all access control groups in the organization.

  • get-credentials-by-user: List all access control credentials for a specific user. Requires userUuid.

  • get-lockdown-plans: List all lockdown plans in the organization.

  • activate-lockdown: Activate a lockdown plan at a location. Requires locationUuid and lockdownPlanUuid.

  • deactivate-lockdown: Deactivate a lockdown plan at a location. Requires locationUuid and lockdownPlanUuid.

  • get-door-schedules: Get door schedule exceptions for a location. Requires locationUuid.

  • get-access-grants: List location access grants (physical badge/card access). Optionally accepts locationUuid to filter by location. Each grant includes userUuids (directly assigned users), groupUuids (assigned access control groups), and doorUuids (the doors this grant provides access to).

  • get-remote-unlock-users: Get all users who have permission to remotely unlock doors at a location. Requires locationUuid. Returns a list of doors with remote unlock enabled and the users who can unlock each door, based on their permission group roles. This is the correct tool for questions about remote unlock permissions.

Use the get-entity-tool with entityType ACCESS_CONTROL_DOOR to get door UUIDs. Use the user-tool to look up user UUIDs and resolve them to names/emails. Use the location-tool to get location UUIDs.

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 access control request to make.
doorUuidYesThe UUID of the access controlled door. Required for 'unlock-door'.
userUuidYesThe UUID of the user. Required for 'get-credentials-by-user'.
locationUuidYesThe UUID of the location. Required for 'activate-lockdown', 'deactivate-lockdown', 'get-door-schedules', and 'get-remote-unlock-users'. Optional for 'get-access-grants' to filter by location.
lockdownPlanUuidYesThe UUID of the lockdown plan. Required for 'activate-lockdown' and 'deactivate-lockdown'.
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
unlockResultNoResult of unlocking a door
accessControlGroupsNoList of access control groups
credentialsNoList of access control credentials for a user
lockdownPlansNoList of lockdown plans
lockdownResultNoResult of activating or deactivating a lockdown
doorScheduleExceptionsNoDoor schedule exceptions
accessGrantsNoList of location access grants. Each grant contains userUuids and groupUuids that have access to the doorUuids in the grant.
remoteUnlockUsersNoUsers who can remotely unlock doors at a location, grouped by permission group. Always present the COMPLETE list of all users to the end user.
errorNoAn error message if the request failed.
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the behavior of each mode (e.g., unlock-door is a write operation, get-groups is read-only) and warns about large responses. However, it lacks details on side effects, error handling, or permission requirements, which is a moderate gap.

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 bullet points for modes, making it easy to scan. It front-loads the purpose. While it is lengthy due to the number of modes, every section serves a purpose; minor redundancy in parameter explanations could be tightened.

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 tool's complexity (7 parameters, 9 modes) and the existence of an output schema, the description covers modes, required parameters, output filtering, and related tools. It could be more complete by briefly noting what each mode returns, but the output schema reduces that need.

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?

Although schema coverage is 100%, the description adds significant value by clarifying which parameters are required for each mode and providing examples for includeFields and filterBy. This goes beyond the schema's generic descriptions.

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 that the tool manages Rhombus access control operations and enumerates nine specific modes via requestType. It differentiates from sibling tools by explicitly directing users to get-entity-tool, user-tool, and location-tool for UUID lookups, and states that this is the correct tool for remote unlock permissions.

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?

The description provides explicit guidance for each mode, including required parameters. It names alternative tools for prerequisite lookups and includes a warning about large responses. However, it does not explicitly state when not to use this tool versus a sibling beyond those mentions, leaving some implicit inference.

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