Skip to main content
Glama
ThatGuyinIT

Brivo Velocity

by ThatGuyinIT

Administrator: List_administrators

Read-only

Retrieve all Brivo administrators, with optional filtering by fields such as ID or name and pagination controls, to inspect admin accounts and roles in an access-control account.

Instructions

List all Brivo administrators.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNoBrivo filter syntax: "<field>__<op>:<value>[,<value>...]", operators eq/ne/gt/lt, multiple filters separated by ";". Example: "id__eq:11,22,33;name__eq:Acme". See the per-endpoint reference for which fields are filterable.
offsetNoSkip the first N results. Default: 0.
pageSizeNoMax results to return. Default: 20. Max: 100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no note on pagination behavior, result scope (all accounts vs. tenant), or what the listing returns. For a zero-effort sentence this is a clear gap.

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

Conciseness3/5

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

It is a single front-loaded sentence with no filler, so nothing is wasted. However, at six words it is under-specified rather than genuinely concise for a tool with three parameters and several sibling alternatives.

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?

For a simple read-only list tool with 100% schema coverage and no output schema, the description is minimally sufficient. It still omits the scope of 'all' (which accounts/tenants) and any pagination expectation, which matters given the near-identical sibling listing tools.

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

Parameters3/5

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

Schema description coverage is 100%, with filter, offset and pageSize each fully documented in the schema (filter syntax, defaults, max 100). The description adds no parameter meaning of its own, so the baseline of 3 applies when the schema does all the work.

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

Purpose3/5

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

The description states a verb and resource ('List ... administrators'), but it largely restates the tool name List_administrators, adding only 'all' and 'Brivo'. It does not distinguish this global listing from the sibling List_account_administrators or from Get_administrator, so an agent cannot tell the scopes apart without opening schemas.

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?

No when-to-use guidance is given. The description never explains when to call this instead of List_account_administrators (account-scoped) or Get_current_administrator, and there are no stated prerequisites or exclusions.

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