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

Annotations only say readOnlyHint=true; the description adds real behavioral facts beyond that: a login is required, results are capped at 50, the applications scope only surfaces non-members pending review or rejected within 30 days, and per-organization expansion is costly so it should not be called in a loop. It also clarifies that pending relationships carry no admin permissions, which matters for downstream authorization assumptions.

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?

Every clause earns its place — status semantics, the scope caveat, sibling routing, and the performance warning — and the status semantics are front-loaded. The telegraphic semicolon-and-arrow style, with sentence fragments and mixed Chinese terms, makes it denser than it needs to be, but nothing is padding.

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-required-parameter, single-parameter read tool with a known enum, the description covers everything an agent needs: auth requirement, result cap, status meanings, where to go for related data, and a cost warning. With no output schema, it still describes the shape of the returned relationships well enough to consume them.

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 100% and there is a single enum parameter, so the schema already covers the baseline. The description nonetheless adds meaning the schema does not: it explains the 30-day rejection window and the 50-item cap that apply when scope=applications, and states that omitting scope returns all relationships. That is a genuine semantic addition over the enum's terse 'applications=仅申请中'.

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 makes clear this returns the caller's own organization relationships and enumerates the meaningful states (joined = on roster; pending = applying or rejected but not yet a member, with no admin rights). It distinguishes itself well from organization-side listing tools by the repeated '本人/我的' framing. The only weakness is that the listing verb itself is implicit and the status vocabulary is dense, but an agent can still tell what data comes back.

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 routes explicitly to alternatives by identifier type: membershipId goes to update_my_organization_membership for promotion control, organization id goes to list_organization_applications for reviewing applications and list_my_organization_tasks for task viewing, and agreement text/signup answers go to get_organization(includeTermsBody=true). It also gives an explicit anti-pattern — do not loop per organization because it is expensive — which is exactly the kind of when-not guidance agents need.

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