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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile needs no repeating. The description contributes the underlying HTTP endpoint and a summary of the record shape, but says nothing about pagination limits, rate limits or auth scoping that the annotations don't cover.

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?

A single compact sentence with the resource and returned fields front-loaded, followed by the endpoint. No filler or redundancy.

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 no output schema, the field enumeration partially substitutes for a return-value description, and pagination is covered by the schema's current_item/page_size text. Missing only a note on total counts or paging termination, which is minor for a simple read-only listing tool.

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 coverage is 100%, so page_size, current_item, include_branches and include_customer_groups are already fully documented in the schema. The description's mention of 'branches, customer groups' only loosely gestures at the include flags and adds no syntax, defaults or pagination semantics beyond the schema.

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 the specific verb 'list' and resource 'price books', enumerates the fields returned (name, active flag, validity dates, branches, customer groups) and names the endpoint GET /pricebooks. The list-vs-get distinction from sibling kiotviet_get_price_book is implied by the verb but never made explicit.

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?

Usage is only implied by the name and verb 'list'; the description gives no guidance on when to pick this over kiotviet_get_price_book or other list tools, and no prerequisites are mentioned. An agent can infer this is the bulk-enumeration variant, but nothing in the text confirms it.

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