Skip to main content
Glama
beel-es

BeeL MCP server

Official
by beel-es
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

beel_list_member_grants

Read-onlyIdempotent

Fetch the companies (NIFs) a member can access, along with each access level. Use to audit member grants within an account.

Instructions

Lists the companies (NIFs) granted to a MEMBER and the access_level of each. Empty for OWNER and ADMIN, who reach every company of the account implicitly and hold no grants.

Paginated with the usual page/limit, and the usual defaults: without them you get the first 20 grants, not all of them. Read data.pagination to walk the rest.

Endpoint: GET /v1/accounts/{account_id}/members/{member_id}/grants

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, starting at 1. The response echoes it back as `pagination.current_page`.
limitNoHow many items to return per page. The response echoes it back as `pagination.items_per_page`.
member_idYesMembership unique UUID.
account_idYesYour own account, or an account you provisioned. It — not the credential — decides which account the operation acts on; a `403` is returned when you do not reach it, the same response an account that does not exist gets.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 20,
+  "description": "How many items to return per page. The response echoes it back as `pagination.items_per_page`.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / page
      Added value: +{
+  "default": 1,
+  "description": "Page number, starting at 1. The response echoes it back as `pagination.current_page`.",
+  "minimum": 1,
+  "type": "integer"
+}
  2. First observedv0.3.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish the operation as read-only, idempotent, and non-destructive. The description adds genuine extra behavioral detail: OWNER/ADMIN return empty grant lists, pagination defaults to the first 20, and data.pagination must be followed to fetch the rest. No contradiction with annotations.

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?

The core purpose is front-loaded in the first sentence, followed by the role exception, pagination behavior, and endpoint in compact sections. Every sentence earns its place and there is no redundant filler.

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?

Despite lacking an output schema, the description covers what is returned (NIFs and access_level), the edge case for OWNER/ADMIN, pagination traversal, defaults, and the endpoint. For a read-only list operation this is sufficient for an agent to invoke and interpret the call correctly.

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 description coverage is 100%, so this starts at baseline 3. The description adds interpretive value by warning that omitting page/limit yields only the first 20 grants, not the full set, and by pointing to data.pagination for navigation. account_id and member_id semantics are already well documented in 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 uses a specific verb ('Lists') and precisely identifies the resource: the companies (NIFs) granted to a member plus the access_level of each grant. It also distinguishes itself from member-level or company-level list tools by explaining the OWNER/ADMIN exception.

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?

It provides clear context: this is for reading grants, grants are empty for OWNER/ADMIN, and pagination is required to see beyond the first 20 items. It does not explicitly name sibling alternatives or exclusion conditions, but it gives enough role-specific guidance to decide when the call is meaningful.

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