get_smart_follow_results

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: results are limited to the most recent analysis (not a history), and target price is null/'—' for actions other than follow_price/raise_price. It does not cover the empty state (no analysis run yet) or any permission/scope constraints, which is the remaining gap.

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?

Purpose is front-loaded in the first sentence, followed by clearly delimited blocks for query phrasings, the optional parameter, and action-value semantics. Every block is labeled and the value glossary prevents misinterpretation of the returned action field.

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 single optional-parameter read tool with an output schema, the description covers what is returned, the meaning of the action enum, and the null semantics of target price — the agent can call and interpret it correctly. Only the no-data case and the provenance of monitor_id remain unspecified.

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% — monitor_id has no description or enum in the schema — but the description compensates with '只看指定监控项的结果', clarifying it acts as a filter rather than a selector. It omits where to obtain a valid monitor_id (presumably get_monitor_list), which would have made the parameter fully actionable.

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 opening line gives a specific verb and resource ('查看最近一次智能跟卖分析的结果') plus the exact payload (suggested action, target price, reason, competitor snapshot per self-owned product). It implicitly distinguishes itself from run_smart_follow_analysis by scoping to the most recent existing result, but it never names that sibling or get_smart_follow_stats, so the differentiation is left to inference.

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 '用户可能的问法' block gives concrete routing triggers ('最近一次跟卖分析结果是什么', '系统建议我跟着降价吗') that map natural-language intents to this tool. There are no explicit exclusions or named alternatives telling the agent when to prefer run_smart_follow_analysis or get_smart_follow_stats instead.

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