identify_product_from_image

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

No annotations are provided, so the description carries the full burden. It explains that the tool searches ERPNext and returns a result, which implies read-only behavior, and clarifies that it does not process images itself but uses extracted data from Hermes. However, it does not disclose potential behaviors such as whether it creates records, error handling for no matches, or required permissions. The workflow transparency is useful but not fully comprehensive.

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 yet information-dense. It front-loads the primary purpose, then provides a numbered workflow (1-3), and ends with usage examples. Every sentence contributes value: purpose, workflow, and when-to-use. The structure is logical and easy for an agent to parse, with no fluff.

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?

The tool has no output schema, so the description should explain what the result contains. It only says 'retourne le résultat' without specifying if it includes price, stock status, or product details, despite usage examples suggesting those queries. Edge cases (e.g., no match found) are not addressed. Given the simplicity of the tool and the workflow, this is a moderate gap, making the description minimally viable but not fully 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 has 100% coverage, with descriptions for all four parameters. The description adds context by explaining that the parameters are the data extracted by Hermes from the image, which explains why they are optional and how they are used. However, it does not provide additional syntax or format details beyond what the schema already states, so a baseline of 3 is appropriate.

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 tool's function: identify a cosmetic product in ERPNext using data extracted from an image. It distinguishes from siblings like search_items or create_item_from_image by specifying the product identification workflow and the input of extracted data rather than raw images. The verb 'Identifier' and resource 'produit cosmétique dans ERPNext' make it specific.

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 explicit usage context: when a user sends a product photo and asks questions like 'what is this product' or 'is it in stock'. It also outlines a workflow where Hermes first analyzes the image with vision_analyze, then calls this tool, which clarifies when to use it versus performing direct image analysis. However, it does not explicitly mention alternatives or when NOT to use it beyond implicit steps.

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