wb_orders_new

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It names the resulting data but says nothing about pagination, result ordering, response format, or required auth scope. The operation is low-risk as a zero-param fetch, but the disclosure is minimal.

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?

Eight words plus a Russian gloss carry the entire semantic payload with zero filler. The key qualifiers (FBS, new, awaiting assembly) are front-loaded, making this maximally efficient for an agent to parse.

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 tool with no output schema and no annotations, the description is the sole information source. It states the resource clearly, but it does not define what 'new' means in status terms, whether results are paginated, or how this tool relates to wb_orders_list — notable gaps given the 130+ sibling tools.

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 is empty (0 parameters), so there is nothing for the description to add beyond the schema — the baseline of 4 applies. No parameter documentation gap exists.

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 identifies a specific resource — FBS orders in a particular state (new, awaiting assembly) — and the 'FBS' qualifier distinguishes it from the DBS and CC variants in the sibling list. However, the verb is only implied ('get/list'), and it doesn't clarify how this differs from wb_orders_list, 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?

No when-to-use or when-not-to-use guidance is provided. Given nearly identical sibling names like wb_dbs_orders_new and wb_cc_orders_new, an explicit statement that this is the FBS fulfillment-type variant would materially help an agent route correctly. Without it, an agent must infer the distinction from the 'FBS' token alone.

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