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

Annotations already declare this as a read-only, idempotent, open-world read, so the safety profile is covered. The description adds non-obvious behavior — slug resolution searches sale listings first then rentals, and camper_id pulls from the full catalog spec sheet — which is genuine context beyond the annotations.

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 three sentences are front-loaded with the primary action, then resolution behavior, then output content — each earns its place. Slightly dense but 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 7 parameters and no output schema, the description does the heavy lifting by summarizing what is returned (decoded specs, photo URLs, equipment, contact details, listing URL) and the includePhotos behavior. It is close to complete for the tool's complexity, though it doesn't note any rate or permission constraints (unneeded for a read-only lookup).

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, but the description adds interpretive value: it clarifies the slug/segment interplay and that includePhotos causes actual images to be attached for viewing. It notes the returned field groups (specs, photos, equipment, contact, URL), reinforcing what the parameters yield.

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+resource ("Get full details for one camper listing") and immediately distinguishes the two lookup modes (slug vs camper_id) so an agent can tell it apart from sibling tools like search_campers or get_marketplace_listing_details.

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 explains the resolution behavior for each identifier type and when to override with segment ("set segment to force 'sale' or 'rental'"), which gives clear context for choosing inputs. It stops short of naming which sibling tool to prefer over this one, so it lacks an explicit alternative-routing statement.

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