Skip to main content
Glama

elaichi__member__list

Read-onlyIdempotent

List the people in this organization. Each row carries user_id (a usr_… id), status, join date, the roles and teams that person holds, and user: { id, name, email } — the name and email live outside the membership record and are attached here, so call people by name rather than reading a usr_… id back to the user. Going the other way, q matches name and email case-insensitively across the whole organization and filters before paging, so "find Bob" is one call, not a walk through every page. Every member.* operation, plus team.add_member and team.remove_member, takes the user_id you read here. Returns { result: [...], nextCursor, prevCursor } — camelCase here, unlike the REST API’s next_cursor. Page by sending nextCursor back as cursor until it is null.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoCase-insensitive substring of a member’s name or email address, matched across the whole organization before paging. The only name-or-email → user_id lookup in this catalog.
limitNoRows per page, 1–200 (default 50). Larger values are clamped, not rejected.
cursorNoOpaque cursor taken verbatim from a previous call’s `nextCursor`. Omit for the first page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover read-only and idempotent behavior. The description adds valuable behavior beyond that: q filters before paging, return fields are camelCase unlike the REST API, and pagination is done by sending nextCursor back as cursor. It does not mention auth or rate limits, but given the annotations, this is sufficient.

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 about four sentences and packs in purpose, output shape, q semantics, downstream usage, and pagination rules. It is somewhat dense and could be trimmed, but every sentence carries distinct useful information and the main purpose is front-loaded.

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?

With no output schema, the description compensates by specifying the return shape, row contents, nested user object, pagination fields, and casing difference. It gives the agent everything needed to call the tool correctly and use the results, making it very complete for a list endpoint.

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%, but the description adds real meaning: q is the only name-or-email-to-user_id lookup, it matches case-insensitively before paging, and the cursor parameter is tied to the camelCase nextCursor return field. This goes beyond the schema's basic property 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 opens with a specific verb and resource: 'List the people in this organization.' It clearly distinguishes this list tool from member__get and team__list by emphasizing that each row carries membership roles, teams, and user identity, and that it is the org-wide membership listing tool.

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 explicitly explains when to use q for name/email lookup and frames the tool as the source of user_id for every member.* operation plus team.add_member/remove_member. However, it does not explicitly say 'use member__get when you already have the user_id,' so the when-not guidance is slightly incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources