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

注解仅表示非只读且非破坏性。描述补充了关键行为：小部件从不获取数据，并且值按原样显示。这为代理提供了超出注解的有用行为信息，但未涉及权限或副作用。

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?

描述仅两句话，第一句说明操作和对象，第二句提供关键行为上下文。没有冗余，信息密度高。

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?

对于一个小型更新操作，描述涵盖了核心功能和行为。架构中已包含id来源和参数描述，输出模式存在。缺少的是与替代工具的明确对比，但整体足够完整。

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?

虽然架构已覆盖所有参数，但描述通过示例（数字、金额'R50'、文本'Active'）为'value'参数增加了语义，并确认了'name'是标签。这有助于代理理解可接受的值格式，尽管架构已提供基础描述。

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?

描述以明确的动词'Set the value'和资源'Static Value widget'开头，并澄清了该小部件没有数据源且从不获取数据，从而与其他小部件类型区分开来。这为代理提供了清晰的目标和范围。

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?

描述通过说明没有数据源且从不获取来确定使用上下文，暗示此工具用于显示固定值，而不是基于数据的小部件。它没有明确命名替代品，但提供了足够的上下文，让代理可以推断何时使用它。

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