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

With no annotations, the description carries the full burden and does substantial work: it discloses the two-phase preview/confirm flow, that consent and phone-number usage authorization are transferred to organization staff, that unshared contacts are never revealed to the requester, and that no automatic contact occurs ("不自动联系本人或目标"). The remaining gaps — what the preview returns, whether repeated calls create duplicate requests, failure modes — are minor for this kind of tool.

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 text is short and free of filler, but it is organized as a run-on procedure rather than front-loading the purpose, and the privacy guarantee is buried after the process clauses. Reordering so the action leads and the preview/consent steps follow would improve scanability at the same length.

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?

Six parameters, no annotations, and no output schema, so the description needs to do more than it does. It covers privacy, consent, and the preview handshake well, but leaves the previewHash round-trip, expected result of a successful request, and what happens after staff follow up unaddressed.

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 0%, so the description must compensate. It explains the semantics of three parameters functionally (preview gating, consent/authorization, note as the communication purpose) and implies organizationId and targetId, but it never names them and says nothing about previewHash, which the pattern and preview flow strongly suggest must be carried from the preview step. Useful but partial compensation for six undocumented parameters.

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 conveys that the request hands the communication purpose and phone-number authorization to the organization's staff, which indirectly reveals the action. However, it leads with the procedure ("先读当前可联系状态并预览，再确认…") rather than a headline verb+resource, and it never distinguishes itself from nearby siblings such as create_connection_request, request_contact_exchange, or create_quick_contact_request. An agent can roughly infer the purpose but not cleanly separate this tool from its neighbors.

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?

There is an implied workflow — read status, preview, then confirm — and a scope limit ("仅本次协助"), which gives some when-to-use signal. But there is no explicit statement of when this tool is preferred over the many other contact-request tools in the sibling list, and no prerequisites or exclusions beyond the one-time nature.

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