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

The annotations only say idempotent and non-destructive; the description adds the substantive behavior — a two-phase preview/commit with a hash echo, a hard floor of 5000 cents on the fee, creation of a draft PENDING order with no payment taken, and no outreach to the target. It also implies an authentication requirement ("登录").

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?

It is dense and front-loaded, moving from precondition to selection to term-setting to the preview/commit sequence before the terminal caveats. The semicolon-chained, run-on style makes it slightly hard to scan, but almost every clause carries behavioral information rather than 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?

For a 14-parameter, 7-required mutation tool with no output schema, it covers the calling sequence, the fee constraint, the consent gate, and the final state of the result (PENDING only). The gaps are the unresolved relationship between needId and targetUserId and the source of previewHash, both of which an agent must infer.

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 0% across 14 parameters, so the description must do the work; it explains the candidate selection for introducerIds, targetCriteria, serviceType, successCriteria, the fee parameter with its minimum matching schema min 5000, and the coupled preview/previewHash/consent trio. It leaves needId, targetUserId, requesterValue, successCriteriaDetail, and idempotencyKey unexplained, so the compensation is substantial but incomplete.

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?

It states a specific verb+resource with scope: prepare a network introduction where the introducer is privately designated and not disclosed ("私下指定介绍人，不公开"). It also distinguishes itself from adjacent tools: it explicitly points at find_network_candidates for selecting people and clarifies that it only prepares a PENDING order rather than handling payment.

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 a full ordered workflow: first use find_network_candidates to pick candidates, then preview, then call again with identical parameters plus preview=false + previewHash + consent=true after verifying the terms. It also says what happens outside this tool: payment is done in the App and the target still consents per-order, with no automatic contact.

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