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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely new context: login is required, the caller must be a registered org member, and invitation/application/internal-relationship data is trimmed by server-side management capability. That auth and capability-trimming disclosure is meaningful beyond the structured hints.

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?

Dense but efficient: the login requirement is front-loaded, then usage guidance, with no filler sentences. It leans on terse field jargon (current, requiredGrants, share, 能力) that is compact but borders on cryptic for an agent lacking field knowledge.

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 read-only tool with no output schema, the description names the key fields a caller should inspect (current, requiredGrants, share, capabilities) and states the auth precondition, which is adequate coverage. It could still be clearer about the shape of the returned status, but nothing essential to invoking it correctly 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?

With one parameter at 0% schema description coverage, the description should clarify organizationId but does not; it only implies the org must have the caller as a registered member. The single orgId is largely self-evident from the name, so this is minimum viable rather than actively misleading.

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 name and title establish that this reads an organization's alliance relationship status, but the description itself never states what the tool returns in plain terms. It jumps straight to auth preconditions and manager advice, leaving the purpose to be inferred from the tool name rather than the description text.

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?

Strong on when-to-use: it tells managers to read this before joining, changing grants, leaving the alliance, or negotiating revenue splits, and warns not to infer behavior from organization type. It stops short of naming alternatives (e.g. get_alliance, get_alliance_workbench), so it does not reach 5.

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