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

With no annotations provided, the description carries the full burden and excels: it discloses lot-locking on unmet MOQ, public fill mechanics, the 30-day deadline triggering refund_pending, auto-refund candidate listing, the full status flow, and account scoping. This is far beyond typical descriptions and gives the agent a clear mental model of side effects.

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 dense but not bloated; it front-loads the purpose and then systematically covers lock behavior, fill mechanics, deadline, refund flow, and status transitions. Every sentence earns its place, though the sheer number of behavioral details makes it slightly long. Overall well-structured for a complex 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?

Covers nearly all critical context: input alternatives, MOQ/lot-lock behavior, public fills, deadline and refund flow, status progression, and account scoping. The only notable omission is any description of the return value or error conditions, which matters because there is no output schema. Still, for an order-creation tool, the behavioral coverage is unusually 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?

Schema coverage is 83%, so the baseline for parameter semantics is 3. The description reinforces that rfq_id is for a received RFQ and supplier_id+kind is for direct orders, but the schema already documents these conditions. The description adds no new parameter-level detail beyond what the schema provides, though it does help connect the mental model of how parameters interact.

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?

Description states a specific verb ('Open a purchase order (受注)') and resource, and clearly distinguishes the two input modes (from a received RFQ or directly with supplier_id+kind). It is immediately apparent how this tool differs from sibling order-related tools like mu_order_advance and mu_order_status, which focus on state changes rather than creation.

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?

Explicitly explains when to pass rfq_id versus supplier_id+kind, and gives context for both paths. However, it does not explicitly name sibling tools as alternatives or state exclusion criteria (e.g., 'use mu_order_advance when you need to change an existing order'), so it stops short of full when/when-not guidance.

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