comfyui_audit_dangerous_nodes

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not restate safety. It adds value by disclosing what is scanned for (arbitrary code, shell commands, file system access) and the return structure (dictionary with counts and lists), which are behavioral details beyond the annotations.

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 sentences, front-loaded with the core purpose, then expands on scope, use case, and return value. It is concise with no wasted words, and the 'Returns:' section clearly separates output info.

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?

Given zero parameters, strong safety annotations, and an output schema, the description fully covers the tool's behavior. It explains what it does, why you'd use it, what it looks for, and what it returns. No critical information is missing.

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 has zero properties, so there are no parameters to describe. The description correctly omits parameter details. With 0 params, a baseline of 4 is appropriate, and the description does not need to compensate for any schema gaps.

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 first line states 'Audit all installed nodes to identify potentially dangerous ones' with a specific verb ('audit') and resource ('all installed nodes'), clearly distinguishing this from sibling tools like list_nodes or get_node_info. The description further elaborates on the scanning criteria, making the purpose unambiguous.

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 provides a clear use case ('Useful for building a dangerous node blacklist') and describes the scan focus (code execution, shell commands, file system access). It does not explicitly mention alternatives or when not to use, but the context is sufficient for an AI agent to infer when this tool is appropriate.

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