lark_get_chat_members

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool gets a member list, but does not disclose pagination behavior, return format, error handling, authorization requirements, or rate limits. The read-only nature is implied but not elaborated.

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

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

The description is a single, concise sentence that gets straight to the point. It is front-loaded and contains no unnecessary words. However, it is essentially a restatement of the tool name, providing minimal additional value beyond clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and the minimal description, the tool is not fully contextualized. The agent learns what it does but not important operational details like how to obtain chat_id, whether member lists are paginated, or if any special permissions are needed. The existence of an output schema mitigates this somewhat, but the description itself is incomplete for seamless invocation.

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

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

The input schema already covers the only parameter chat_id with a description ('群聊 ID'), providing 100% schema description coverage. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate. The parameter is self-explanatory.

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

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

The description '获取群聊成员列表' clearly states the tool's function: retrieving the member list of a group chat. It uses a specific verb (get) and resource (chat members), and it is distinct from siblings like lark_list_chats (list chats) or lark_list_messages (list messages). However, it lacks scope details such as whether members are returned in pages or if filtering is supported.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a chat_id from lark_list_chats), exclusions, or scenarios where another tool would be more appropriate. This leaves the agent without clear selection criteria.

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