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

Beyond the readOnly/idempotent annotations, the description discloses important behaviors: 200-row service-layer caps with no cursor, truncation semantics where counts/broughtInTotal are authoritative, phone data masking to hasPhone/phoneTail4, and a shared 24-hour rolling quota between introLeft and update_broker_match. These are substantial behavioral details that materially affect how an agent should interpret results.

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 well-structured with clear sections: 【需要登录】, 【组合链】, and 【口径】. Each block earns its place: login requirement, workflow position, and critical data-caliber caveats. The front-loaded overview makes the tool's purpose immediately clear, and the bulleted口径 section is easy to scan.

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?

For a complex aggregate tool with no output schema, the description covers a lot: response sections, quota fields, truncation behavior, contact-field masking, and the shared quota. It still leaves some ambiguity around what the '首屏六个数' actually are and what leadLimit controls, so it is not fully complete, but it is sufficient for safe 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 description adds meaning to matchStatus ('用 matchStatus 缩小范围再读') and explains the truncation context that makes that parameter important. However, leadLimit is not described in the schema and is not explicitly tied to '最近线索' in the description, leaving one parameter underspecified. With 67% schema coverage, the description partially compensates but not fully.

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 a specific verb-resource relationship: '一次拿全撮合台' (get the entire matching desk in one call) and enumerates its contents: six headline numbers, recent leads, match list, attribution summary, and quota remainders. It also distinguishes itself from the App's four-tab/four-request pattern, making it identifiable as a consolidated dashboard rather than a single-list helper.

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 strong usage context: login is required, this is the entry point of a named combination chain, and it explains when to rely on counts versus items via truncated.*. It does not explicitly state when NOT to use this tool or name alternatives like list_broker_leads/list_broker_attributions, but the chain and aggregation framing give clear operational context.

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