style_inspect

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

No annotations are provided, so the description carries the full burden. It discloses one key behavior: '默认只返回失败项' ('only returns failures by default'), which is useful. However, it does not mention other behaviors like error handling, side effects, or return format, leaving a moderate transparency level.

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 three short sentences, each earning its place: the first states the purpose, the second describes default behavior, and the third gives usage guidance. It is front-loaded, efficient, and free of unnecessary words.

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 six optional parameters and no output schema, this description provides the essential context: what it does, the default output behavior, and when to prefer it. It does not explain the selector parameters or the setup/nodes/relations structure, but the schema covers the parameters. It is reasonably complete for a read-only inspection 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?

The input schema covers all 6 parameters with descriptions, so the baseline is 3. The description adds no new parameter-level meaning; the 'failures only' default is already documented in the failuresOnly parameter. Thus, the schema does the heavy lifting and the description does not enhance it.

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 identifies the tool as running style/layout checks based on a JSON spec, with a parenthetical defining the scope (setup+nodes+relations). It distinguishes from sibling tools by emphasizing spec-driven inspection and explicitly recommending it when acceptance criteria exist, which sets it apart from status, tab, and find tools.

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 a clear when-to-use signal: '有验收标准时优先用' ('prefer when acceptance criteria exist'). This provides context for choosing this tool over alternatives, but it does not mention specific sibling names or state when not to use it, so it stops short of full guidance.

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