Update Product

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

Annotations include idempotentHint=true and destructiveHint=false, which already cover safety and idempotency. The description adds only that it 'Returns confirmation of the update,' but does not clarify whether the update is partial (only provided fields are changed) or full (unspecified fields are reset). This is a behavioral gap not covered by 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 and front-loaded with the core purpose. It lists the required and optional parameters in a straightforward manner, though the formatting could be improved by referencing the schema for detailed parameter types and defaults. No unnecessary text is present.

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 description provides the essential information to call the tool (product_id required, optional fields), and it mentions the return value (confirmation). However, it does not explain whether the update is partial or full, what the confirmation format looks like, or how the response_format parameter affects the output. Given the tool's moderate complexity and lack of an output schema, these gaps make it less 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% parameter coverage with descriptions for all eight properties, so the baseline is 3. The description merely lists the field names without adding any additional meaning or clarifications beyond what the schema already provides (e.g., price in cents, availability semantics).

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 that it 'Updates a product's details' and lists the specific updatable fields (name, description, price, availability, image_url, url). This differentiates it from get/create/delete product tools, and the verb 'update' unambiguously indicates a write operation.

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 no explicit guidance on when to use this tool versus alternatives like meta_create_product or meta_get_product. It only says 'Updates a product's details,' implying it is for existing products, but it does not state any prerequisites, exclusions, or scenarios where this tool is preferred.

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