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

Beyond annotations (which already cover read-only, idempotent, non-destructive, open-world), the description discloses login requirement, server-side viewer-based trimming of participants and edges, inclusion of cloud users, default status filtering, a 60-item cap, and that scores cannot be interpreted as business commitments.

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 dense but front-loads the core purpose, then layers status defaults, limits, origin semantics, and a combo chain. Every sentence carries useful information, though it could be more scannable with structure.

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 absence of an output schema, the description is complete enough: it covers authentication, permission scope, viewer-based data trimming, default and explicit status options, result limits, origin meaning, and the surrounding workflow chain.

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?

Schema description coverage is only 33%, but the description compensates by explaining the default value and semantics of status (SUGGESTED vs ALL vs DISMISSED) and the meaning of kind values (PAIR vs GROUP). organizationId is already documented in the schema.

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 states a specific verb (查看) and resource (组织/联盟空间里的两人对接 PAIR 或 AI 拉会 GROUP), and distinguishes the two result kinds (PAIR vs GROUP). It also names related tools in the combo chain, letting an agent tell it apart from siblings like list_organization_match_pairs.

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?

It gives clear usage context: default status is SUGGESTED, ALL means SUGGESTED+CONVERTED, and DISMISSED must be explicit. The combo chain shows where this tool fits relative to list_my_spaces and downstream tools, though it does not explicitly state when not to use it versus other list tools.

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