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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds meaningful context beyond them: it requires login and matchmaking management capability, and explicitly states phone numbers are NOT returned — a privacy behavior an agent cannot infer from schema or 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?

Uses bracketed labels to front-load the auth requirement, then the payload, then the sibling chain. Very compact with no wasted prose, though the telegraphic style slightly reduces 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?

No output schema exists, so the description carries the return-value burden and does so reasonably: it names the fields returned and the excluded phone field, plus auth prerequisites. Missing only edge-case behavior (e.g., what happens for invalid pairId), which is minor for a simple getter.

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 100%, with pairId and organizationId both documented in the schema (including the pairId vs proposal-id caveat). The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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: viewing a match pair's details, and names the returned content (both users' business profiles, reason, channels). An agent can distinguish it from list_organization_match_pairs or invite_organization_match_pair_to_activity, though the phrasing is terse.

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?

Explicitly routes to siblings in the 【组合链】 block: detail lookup vs invite_organization_match_pair_to_activity for inviting, and draft_organization_match_activity for copy. It also states the prerequisite (login required, matchmaking management capability). No explicit when-not-to-use, so not a 5.

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