ozon_order_fbs_cancel_reasons

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, and it says nothing about what the tool returns, whether it is read-only, whether it requires an order context, or what the structure of the reasons looks like. It does not contradict any annotations, but it adds almost no behavioral context beyond the tool name.

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 extremely short—a single noun phrase with a Russian gloss—so there is zero waste, but it is under-specified rather than efficiently concise. It earns a mid score because brevity is achieved by omitting almost all useful information.

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?

This is a simple 0-parameter tool, but with no output schema and no annotations, the description must explain what the agent will get back. 'FBS cancellation reasons' does not say it returns a list, how the reasons are keyed, or how they connect to the cancellation workflow (ozon_order_fbs_cancel). For an agent to select this tool confidently, more context is needed.

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 tool has 0 parameters and 100% schema description coverage (the schema is empty, so nothing is undocumented). Per the baseline for 0-parameter tools, the description need not compensate for parameter documentation gaps. There is nothing misleading about parameters.

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 the resource (FBS cancellation reasons) but lacks a verb—it's a noun phrase rather than a statement of what the tool does (e.g., 'Returns the list of...'). It does distinguish itself from the sibling ozon_order_fbs_cancel, which is the actual cancellation action, so an agent could infer it provides valid reasons to pass to that tool. However, it never explicitly says it retrieves a list.

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 guidance on when to use this tool versus alternatives. It is silently related to ozon_order_fbs_cancel and ozon_cancellation_list, but the description does not state that these reasons are meant to be used when cancelling an FBS order, nor when it should not be used. The agent is left to infer context from the sibling set.

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