Skip to main content
Glama
Sign In
AliMail Admin MCP

AliMail Admin MCP

by mfc-open
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

查询用户列表

list_users
Read-onlyIdempotent

Query organization users by LDAP-style filters and cursor pagination to find accounts by email, name, department, status, or role. Use nextCursor for more results, up to 100 per page.

Instructions

按 filter 表达式查询组织内用户，游标分页（单页最多 100）。 filter 支持字段：email、name、nickname、employeeNo、status、domain、employeeType、delegateType、departmentId、jobTitle、workLocation、homeLocation、info、managerId、isSharedWithOthers。 示例：(departmentId=xxx) 直属成员；(departmentId=xxx*) 含子部门；(|(name=Jack)(email=jack))；(&(employeeType=SERVICE)(email=abc))；(&(departmentId=xxx)(!(status=FREEZE)))。 返回 hasMore=true 时用 nextCursor 继续翻页。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_users"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNo每页数量，最大 100
orderNoASC 升序 / DES 降序
cursorNo上一页返回的 nextCursor
filterNoLDAP 风格过滤表达式
selectNo透传 $select，指定额外返回字段，多个用英文逗号分隔，如 phone,managerEmail,isHidden
managedNo仅返回当前身份可管理的用户
orderbyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's real contribution is the pagination contract: 100-item page cap and the hasMore→nextCursor continuation rule. It still omits scope details such as whether results span the whole organization and what happens on an invalid filter.

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?

Front-loads the operation and pagination, then systematically lists filter fields and examples. Every sentence and example carries information an agent needs to build a valid filter; nothing is padding.

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?

No output schema exists, yet the description covers the return contract (hasMore, nextCursor) and the hardest part of invocation, filter syntax. Combined with a mostly-documented 7-parameter schema and safety annotations, an agent has everything needed to call it 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 coverage is already 86%, and the description still adds genuinely new meaning: the full set of filterable fields and several concrete LDAP expression examples (direct members, sub-departments, negation, OR/AND composition). That goes well beyond the schema's 'LDAP 风格过滤表达式'.

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?

States a specific verb and resource ('查询组织内用户') plus the mechanism ('按 filter 表达式') and pagination, so the agent knows exactly what the tool does. It does not, however, differentiate itself from close siblings such as list_department_users or get_users_by_ids.

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?

Usage is implied by the filter example catalog (e.g. department vs sub-department scoping), but there is no explicit statement of when to choose this over list_department_users or get_users_by_ids, and no exclusions or prerequisites.

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