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

No annotations are provided, so the description carries full burden and it does well: it discloses login requirement, managePolicy authorization, that owned orgs apply immediately while joined orgs require acceptance, and — critically — that the call overrides any current pending proposal from either party, which is a real destructive side effect worth flagging.

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?

Front-loads the hardest constraints (login, managePolicy) and packs substantive content into a few semicolon-separated clauses. Dense but every clause carries information; slightly run-on structure is the only cost.

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 3-param mutation tool with no annotations and no output schema, the description covers permissions, effect mode, unit/range semantics, and override behavior — enough for an agent to call it correctly. It leaves the response shape unstated, but that is minor for this mutation.

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 0% schema description coverage, the description compensates where it matters most: it clarifies allianceShareBps is the alliance's share of the acquisition/management revenue pool, 0..10000 with 10000=100%, and explicitly not the proportion of the whole order revenue — resolving the main ambiguity. allianceId/organizationId get only the generic 'confirm alliance/organization' hint, but their names are self-evident.

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: set/propose the alliance's share of an organization's revenue pool. It distinguishes the two modes (自有直接生效 vs 加盟通知待接受) which differentiates behavior, though it never names the sibling propose_organization_alliance_share or respond_alliance_organization_share to disambiguate further.

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?

Explicit precondition: '仅盟主 managePolicy' and '先读下属组织 share 与 relation' define who may call and what to read first. It explains which mode applies based on whether the org is owned or joined, but does not explicitly route to an alternative tool when the caller is not the leader or wants to propose rather than set.

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