save_vehicle

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It candidly states 'Best-effort: clicks the Save/Watchlist control on the listing page', revealing the underlying UI automation behavior, and 'Requires confirm: true before any account action is taken', disclosing the two-step confirmation flow. It also notes the authentication requirement. While it doesn't describe failure modes or side effects like pre-existing saves, the transparency is above average for a tool with no 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 description is concise, delivered in two sentences with no fluff. The primary action and authentication prerequisite are front-loaded, followed by the best-effort nature and confirm requirement. Every phrase adds value, and the structure is logical and scannable for an agent.

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 tool with three parameters, no output schema, and no annotations, the description covers the essential aspects: the action, the auth prerequisite, the best-effort behavior, and the human-in-the-loop confirmation. It does not explain what the tool returns (though none is specified) or handle edge cases like when a listing is already saved, but given the absence of an output schema and the tool's relative simplicity, the description is reasonably 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 input schema already has 100% description coverage, with each parameter (url, confirm, listingId) having meaningful descriptions. The tool description adds little beyond restating the confirm requirement ('Requires confirm: true') and does not provide additional syntax or format details. This matches the baseline of 3 where the schema does the heavy lifting.

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 clearly states the action: 'Save/watchlist a carsales listing to YOUR account', with a specific verb and resource. It also mentions the authentication prerequisite via set_auth, which adds specificity. However, it does not explicitly differentiate from the 'watch_listing' sibling, which may perform a similar operation, so it doesn't fully distinguish among siblings.

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?

The description provides clear context about the requirement for an authenticated session and the confirm flag (human-in-the-loop), which signals when it is appropriate to invoke. However, it does not explicitly state when to use this tool versus alternatives like 'watch_listing' or 'remove_watch', nor does it mention any exclusion conditions. The guidance is implied rather than explicit.

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