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

Annotations only declare idempotent and non-destructive, so the description carries the safety burden and does it well: it names the login + AI authorization prerequisite, enumerates the access gates that make the call return nothing, and excludes private channels that still need per-order consent. The closing constraint (不预取、外传或自动联系) also tells the agent how the retrieved data may not be used.

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 whole definition is one dense, front-loaded sentence with the authorization precondition first and the read scope second; nothing is filler. It loses a point for terse abbreviations (未接/撤回) that are efficient but slightly opaque.

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?

With no output schema, the description does tell the agent what kind of data comes back (mutual contact info for the two parties, excluding private channels) and when it will be empty. It does not describe the shape of the returned contact fields, but for a single-parameter read that is a minor gap.

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% for the single introductionId parameter, so the description must compensate. It only obliquely ties the input to 本单 (this order/introduction), never stating that introductionId is the introduction identifier or what format it takes. That is partial compensation, not full.

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 states a specific verb and resource: read the mutually visible contact details of the seeker and the accepted introducer for this introduction (本单). That is far more precise than the name alone. It stops short of naming a sibling it is not (e.g. get_network_introduction or list_network_contacts), so an agent must infer the boundary from the word 联系方式.

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 clear positive trigger (仅用户明确为本单推进要求时) and explicit negative conditions (未接/撤回/无权/屏蔽等不可读), which is stronger than most read tools. What is missing is an explicit alternative to use instead when those conditions fail, so it falls short of a 5.

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