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

Beyond the annotations it discloses the full lifecycle: nothing is published until the seller opens the link and taps Publish, no Commonplace account is required, and the seller is texted the link when seller_phone is present — real side-effect information an agent needs. The only gap is a mild tension with readOnlyHint=true, since the description's own verb is 'Save a draft,' a persisted artifact, which the description never reconciles with the read-only hint.

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 content is useful but the structure is loose: the 'when also posting to Facebook Marketplace, Craigslist, or OfferUp' clause appears twice, and the price/take-home explanation arrives after a redundant second 'use this when' sentence. It is also not front-loaded on the action — the first clause is a use condition, not what the tool does.

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 15-parameter tool with no output schema, the description covers the essentials an agent needs: the draft/publish gate, the returned confirm link, the SMS side effect, and the price-type semantics. It does not cover what happens with invalid or missing photos, category resolution (there is a listing_resolve_category sibling), or failure modes, but nothing critical to correct invocation 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?

With only 40% schema description coverage across 15 parameters, the description does compensate for the two hardest ones: price_type (the price the seller asked for on the other site becomes their take-home) and seller_phone (triggers the SMS). But it adds nothing for title, description, category, condition, brand, city/state/zip, source_url, seller_name, or seller_email, so roughly half the parameters remain undocumented in both places.

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 gives a specific verb and artifact: "Save a draft and return a confirm link," which is clearly distinct from listing_create (publishes) and listing_add_photos (attaches media). It also scopes the use case to large/valuable items. However, the action statement is buried behind two 'use when' sentences, and the framing leans on the title rather than leading with what the tool does.

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 explicit triggering conditions with concrete item examples (fitness equipment, hot tubs, saunas, golf carts, furniture, appliances) and the cross-listing scenario (Facebook Marketplace, Craigslist, OfferUp). It also states a constraint: use when this connection cannot create listings itself. It does not, however, name a sibling alternative (e.g. listing_create) for the non-crosslist case, and the Facebook/Craigslist/OfferUp clause is repeated verbatim twice.

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