subscribeSpreadOrder

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds one useful behavioral detail beyond them: authentication is required. It does not contradict the annotations — subscribing to order changes is consistent with a read-only, open-world stream. However, it fails to disclose the delivery mechanism (e.g., whether this is a one-shot poll governed by timeoutMs/messageCount or a persistent WebSocket subscription), which is material for a subscription tool.

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 verb and resource front-loaded and no filler words. The auth requirement is efficiently appended in parentheses. It is appropriately concise, though the brevity borders on under-specification, which is penalized in other dimensions.

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, 0% parameter coverage, and a large sibling family including near-identical subscription tools, the description is too thin to fully guide an agent. It does not clarify what events count as '订单变动', how the returned data is delivered, what timeoutMs/messageCount do, or how this differs from subscribeSpreadExecution — several of these gaps would lead an agent to mis-select or mis-invoke the 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 description coverage is 0%, so the description must compensate, but it says nothing about timeoutMs or messageCount. The parameter names and defaults are partially self-documenting (a timeout in milliseconds, a message count), which prevents a score of 1, but an agent gets no explanation of how these interact with a 'subscribe' operation — e.g., whether it waits for messageCount updates or times out.

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 '订阅 Spread 订单变动（需要鉴权）' states a specific verb (subscribe) and resource (Spread order changes), so an agent can tell it is about spread order change notifications. However, it does not explicitly distinguish itself from close siblings like subscribeSpreadExecution, subscribeOrder, or subscribeExecution — the differentiation is only implicit via the resource name.

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?

The description offers no guidance on when to use this tool versus the many subscription siblings — it does not mention subscribeSpreadExecution, subscribeOrder, or how 'order changes' differs from 'executions'. The parenthetical '需要鉴权' (authentication required) is a prerequisite note, not usage guidance. Usage context is only weakly implied by the verb and resource name.

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