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

Annotations only declare readOnlyHint. The description goes well beyond: a 200-row service cap, a truncated flag meaning items is not exhaustive, broughtInTotal as the authoritative denominator for reporting, and phone numbers masked to the last four digits. These are exactly the failure modes (partial results, wrong counts, redacted fields) that would otherwise cause an agent to misreport.

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?

Dense but every clause carries operational weight: prerequisite, alternative routing, truncation semantics, authoritative count, field meaning, and masking rule. Front-loading the login prerequisite is reasonable, though the packed semicolon structure makes it slightly harder to scan than a lead sentence plus bullets would be.

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?

There is no output schema, so the description must carry return-value semantics — and it does: it explains broughtInTotal, items, truncated, worked, and phone masking. Combined with the sibling routing and login prerequisite, an agent has what it needs to call and interpret this tool correctly.

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?

There is a single parameter with 100% schema description coverage; the schema already states '只看真做过的（建过撮合的）'. The description's 'worked=true 表示这条线索真被你做过（建过撮合）' restates the same meaning rather than adding syntax or edge-case detail, so baseline 3 applies.

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 identifies a specific resource ('我带进独行录的人的可对账整表（分账口径）' — the reconcilable full table of people the caller brought in) and implicitly a list verb. It also names the sibling get_broker_desk as the summary alternative, so the agent can tell the two apart. Only the verb itself is left implicit and the app-specific jargon ('独行录', '分账口径') is opaque to an outside reader.

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?

Explicit routing: use get_broker_desk for summary figures and '别两个都调' (do not call both). It also states a prerequisite ('登录' — login required), which is the kind of gating condition an agent needs before invoking. When-to-use, when-not-to-use, and the alternative are all present.

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