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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds real substance beyond them: partial-update semantics ("Only non-null fields are updated") and the important side effect that `seliee_articles_order_active=False` pauses waiting articles while True resumes them. That side effect is exactly the kind of downstream consequence an agent needs before invoking a destructive tool; a fuller note on reversibility or scope of the pause would push it higher.

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 compact sentences, front-loaded with the action and target, followed by update semantics and the side effect. No filler, though the compressed phrasing of the active-flag sentence takes a second read.

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 destructive, six-parameter mutation tool with no output schema and no parameter descriptions, the definition covers the highest-risk aspects (partial update, pause/resume consequence) but leaves half the parameters unexplained and says nothing about return values or failure modes when neither identifier is supplied.

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 carries real weight here. It explains the two lookup keys and the semantics of `seliee_articles_order_active`, but leaves `seliee_articles_order_note`, `_type`, and `_title` undocumented beyond their self-describing names, and never says whether one or both identifiers are required.

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 ("Edit an article order") and names the lookup keys (`order_id` or `order_uuid`), which lets an agent distinguish it from create_articles_order, delete_articles_order, get_articles_order, and list_articles_orders. It does not explicitly name those siblings or explain the boundary, so it stops short of a 5.

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 implied rather than stated: the agent learns it needs an existing order identified by one of two keys, and that only supplied fields change. There is no guidance on when to prefer this over edit_article, no prerequisites (permissions, whether an identifier is mandatory), and no when-not-to-use case.

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