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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses authentication requirements, ordering (newest first), exclusion of deleted listings, pagination via limit/next_cursor, and the _untrusted treatment of user-controlled fields. This is rich behavioral context with no contradiction.

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 core purpose and key constraints are front-loaded, and the explanation of untrusted fields earns its place given the security context. It is slightly dense but every sentence contributes; no filler.

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?

With no output schema, the description carries the burden of describing return contents, and it does so thoroughly: statuses, sales count, seller stats, deleted-listings exclusion, pagination, and untrusted fields. Nothing essential for invoking the tool 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?

Schema description coverage is 100%, so the schema already documents limit and cursor. The description restates the limit cap/default and the cursor's use as next_cursor, adding no new meaning beyond a slight usage framing, which matches the baseline for fully covered schemas.

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 identifies the resource as 'your own listings' and enumerates exactly what each item contains (status, sales count, seller stats), so an agent can tell it returns a list of the caller's own listings. It lacks an explicit action verb like 'list' and doesn't directly contrast with getListing, but the scope is unambiguous.

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 states a prerequisite ('needs your API key') and an exclusion ('Deleted listings are not shown'), and points to updateListing() for edits. However, it doesn't explicitly say when to prefer this over getListing or mySales, so usage guidance is mostly implied rather than stated.

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