lufa_add_to_basket

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 reveals immediate effect (no draft state), the increment semantics of quantity, the separate product ID treatment for variants, and the session requirement. These are non-obvious behaviors that an agent needs to know, and they are stated clearly and confidently.

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 and front-loaded with the primary action. The additional paragraphs add valuable context without fluff, and the Args section cleanly separates parameter explanations. Every sentence earns its place with unique information, and the structure makes it easy to scan.

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 simple two-parameter tool, the description covers everything needed: how to add, what to know about variants, the increment behavior, session requirement, and the immediate effect. It even references the related tool for finding product variants. There is no output schema, but the description doesn't need to explain return values given the tool's straightforward purpose.

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 provides no parameter descriptions (0% coverage), so the description compensates fully. It explains that product_id is the ID to add and that quantity is an increment on top of the current basket quantity, not an absolute target. This goes beyond the schema's bare type/default information, giving actionable meaning to both parameters.

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 opens with 'Add a product to the basket,' a specific verb+resource statement that clearly identifies the tool's function. It further distinguishes from siblings like lufa_remove_from_basket and lufa_view_basket by focusing exclusively on the add operation and the immediate effect of the change.

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?

Provides clear when-to-use context: add products, with a note that no save_basket is needed since changes take effect immediately. It also gives explicit guidance on handling product variants—check sub_products via lufa_get_product_details—and prerequisites like requiring an active session. This exceeds simple implied usage by offering an alternative workflow.

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