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

readOnlyHint=true already establishes a safe read. The description adds substantive behavioral context beyond annotations: login is required, statistics are gated by directory authorization, relation must not be guessed when absent, and contacts return only public identity. These are meaningful data-visibility and interpretation constraints.

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?

A single front-loaded line places the login requirement first, then the operation and caveats. It is dense but every clause carries information; there is no filler, though the run-on phrasing could be broken up for easier parsing.

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 detail tool with no output schema, the description covers authentication, data-scope dependencies, interpretation caveats, and the categories of data returned. It stops short of describing error cases or exact response shape, but is largely sufficient for correct invocation.

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%, so the schema itself documents neither allianceId nor organizationId. The description's '先读联盟工作台，再看单个在册下属组织' implicitly maps the two IDs to the alliance and the subordinate organization, but adds no format, length, or constraint details. This is partial compensation only.

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 names a specific resource — a single registered subordinate organization under an alliance — and enumerates the aspects returned (capabilities, actual authorization, owner/manager, revenue-share status). The '先读联盟工作台' framing distinguishes it from the workbench tool, though the verb 'get/view' is implicit rather than stated as 'returns details'.

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 provides a sequencing prerequisite ('先读联盟工作台') and data caveats ('统计取决于 directory 授权', 'relation 缺省不能猜'), which is useful implied usage guidance. However, it never names a sibling alternative (e.g., list_alliance_organization_members, get_organization) or states when not to use this tool, leaving routing to inference.

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