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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the description's extra burden is lower. It still adds genuinely useful behavior beyond the annotations: a nonpublic listing is readable only while this account holds a membership, unknown targets fail closed, and the required consent scope is named. The only weakness is that the write-named scope on a read-only tool is asserted repeatedly without explaining why.

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?

The same three facts — exact listing snapshot, membership-gated nonpublic reads, and account:watchlist:write consent — are restated four or more times in near-identical sentences, with no clear front-loaded hierarchy. A single compact paragraph would carry the same information; the repetition actively slows an agent trying to extract the operative constraints.

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?

An output schema exists and the single parameter is fully documented, so the description is not required to explain return values. It nevertheless covers auth scope, fail-closed behavior on unknown targets, and the nonpublic-membership restriction, which is the full set of things an agent needs before calling. Only the absence of explicit sibling routing keeps it from being complete.

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?

The schema has one parameter at 100% description coverage, and the field doc already explains that it is an exact listing ID rather than a catalog, product, or account identity. The description restates the same constraint (public to add, nonpublic only while a membership exists) without adding format, source, or lookup guidance, so it meets but does not exceed the baseline for a fully documented schema.

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 states a specific verb and resource: read one exact listing's product identity, current account membership rows, and public add eligibility. That is concrete enough to distinguish a single-target snapshot from a bulk list. It never names the adjacent list/watchlist siblings (supercatch_list_watchlist_items, supercatch_list_account_watchlist, supercatch_get_listing), so sibling differentiation is left to inference.

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 gives a timing hint — inspect 'before a requested change' — and states that membership changes require a separate add or remove call with explicit intent, which implicitly routes the agent away from this tool for mutations. However, no alternative tool is named and there is no explicit 'use X instead when listing many items' exclusion, so the agent must infer the boundary against the list tools.

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