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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the safety profile is carried by structured data. The description adds the confirmed=true gate and the internal header/ChannelOAuthId resolution, but never explains what 'manual review' actually does to the listing, whether it is reversible, or what downstream effect it has — meaningful gaps for a destructive mutation.

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?

Three short sentences, front-loaded with the action and its identifying key. Slightly telegraphic in phrasing ('Requires HGRApi Header channel / ChannelOAuthId resolved internally') but every clause carries operational information.

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?

Output schema exists and annotations cover safety, so the description needn't explain returns. It covers the identity key, the confirmed gate, and auth resolution — enough to invoke correctly. Missing only the sibling-routing rationale, which keeps it short of full completeness.

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%, so the baseline is 3. The description only reinforces pendingListingId and confirmed; it ignores the optional productId alternative ('Prefer this for active or terminated listings'), so it adds little routing guidance beyond the schema and leaves the id-selection choice to the schema alone.

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 and resource ('Moves one pending listing to manual review') plus the identifying key (visible pending listing id), so an agent knows exactly what the tool mutates. It does not differentiate itself from the near-identical sibling hgr_post_searchproduct_pausetoreview, leaving ambiguity about which pausetoreview endpoint to pick.

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?

Gives a hard precondition ('Requires confirmed=true') and notes that the channel is resolved internally, which is genuinely useful gating context. But there is no statement of when to use this vs. the many listing-state siblings (hgr_post_searchproduct_pausetoreview, hgr_terminate_listing, hgr_post_listingcreate_editpending) or any exclusion, so usage is only implied.

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