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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it requires login (【需要登录】), it returns two structured halves (prefs and governance), it explains the 20-entry limit and the silent eviction behavior, and it clarifies the meaning of needOpen=false entries. It doesn't contradict annotations. The only minor gap is not describing pagination or exact response shape, but with no output schema and a read-only list tool, the description carries substantial weight and does so well.

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 description is dense but well-structured: it opens with the login requirement and the core question it answers, then breaks down the two halves, then gives the chaining path, then the operational caveat. Every sentence carries distinct information. The use of bold labels and arrow chains makes it scannable. It is longer than average, but the density and structure justify the 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?

For a zero-parameter read-only tool, the description is complete: it states the login requirement, enumerates the returned categories, explains the scope semantics, provides the sibling chain for mutations, and warns about the 20-slot limit and silent eviction. There is no output schema, so the description's enumeration of prefs and governance fields is the primary contract. Nothing an agent needs to decide whether to call this tool is missing.

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?

The tool has 0 parameters, so there is no schema to compensate for. The description explains what the returned data means (WANT/AVOID, scopes, bound needs, expiry times, governance fields), which is the semantic content an agent needs. Baseline for 0 params is 4, and the description earns it by explaining the meaning of the data it returns.

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 clearly states this tool retrieves the user's icebreak match preferences, listing both halves: prefs (WANT/AVOID with scopes PROFILE/NEED/TEMPORARY) and governance (icebreak, icebreakPace, icebreakSnoozeUntil, icebreakRole). It uses a specific verb (list/get) and resource (my match preferences), and the title reinforces it. It distinguishes itself from siblings like set_my_match_preference and revoke_my_match_preference by being the read counterpart.

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?

The description explicitly provides a combination chain: this tool → set_my_match_preference to add / revoke_my_match_preference to remove → set_notification_prefs to adjust pace or snooze. It also gives operational guidance: entries with needOpen=false are bound to delisted needs and waste the 20-slot limit, so revoke them first; when the limit is full, writing a new one silently evicts the oldest. This is explicit when-to-use and how-to-chain guidance, far beyond a typical description.

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