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

With only readOnlyHint supplied, the description carries the burden and delivers: a login requirement, a hard 200-item cap with no cursor, the truncation contract (only counts/broughtInTotal stay complete when truncated), contact-info masking to existence plus last 4 digits, and a shared 24h quota for INTRODUCED backfill and group creation. These are exactly the auth, rate-limit and data-shape disclosures an agent needs before calling.

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?

Extremely dense and front-loaded — the resource and payload come first, caveats after — with no filler sentences. The telegraphic semicolon style and the cryptic 'INTRODUCED补记与拉群共用24h额度' clause cost a bit of readability.

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 3-parameter read tool with no output schema and no annotations beyond readOnlyHint, the description covers payload content, pagination limits, truncation behavior, privacy masking and quota coupling. The only material gap is leadLimit semantics and how it interacts with the server-side 200 cap.

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 coverage is 67%, and the description adds real meaning where the schema is thin: it explains why matchStatus exists (narrowing to stay under the 200-item truncation threshold) and maps the sections enum values onto the described response blocks. leadLimit's interaction with the 200 cap is never explained, which keeps it off a 5.

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 names a specific verb/resource (my broker desk) and enumerates exactly what the response aggregates: totals, leads, matches, attributions, plus introLeft/leadsLeft counters. This distinguishes it from the list_broker_leads / list_broker_attributions siblings as an aggregate overview rather than a filtered list, though it never names those alternatives explicitly.

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?

Usage is implied rather than stated: 'use matchStatus to narrow the range' is the only directive, and it applies to a parameter choice, not to choosing between this tool and the sibling list/scan tools. There is no explicit when-to-use or when-not-to-use statement.

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