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

Beyond the annotations (readOnlyHint=false, idempotentHint=true), it discloses login requirement, order-insensitivity of pairs, the side effect of marking both leads worked=true with revenue-split impact, and execution semantics (processed one by one, failures do not interrupt). These are exactly the behavioral traits an agent needs before calling, and they are consistent with the annotations.

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?

Front-loads the login prerequisite and the action, then the workflow chain, then reason content rules, then the destructive side-effect warning. Every clause carries actionable information with no filler.

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?

No output schema exists, yet the description covers prerequisites, batch limit, workflow context, side effects, and per-item failure behavior, which is everything needed to invoke it correctly. Nothing material is left to inference.

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 100%, so the baseline is 3, but the description adds meaning the schema does not: pairs are not left/right ordered, bUserId lets you pass an in-site person not yet in the pool, and reason must be human-language rationale with no scores since it is shown verbatim on four surfaces. That is real semantic guidance beyond the field docs.

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?

States a specific verb+resource (create matches / 建撮合) plus scope (after user confirmation, max 20 pairs). It clearly distinguishes itself from the sibling scan_broker_matches by describing itself as the confirmation step that produces the match. An agent can tell it apart from update_broker_match and create_broker_lead without opening the schema.

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?

Gives an explicit pipeline: scan_broker_matches → user confirmation → this tool → get_broker_intro_scripts (external) or introduce_broker_match (in-site group). It also states a when-not: do not use for test runs because leads get marked worked=true and revenue split is affected.

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