style_styles

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

No annotations are provided, so the description must fully disclose behavioral traits. It uses the verb '读取' (read) implying a read-only operation, which is helpful, but does not explain any side effects, prerequisites (e.g., module must be rendered), performance implications, or what the returned subtree structure looks like. It provides some context via '探索/对稿时用' but leaves key behavioral details unstated.

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 two short sentences, front-loaded with the core action and selection method, followed by usage context and alternative. Every word earns its place; no fluff or repetition of schema field descriptions.

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 7 parameters, no output schema, and no annotations, the description gives a high-level purpose and usage context but omits important details like the meaning of depth or maxNodes, how the returned subtree is structured, and any constraints or prerequisites. It is minimally viable but leaves gaps in fully guiding the agent.

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 low (43%), so the description must compensate for undocumented parameters. It does clarify that the module can be selected by 'uid 或 css', covering the two main selector parameters. However, it does not explain the depth or maxNodes parameters, which remain undocumented in both schema and description. It partially compensates but not fully.

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 clearly states the tool's action: '读取模块 computed style 子树（uid 或 css）' (read the computed style subtree of a module, by uid or css). It names the resource (computed style subtree) and the selection mechanism, and explicitly distinguishes from sibling style_inspect by saying '有 spec 优先 style_inspect'.

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 gives explicit usage context: '探索/对稿时用' (use during exploration/design comparison). It also names an alternative tool and when to prefer it: '有 spec 优先 style_inspect' (if a spec exists, prefer style_inspect). This is clear when-to-use and alternative guidance.

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