get_product_performance_tool

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

No annotations are provided, so the description carries the full behavioral burden. It does add real domain context by naming the VIDEO/LIVE/PRODUCT_CARD breakdown of the response, but it says nothing about required permissions, whether seller_name is mandatory in practice, rate limits, or how date windows are interpreted. Read-only behavior is only implied by 'Get'.

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?

Two short sentences, zero filler, and the core purpose plus the breakdown dimension are front-loaded. It is efficient, though it veers toward under-specification for a six-parameter tool.

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 six parameters at 0% schema coverage, no annotations, and no required fields, the description leaves critical gaps: the meaning of granularity='ALL', how start_date_ge/end_date_lt bound the query, and the role of currency and product_id. The existence of an output schema excuses it from explaining return values, but not the parameter behavior.

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 description coverage is 0% across six parameters, so the description must compensate and largely does not. Only seller_name gets semantic help ('to specify shop'); product_id, currency, granularity, start_date_ge, and end_date_lt are left with no explanation of defaults, accepted values, or date-window 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?

States a specific verb and resource ('Get single product performance') and scopes it to one product, which reads differently from shop-level siblings like get_shop_products_performance_tool. It also discloses the metric segmentation (VIDEO/LIVE/PRODUCT_CARD). It stops short of naming an alternative tool to disambiguate from get_product_detail_tool or get_sku_performance_tool.

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 sentence 'Use seller_name to specify shop' gives a concrete usage hint for one parameter, so usage is implied rather than absent. But there is no guidance on when to choose this tool over get_product_detail_tool, get_sku_performance_tool, or get_shop_products_performance_tool, and no prerequisites or date-range conditions are stated.

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